lunes
ene122004
Benchmark de Java vs .NET vs Phyton
lunes, enero 12, 2004 at 1:53AM
Este artículo realiza una comparación entre diversos lenguajes de .Net (C#, J#, Visual C++ y Visual Basic), gcc, Python/Psyco, Python y las máquinas virtuales de Sun 1.3.1 y 1.4.2. Este micro-benchmark aborda cálculos con enteros, long, double, operaciones trigonométricas, y de entrada y salida.
En los resultados la máquina virtual 1.4.2, si no tenemos en cuenta las operaciones trigonométricas, donde es francamente pésima, vence a gcc y está a la par de Visual C++, el mejor lenguaje de .NET. En cuanto a Python/Psyco y Pitón, lenguajes totalmente interpretados, son un orden de magnitud más lentos que los lenguajes compilados. El comportamiento de la máquina virtual 1.4.2 en cuanto a las operaciones trigonométricas es francamente patético (unas tres veces más lento que la 1.3.1!!!). Probablemente se deba a un error en la programación de las rutinas trigonométricas en esa MV.
Como todo microbenchmark este debe tomarse con sumo cuidado, y no generalizar los resultados. Las pruebas sólo atañe a métodos estáticos, no hacen un uso intensivo de reserva y liberación dinámica de memoria, el testeo de la entrada y salida es muy básico, no se mide de ningún modo el rendimiento en multihilo
Y adicionalmente Christopher W. Cowell-Shah, autor de los test no, parece ser un experto en Java; no comprende porqué Java, siendo interpretado, vence a gcc, ya que "ejecutar código en una JVM debería introducir algún tipo de penalización en el rendimiento respecto a ejecutar ensamblador". Obviamente esto no tiene porqué ser así desde el momento que se emplea Hot Spot, ya que se emplea información sólo disponible en tiempo de ejecución para realizar optimizaciones adicionales en el código ensamblador generado por la JVM. También dice que JRockit, la máquina virtual de Bea, podría mejorar notablemente los resultados de Sun, cosa cierta, pero que "sólo está disponible para Windows", cuando JRockit está disponible también para Linux de 32 y 64 bits.
Aquí tenéis los códigos fuentes del benchmark. Yo lo he probado, y a modo de test he mirado como correría en JRockit 8.1 el código del becnhmark. JRockit 8.1 es equivalente a la JVM 1.4.1. Estos son los resultados que obtuve:
JDK de Sun int = 21.3, long = 46.6, double = 54.5, trigonometría = 113, I/O = 18.3, total = 258.
JRockit int = 18, long = 22, double = 52, trigonometría = 25.5, I/O = 15.3, total = 133.
Obviamente mis resultados no se pueden comprar con los del artículo; la máquina en la que se ejecutaron es mucho más lenta, sólo se pueden comparar entre si. No es ninguna noticia que el jdk de Sun no es el más eficiente; siempre es el primero en salir (aún no hay un JRockit equivalente a una JVM 1.4.2), pero no el más eficiente.
Observamos como la mejoría es especialmente notable en el cálculo trigonométrico, lo que refuerza la hipótesis de que se produjo un error en la JVM 1.4.2 de SUN al codificar las rutinas trigonométricas . JRockit, excluyendo las rutinas trigonométricas (sino sería el doble de rápido), emplea sólo un 75% del tiempo que necesita la JVM 1.4.1. Extrapolando esto al benchmark podríamos concluir que JRokit es notablemente más rápido que Visual C++.
¿Qué opináis vosotros de este benchmark y de mi humilde contribución?
En los resultados la máquina virtual 1.4.2, si no tenemos en cuenta las operaciones trigonométricas, donde es francamente pésima, vence a gcc y está a la par de Visual C++, el mejor lenguaje de .NET. En cuanto a Python/Psyco y Pitón, lenguajes totalmente interpretados, son un orden de magnitud más lentos que los lenguajes compilados. El comportamiento de la máquina virtual 1.4.2 en cuanto a las operaciones trigonométricas es francamente patético (unas tres veces más lento que la 1.3.1!!!). Probablemente se deba a un error en la programación de las rutinas trigonométricas en esa MV.
Como todo microbenchmark este debe tomarse con sumo cuidado, y no generalizar los resultados. Las pruebas sólo atañe a métodos estáticos, no hacen un uso intensivo de reserva y liberación dinámica de memoria, el testeo de la entrada y salida es muy básico, no se mide de ningún modo el rendimiento en multihilo
Y adicionalmente Christopher W. Cowell-Shah, autor de los test no, parece ser un experto en Java; no comprende porqué Java, siendo interpretado, vence a gcc, ya que "ejecutar código en una JVM debería introducir algún tipo de penalización en el rendimiento respecto a ejecutar ensamblador". Obviamente esto no tiene porqué ser así desde el momento que se emplea Hot Spot, ya que se emplea información sólo disponible en tiempo de ejecución para realizar optimizaciones adicionales en el código ensamblador generado por la JVM. También dice que JRockit, la máquina virtual de Bea, podría mejorar notablemente los resultados de Sun, cosa cierta, pero que "sólo está disponible para Windows", cuando JRockit está disponible también para Linux de 32 y 64 bits.
Aquí tenéis los códigos fuentes del benchmark. Yo lo he probado, y a modo de test he mirado como correría en JRockit 8.1 el código del becnhmark. JRockit 8.1 es equivalente a la JVM 1.4.1. Estos son los resultados que obtuve:
JDK de Sun int = 21.3, long = 46.6, double = 54.5, trigonometría = 113, I/O = 18.3, total = 258.
JRockit int = 18, long = 22, double = 52, trigonometría = 25.5, I/O = 15.3, total = 133.
Obviamente mis resultados no se pueden comprar con los del artículo; la máquina en la que se ejecutaron es mucho más lenta, sólo se pueden comparar entre si. No es ninguna noticia que el jdk de Sun no es el más eficiente; siempre es el primero en salir (aún no hay un JRockit equivalente a una JVM 1.4.2), pero no el más eficiente.
Observamos como la mejoría es especialmente notable en el cálculo trigonométrico, lo que refuerza la hipótesis de que se produjo un error en la JVM 1.4.2 de SUN al codificar las rutinas trigonométricas . JRockit, excluyendo las rutinas trigonométricas (sino sería el doble de rápido), emplea sólo un 75% del tiempo que necesita la JVM 1.4.1. Extrapolando esto al benchmark podríamos concluir que JRokit es notablemente más rápido que Visual C++.
¿Qué opináis vosotros de este benchmark y de mi humilde contribución?
Reader Comments