Mejoras de jitter de C# en futuras versiones de framework

Question

Noté que la fluctuación de fase de C# produce un código considerablemente más lento que el compilador de C++, incluso si no se usan construcciones de "sobrecarga gestionada" (como matrices con indexación comprobada).

Para cuantificarlo, lo cronometré el siguiente bucle simple:

public static int count = 1000000000; 
public static int Main() 
{ 
    int j = 0; 
    for (int i = 0; i < count; ++i) 
    { 
     j += (i % 2 == 0) ? ((i + 7) >> 3) : (i * 7); 
    } 
    return j; 
} 

Este bucle se lleva 3.88s para ejecutar (compilado con/O). El bucle equivalente compilado con VC 2010 (-O2) tarda 2.95 s.

Para verificar que se generó código inferior, comparé códigos de máquina: creé una lista (/ FA) del compilador VC, y adjunté un depurador al programa C# (después de completar el ciclo).

De hecho, la versión C++ está utilizando algunos trucos ingeniosos. Por ejemplo, para evitar la multiplicación costosa por 7, hay un registro separado que se incrementa en 7 cada cuenta de bucle. La versión C# hace la multiplicación (imul) cada vez. Hay otras diferencias también.

Entiendo que C# jitter tiene mucho menos tiempo para compilar el código en tiempo de ejecución que VC en tiempo de compilación. Pero, p. Java jitter optimiza dinámicamente los métodos utilizados con frecuencia. C# no parece estar haciéndolo.

Mi pregunta es: ¿hay planes para mejorar la inestabilidad de C# en las futuras versiones de framework?

Answer 1

¿hay planes para mejorar la inestabilidad de C# en las futuras versiones de framework?

¿Estás preguntando si había hecho una reunión secreta el mes pasado entre Microsoft y Xamarin donde se acordó que si bien ambos habían pasado la última década la mejora de sus respectivos nerviosismo, que a partir de ahora estaban enfermos de hacer las cosas mejor, y no molestaría más, y MS reasignaría a todos, mientras que Xamarin rechazaría cualquier parche enviado que mejorara la trepidación.

Diría que esto es poco probable, y que como cualquier otro proyecto de software desarrollado activamente en el mundo, hay planes para mejorarlo.

Además, si realmente quisiera ejecutar el código que me dio lo más rápido posible, lo optimizaría a mano al return 161315136;. Un código como ese puede demostrar que la implementación A es más lenta que la implementación B en un caso dado, pero no dice nada sobre dónde las personas detrás de cualquiera de las implementaciones deben concentrar sus esfuerzos.

Answer 2

las versiones de lanzamiento, VS2008SP1, .NET 3.5SP1, promedio de 10 pruebas:

.NET, x86: 2.646 seconds 
C++, x86: 2.652 seconds 
.NET, x64: 2.352 seconds 
C++, x64: 2.090 seconds 

errores clásicos están asumiendo que E/S es significativa, la medición del tiempo jitting, corriendo el versión de depuración, las pruebas con el depurador asociado entonces el optimizador de jitter está deshabilitado.

La fluctuación x64 utiliza el mismo truco que usted ha mencionado, que no es única para el generador de código C++:

00000030 xor   r9d,r9d 
... 
00000059 add   r9d,7 

Una nueva característica para .NET 4.5 es la optimización del perfil guiada.

Los planes futuros nunca son compartidos por una compañía como Microsoft y no tiene sentido adivinarlos.