¿Optimiza realmente .NET CLR para el procesador actual

Cuando leo sobre el rendimiento de lenguajes JIT como C# o Java, los autores suelen decir que deberían/podrían teóricamente superar el rendimiento de muchas aplicaciones compiladas nativamente. La teoría es que las aplicaciones nativas generalmente solo se compilan para una familia de procesadores (como x86), por lo que el compilador no puede realizar ciertas optimizaciones, ya que pueden no ser realmente optimizaciones en todos los procesadores. Por otro lado, el CLR puede realizar optimizaciones específicas del procesador durante el proceso JIT.¿Optimiza realmente .NET CLR para el procesador actual

¿Alguien sabe si el CLR de Microsoft (o Mono) en realidad realiza optimizaciones específicas del procesador durante el proceso de JIT? Si es así, ¿qué tipo de optimizaciones?

Fuente

2010-03-08 dewald

Por lo que sé, en este momento, no realmente. – zneak

Un teórico de la conspiración también podría reflexionar sobre si MS podría codificar el JIT para des-optimizar si el software se ejecuta bajo el sistema de un competidor, como ser virtualizado en una Mac x86, suponiendo que pudieran detectar que era una Mac. – AaronLS

@aaronls: MacBU hace un estimado de 350 millones de dólares al año en ingresos para Microsoft. Los Mac son un * centro de beneficios * para Microsoft, que es el mayor proveedor de software para Mac en el mundo fuera de Apple. ¿Cómo encajan estos hechos en su teoría de la conspiración? –

Desde el año 2005, David Notario enumera varias optimizaciones específicas dirigidas a su entrada de blog "Does the JIT take advantage of my CPU?". No puedo encontrar nada sobre el nuevo CLR 4, pero imagino que se incluyen varios artículos nuevos.

Fuente

2010-03-08 23:13:14

Wow. Este es un buen hallazgo. +1 –

Buen enlace, gracias. +1 – dewald

Cita del blog: "no vectorizamos el código (que es la ganancia real con SSE2)". Por desgracia, JIT no tiene muchas ventajas. – colinfang

Optimización específica de un procesador Soy consciente de que esto se hace en Mono compilando Mono.Simd calls hasta instrucciones SSE en procesadores que admiten SSE. Si el procesador que ejecuta el código no es compatible con SSE, el compilador JIT generará el código equivalente no SSE.

Fuente

2010-03-08 22:44:36

Creo que algunos compiladores de Java sí, Microsoft .NET no, y solo supera a los precompilados cuando compara manzanas con naranjas. Precompilado puede enviarse con una biblioteca de variantes sintonizadas en diferentes CPU (o más probablemente, diferentes conjuntos de instrucciones) y la comprobación del tiempo de ejecución para elegir qué biblioteca cargar es mucho más barata que JIT. Por ejemplo, mplayer hace esto (google para mplayer enable-runtime-cpudetection).

Fuente

2010-03-08 22:46:41

¿Tiene alguna referencia para respaldar su afirmación de que MS .NET no lo hace? Sin cuestionarlo, solo preguntándome si es opinión o hecho documentado. –

Bueno, resulta que Microsoft .NET realiza algunas optimizaciones basadas en el conjunto de instrucciones pero no en características particulares de la CPU, como el diseño de la memoria caché (http://blogs.msdn.com/davidnotario/archive/2005/08/15/451845. aspx).Mi punto acerca de que el código precompilado puede usar las mismas optimizaciones (y más que son demasiado costosas de encontrar en un compilador JIT) aún se mantiene. –

Conozco las reglas para cambiar o no las funciones en línea dependiendo del tipo de procesador (x86, x64). Y, por supuesto, el tamaño del puntero variará dependiendo de si se ejecuta como 32 bits o 64 bits.

Fuente

2010-03-08 22:47:03

Sí, pero el tamaño del puntero _siempre_ cambia, no importa si está utilizando un compilador tradicional o no. – zneak

Los Jitters de 32 y 64 bits son diferentes, eso es un comienzo.

Fuente

2010-03-08 22:47:26

Según entiendo la pregunta, el OP está buscando optimizaciones * específicas del procesador dentro de una familia de procesadores * (por ejemplo, ¿genera código específico dependiendo de que el procesador actual esté basado en la microarquitectura NetBurst vs. Core, ambos en modo de 32 bits?) –

@Mehrdad, sé que esta no era la dirección principal, pero pensé que merecía una mención. –

.Net Framework Runtime Optimization Service optimiza no solo problemas de programación (optimización del compilador) sino también para procesadores.

Fuente

2010-03-08 22:54:21 erasmus

Señalaré que la razón principal que escuché citada sobre el potencial de los lenguajes compilados JIT para superar a los lenguajes compilados estáticamente no tiene nada que ver con las instrucciones específicas del procesador. En cambio, es que la información sobre el estado dinámico del programa se puede utilizar para optimizar las rutas de código. Por ejemplo, inline caching se puede usar para hacer llamadas a métodos virtuales más o menos tan rápido como llamadas a métodos no virtuales. A grandes rasgos, esto funciona suponiendo que en un sitio de llamada en particular, el método se llama solo en un único tipo y emitiendo un código que salta directamente a esa implementación (y luego reescribe el código si esta suposición no surge más adelante).

Fuente

2010-03-09 15:02:54 kvb

¿El CLR de Microsoft realiza el almacenamiento en caché en línea? – dewald

@dewald - No es que yo sepa, pero creo que varias máquinas virtuales Java sí. Dado que los métodos no son virtuales por defecto en C# (a diferencia de Java), creo que esta era una prioridad menor para .NET. Sin embargo, este es solo un ejemplo de cómo un JIT puede realizar optimizaciones en tiempo de ejecución que son duras o imposibles de realizar de forma estática. – kvb

@dewald - Consulte http://stackoverflow.com/questions/1255803/does-the-net-clr-jit-compile-every-method-every-time para obtener más información sobre el contraste entre los enfoques CLR y JVM. – kvb

¿Optimiza realmente .NET CLR para el procesador actual

Respuesta

Cuestiones relacionadas