Tiempo de ejecución de.NET vs. Java Hotspot: ¿Está.NET una generación detrás?

comparison jit

Question

De acuerdo con la información que podría reunir en .NET y el entorno de ejecución de Java, la situación actual es la siguiente:

• Las máquinas virtuales Java modernas son capaces de realizar una recompilación continua, que combinada con la creación de perfiles puede producir grandes mejoras de rendimiento. Las JVM más antiguas emplean JIT. Más información en este artículo: http://www.ibm.com/developerworks/library/j-jtp12214/ y especialmente: teoría y práctica de Java: compilación dinámica y medición del rendimiento

• .NET usa JIT o NGEN para generar código nativo, pero una vez que se genera el código nativo, no se realizan más optimizaciones (en tiempo de ejecución).

Dejando a un lado los puntos de referencia y sin intención de escalar guerras santas, esto significa que Java Hotspot VM está una generación por delante de .Net. ¿Estas tecnologías empleadas en Java VM eventualmente encontrarán su camino en el tiempo de ejecución de .NET?

Answer 1

Al parecer, alguien estaba trabajando en algo similar para Rotor . No tengo acceso a IEEE, por lo que no puedo leer el resumen.

Recopilación dinámica y optimizaciones guiadas por perfil para un compilador JIT .NET

Cita del resumen ...

Una evaluación del marco utilizando un conjunto de programas de prueba muestra que el rendimiento puede mejorar en un máximo de 42.3% y en un 9% en promedio. Nuestros resultados también muestran que los gastos generales de recopilar información de perfil precisa a través de la instrumentación superan en gran medida los beneficios de las optimizaciones guiadas por perfiles en nuestra implementación , lo que sugiere la necesidad de implementar técnicas que puedan reducir dichos gastos generales.

Answer 2

Nunca comparé los dos para comparar, y estoy más familiarizado con la JVM de Sun, solo puedo hablar en términos generales sobre los JIT.

Siempre hay compensaciones con optimizaciones, y no todas las optimizaciones funcionan todo el tiempo. Sin embargo, aquí hay algunas técnicas modernas de JIT. Creo que este puede ser el comienzo de una buena conversación si nos atenemos a lo técnico:

• análisis de escape
• intrinsics
  • http://bugs.sun.com/view_bug.do?bug_id=6823354
  • http://weblog.ikvm.net/CommentView.aspx?guid=0404dd8a-88a8-4d62-9bcb-98324d57a2a9
• optimización de la llamada final
• reemplazo en la pila
• bloqueo de bloqueo
• bloqueo elision
• recolección de basura multi-hilo
• recolección de basura de baja pausa
• método polimórfico llamada eliminación
• asignación de pila rápida

También hay características que son útiles para las buenas implementaciones de una VM:

• pudiendo elegir entre GC
• Implementación de personalizaciones de cada GC.
• parámetros de asignación de almacenamiento dinámico (como el crecimiento)
• bloqueo de página

Basándonos en estas características y muchas más, podemos comparar máquinas virtuales, y no solo "Java" versus ".NET" sino, por ejemplo, Sun JVM versus IBM JVM versus .NET versus Mono.

Por ejemplo, la JVM de Sun no hace la optimización de llamadas de cola, IIRC, pero la de IBM sí.

Answer 3

Puede estar interesado en SPUR que es un compilador JIT de rastreo. El foco está en javascript pero opera en CIL no en el lenguaje en sí. Es un proyecto de investigación basado en Bartok, no en la máquina virtual .NET estándar. El documento tiene algunos puntos de referencia de rendimiento que muestran que "funciona de manera consistente más rápido que SPUR-CLR", que es el estándar 3.5 CLR. Sin embargo, no ha habido ningún anuncio sobre su futuro relacionado con la VM actual. Las trazas pueden cruzar los límites de los métodos, lo cual no es algo que HotSpot hace AFAIK, se mencionan here JIT de JVM.

No me atrevería a decir que .NET VM es una generación atrasada, especialmente al considerar todos los subsistemas, en particular los genéricos. Cómo se comparan GC / DLR vs invokedynamic no estoy seguro, pero hay muchos detalles sobre ellos en lugares como channel9 .

Answer 4

Siguen dos estrategias diferentes. No creo que una sea mejor que la otra.

• .NET no interpreta el bytecode, por lo que debe ejecutar JIT todo lo que se ejecuta y, por lo tanto, no puede optimizar en gran medida debido a restricciones de tiempo. Si necesita grandes optimizaciones en alguna parte del código, siempre puede NGEN manualmente, o hacer una implementación rápida pero unsafe . Además, llamar código nativo es fácil . El enfoque aquí parece ser obtener el tiempo de ejecución suficientemente bueno y optimizar manualmente los cuellos de botella .

• Las JVM modernas generalmente interpretan la mayoría del código y luego hacen una compilación optimizada de los cuellos de botella. Por lo general, esto obtiene mejores resultados que el JIT directo, pero si necesita más, no tiene unsafe en Java, y llamar código nativo no es bueno . Entonces, el enfoque aquí es hacer la mayor optimización automática posible, porque las otras opciones no son tan buenas .

En realidad, las aplicaciones Java tienden a funcionar ligeramente mejor en el tiempo y peor en el espacio en comparación con .NET.