OpenJDK es más lento que los binarios propietarios de Oracle en ARM/Linux II
AbrahamRecientemente hemos publicado en el portal una noticia bajo el título "OpenJDK es 5 veces más lento que los binarios propietarios de Oracle en ARM/Linux" en la que se recogían los resultados de un benchmark realizados por un empleado de Oracle. Aunque desde Oracle esto se vende como algo muy positivo, mi análisis era que esta noticia era muy negativa: demuestra la falta de compromiso de Oracle con el mundo opensource y con la implementación opensource de Java.
Tras recibir muchas críticas por la forma en la que se realizó el benchmark, el empleado de Oracle (Jim Connors) ha vuelto a realizar de nuevo un benchmark cuyo propósito es comparar la versión de Java SE-Embedded, tanto la 6 como la 7 con el rendimiento del OpenJDK (la principal crítica del benchmark anteriores que comparaba el rendimiento de Java SE Embede 7 con el OpenJDK 6; en esta ocasión también ha incluido Java SE Embeded 6 para poder realizar una comparación con la misma versión).
En esta ocasión, en vez de emplear un benchmark ad hoc ha empleado uno más estándar (DaCapo). Aquí tenéis los resultados:
Como podéis comprobar, el rendimiento de las versiones de Oracle de Java 6 y 7 es prácticamente idéntico. Y el rendimiento del OpenJDK en este benchmark sigue siendo significativamente inferior, no tanto como cinco veces más lento, pero si está entre un 9% y un 55% más lento. Y encima, el OpenJDK no fue capaz de ejecutar todos los test; en palabras de Jim:
Both OpenJDK instances not only failed to complete certain tests, but also experienced VM aborts too.
Jim sigue vendiendo estos resultados como que la versión de Java de Oracle es mejor, como una medalla para la compañía. Yo lo veo como algo bastante más negativo, ya que demuestra la considerablemente inferior calidad del OpenJDK cuando se le compara con los binarios propietarios de Oracle, y demuestra la falta de compromiso de Oracle con el mundo opensource.
Reader Comments (6)
Esta frase me ha dado que pensar:
"The Java SE 7u2 c2 compiler was also removed because although quite respectable, it did not perform as well as the c1 compilers. Recall that c2 works optimally in long-lived situations."
Me hubiese gustado verlo en acción, aparte de que ya se ha publicado la versión 7u3 hace tiempo.
Sigo pensando que algo no me cuadra, cuando hay tanto interés en dejar fuera a JavaSE 1.7 de las pruebas. Y sigue sin cuadrarme que JavaSE 1 .6 tenga mejor rendimiento que la 1.7 que no se quiere probar, como parece que se sugiere en esa frase.
De todos modos, no creo que se puedan comparar versiones embedded con otras de uso general, como demostración de "algo".
Si acaso, se podrían comparar Hotspot con JRockit, puesto que ambas son de uso general, y ver que ventajas de rendimiento ofrece la versión "comercial" de Oracle, con respecto a la Open Source.
Copio y pego el comentario que hice en su momento.
Un saludo.
--------------------------------------
Mi postura sobre ARM y java SE sigue siendo la misma desde "Vías de acceso a la movilidad".
En cuanto a este tipo de informes no es la primera vez que aparecen (ver también "Java SE Embedded Performance Versus Android 2.2").
De hecho inspirado en este último, hace más de un año, compre un Coby Kyros con el objetivo de instalar Ubuntu ARM con Java SE o romperlo en el intento. En tres ocasiones estuve a punto de lograr uno de mis objetivos (romperlo).
Al final conseguí instalar java SE embedded en otro dispositivo Android y me encontré con la predecible y desagradable realidad.
Aun cuando el tablet tenia pantalla de tacto, acelerómetro y cámara, las aplicaciones java en Linux ARM no empleaban estas características y tenias que conectar un teclado y mouse USB al tablet para poder manejarlas.
Otra historia es que la mayoría de las aplicaciones Swing / AWT / SWT, fueron pensadas y construida sobre procesadores más potentes (desde x86 para arriba) por lo que no están optimizadas para operar en equipos con menores recursos (RAM y procesador) como es el caso de la mayoría de los dispositivos ARM.
¿Mi conclusión?
Si a Oracle, IBM, SAP, Red Hat y al resto de las empresas, que están detrás de Java SE no les importa agregar soporte para los rasgos de una interfaz móvil.
Si no llegan a acuerdos con los fabricantes de OS para dispositivos móviles con el objetivo de que SE venga pre instalado o sea fácil de instalar en estos OS (sin mencionar que estén bien integrado a los OS's móviles y que funcionen de manera optima).
Este tipo de comparativas sirve para lo mismo que el papel sanitario.
@efrigerio
Sí sirven para una cosa: justificar el cobro de licencias de las versiones embedded ;)
Lástima que estas "comparaciones" den la impresión de estar "amañadas".
Lo que buscaba, es un panel de operación para uso industrial, alternativo, de bajo costo, en la línea de esta imagen, y que pudiera programar en java "normal".
¿"Falta de compromiso"? ¿En qué momento dijo Oracle que sacaría su código como abierto? ¿En qué forma encaja eso comercialmente con Oracle? (porque de hacerlo, lo hubiesen sacado ayer). ¿Cómo la posiciona mejor para competir con la JVM de IBM -por ejemplo- y ganar más dinero con ello?
Soy partidario en muchos sentidos del código abierto, pero decir que Oracle no regala el trabajo de sus empleados, gestión, infraestructuras, etc... Pues no, no lo regalan.
Primero decimos que el código abierto es superior. Cuando no es así, pedimos que nos regalen el empresarial...
Sobre Oracle y su posicionamiento sobre Código Abierto:
http://oss.oracle.com/