.NET runtime vs. Java Hotspot: ¿Está .NET una generación atrás?

Question

De acuerdo con la información que pude reunir el entorno de ejecución de Java y .NET, el estado actual de las cosas es el siguiente:

• moderna máquina virtual de Java son capaces de realizar recopilación continua, lo que combinado con perfiles pueden producir un gran rendimiento mejoras. 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: Java theory and practice: Dynamic compilation and performance measurement

• .NET utiliza JIT o NGEN para generar código nativo, pero una vez que se genera el código nativo, no más lejos se llevan a cabo (tiempo de ejecución) optimizaciones.

puntos de referencia a un lado y con la intención de escalar la guerra santa, ¿significa esto que Java HotSpot VM es una generación por delante de .Net. ¿Acaso estas tecnologías empleadas en Java VM finalmente llegarán al tiempo de ejecución de .NET?

Answer 1

Nunca comparé los dos para comparar, y estoy más familiarizado con Sun JVM, 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 JIT modernas.Creo que esto puede ser el comienzo de una buena conversación si nos ceñimos a la parte técnica:

• 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
• tail-call optimization
• en la pila replacemen t
• engrosamiento de bloqueo
• lock elision
• -multi-hilo de basura recogida
• bajo pausa de recolección de basura
• polymorphic method call removal
• fast heap allocation

También hay características que son útiles en la medida de tan buena implementaciones de una VM ir:

• ser capaz de recoger entre GC
• implementaciones personalización de cada GC
• parámetros asignación del montón (tales como el crecimiento)
• página de bloqueo

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

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

Answer 2

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

Dynamic recompilation and profile-guided optimisations for a .NET JIT compiler

Presupuesto de Resumen ...

Una evaluación del marco utilizando un conjunto de programas de prueba muestra que puede mejorar el rendimiento por un máximo del 42,3% y por 9% en promedio. Nuestros resultados también muestran que los gastos generales de recogida de perfil exacto información a través de la instrumentación de un grado mayor que los beneficios de optimizaciones guiada por perfiles en nuestra aplicación, lo que sugiere la necesidad para la aplicación de técnicas que pueden reducir tales gastos generales .

Answer 3

Siguen dos estrategias diferentes. No creo que uno sea mejor que el otro.

• .NET no interpretar el código de bytes, por lo que tiene que JIT todo como está será ejecutado y por lo tanto no se puede optimizar en gran medida por falta de tiempo. Si necesita optimizaciones pesadas en alguna parte del código, siempre puede NGENERLO manualmente o realizar una implementación rápida pero unsafe. Además, calling native code is easy. El enfoque aquí parece ser conseguir el tiempo de ejecución lo suficientemente bueno y optimizar manualmente los cuellos de botella.

• Las JVM modernas generalmente interpretarán la mayor parte del código, y luego realizarán una compilación optimizada de los cuellos de botella. Esto generalmente obtiene mejores resultados que el JIT directo, pero si necesita más, no tiene unsafe en Java y calling native code is not nice. Por lo tanto, el enfoque aquí es hacer la mayor optimización automática posible, porque las otras opciones no son tan buenas.

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

Answer 4

Puede estar interesado en SPUR que es un compilador de JIT de seguimiento. El foco está en javascript, pero opera en CIL, no en el idioma 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 'consistentemente realiza 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 en relación con la VM actual. Las trazas pueden cruzar los límites del método, lo que no es algo que HotSpot hace AFAIK, los JIT de rastreo de JVM se mencionan here.

No me atrevo a decir que .NET VM tiene una generación de retraso, especialmente cuando se consideran todos los subsistemas, en particular los genéricos. Cómo comparar GC y DLR vs invookedynamic No estoy seguro, pero hay muchos detalles sobre ellos en lugares como channel9.