¿Pueden los idiomas OO modernos competir con el rendimiento de la tienda matriz de C ++?

D no tiene matrices covariantes. Se les permitió antes del lanzamiento más reciente ( dmd 2.057 ), pero error se ha solucionado.

Una matriz en D es efectivamente solo una estructura con un puntero y una longitud:

struct A(T)
{
    T* ptr;
    size_t length;
}

La comprobación de límites se realiza normalmente cuando se indexa una matriz, pero se elimina al compilar con -release . Por lo tanto, en el modo de lanzamiento, no hay una diferencia de rendimiento real entre los arreglos en C / C ++ y los de D.

Sí, una optimización crucial es esta:

sealed class Foo
{
}

En C #, esta clase no puede ser un supertipo para ningún tipo, por lo que puedes evitar la verificación de una matriz de tipo Foo .

Y a la segunda pregunta, en F #, las matrices covariantes no están permitidas (pero supongo que la verificación permanecerá en el CLR a menos que se encuentre innecesario en las optimizaciones en el tiempo de ejecución)

let a = [| "st" |]
let b : System.Object[] = a // Fails

enlace

Un problema un tanto relacionado es la matriz de comprobación de límites. Esta podría ser una lectura interesante (pero antigua) sobre las optimizaciones realizadas en el CLR (también se menciona la covarianza 1 lugar): enlace

respuesta de Java:

Supongo que en realidad no has evaluado el código, ¿verdad? En general, el 90% de todos los lanzamientos dinámicos en Java son gratuitos porque el JIT puede sortearlos (la orden rápida debería ser un buen ejemplo para esto) y el resto son una secuencia ld/cmp/br que es absolutamente predecible (si no, ¿por qué diablos es?) ¿Tu código lanzando todas esas excepciones dinámicas?

Hacemos la carga mucho antes que la comparación real, la rama se predice correctamente en el 99.9999% (¡estadísticas compuestas!) de todos los casos, por lo que no bloqueamos la tubería (asumiendo que no golpeamos la memoria con el carga, si no es así, será notable, pero entonces la carga es necesaria de todos modos). Por lo tanto, el costo es 1 ciclo de reloj SI el JIT no puede evitar el cheque en absoluto.

Algunos gastos generales? Claro, pero dudo que alguna vez lo note ..

Para ayudar a respaldar mi respuesta, consulte este Dr. Poste de blog Cliff Click que discute el rendimiento de Java vs. C

D no permite matrices covariantes.

void main()
{
    class Foo {}
    Object[] a = new Foo[10];
}  

/* Error: cannot implicitly convert expression (new Foo[](10LU)) of type Foo[]
to Object[] */

Como dices, sería un agujero en el sistema de tipos permitir esto.

Se le puede perdonar el error, ya que este error solo se solucionó en el El último DMD, lanzado el 13 de diciembre.

El acceso a la matriz en D es tan rápido como en C o C ++.

De la prueba que he hecho en una computadora portátil barata, la diferencia entre usar int[] y Integer[] es aproximadamente 1.0 ns. Es probable que la diferencia se deba a la verificación adicional del tipo.

En general, los objetos solo se usan para lógica de nivel superior cuando no todos los ns cuentan. Si necesita guardar cada ns, evitaría usar construcciones de nivel superior como Objetos. Es probable que las asignaciones solas sean un factor muy pequeño en cualquier programa real. p.ej. crear un nuevo Objeto en la misma máquina es 5 ns.

Es probable que las llamadas a compareTo sean mucho más caras, especialmente si utiliza un objeto complejo como String.

¿Preguntó por otros idiomas OO modernos? Bueno, Delphi evita este problema por completo haciendo que string sea una primitiva, no un objeto. Por lo tanto, una matriz de cadenas es exactamente una matriz de cadenas y nada más, y cualquier operación en ellas es tan rápida como el código nativo, sin sobrecarga de comprobación de tipo.

Sin embargo, los arreglos de cadenas no se usan muy a menudo; Los programadores de Delphi tienden a favorecer la clase TStringList . Para una cantidad mínima de gastos generales, proporciona un conjunto de métodos de grupo de cadenas que son útiles en tantas situaciones que la clase ha sido comparada con una navaja suiza. Así que es idiomático utilizar un objeto de lista de cadenas en lugar de una matriz de cadenas.

En cuanto a otros objetos en general, el problema no existe porque en Delphi, como en C ++, las matrices no son covariantes, para evitar el tipo de orificios del sistema que se describen aquí.

  ¿

o tengo que vivir con el hecho de que, por ejemplo, un Quicksort siempre hace O (n log n) verificaciones de tiempo de ejecución innecesarias?

El rendimiento de la CPU no es monotónico, lo que significa que los programas más largos pueden ser más rápidos que los más cortos (esto depende de la CPU, y es cierto para las arquitecturas comunes x86 y amd64). Por lo tanto, es posible que un programa que realice la comprobación de límites en arreglos sea realmente más rápido que el programa deducido del anterior al eliminar estas comprobaciones de límites.

El motivo de este comportamiento es que la comprobación de límites modifica la alineación del código en la memoria, modificará la frecuencia de los accesos de caché, etc.

Así que sí, conviva con el hecho de que Quicksort siempre realiza comprobaciones falsas con O (n log n) y optimiza después del perfilado.

Scala es un lenguaje OO que tiene matrices invariantes, en lugar de covariantes. Apunta a la JVM, por lo que no hay ganancia de rendimiento allí, pero evita una característica errónea común tanto para Java como para C # que compromete su seguridad de tipos por razones de compatibilidad con versiones anteriores.