Rendimiento de Java

Las primeras JVM siempre interpretaban los bytecodes de Java . Esto tenía una gran penalización de rendimiento de entre un factor de 10 y 20 para Java en comparación con C en aplicaciones promedio. ^{[ 5 ]} Para combatir esto, se introdujo un compilador justo a tiempo (JIT) en Java 1.1. Debido al alto costo de compilación, se introdujo un sistema adicional llamado HotSpot en Java 1.2 y se convirtió en el predeterminado en Java 1.3. Usando este marco, la máquina virtual de Java analiza continuamente el rendimiento del programa en busca de puntos críticos que se ejecutan con frecuencia o repetidamente. Estos luego son el objetivo de la optimización , lo que lleva a una ejecución de alto rendimiento con una sobrecarga mínima para el código menos crítico en términos de rendimiento. ^{[ 6 ] [ 7 ]} Algunos benchmarks muestran una ganancia de velocidad de 10 veces por este medio. ^{[ 8 ]} Sin embargo, debido a las restricciones de tiempo, el compilador no puede optimizar completamente el programa y, por lo tanto, el programa resultante es más lento que las alternativas de código nativo. ^{[ 9 ] [ 10 ]}

La optimización adaptativa es un método informático que realiza la recompilación dinámica de partes de un programa en función del perfil de ejecución actual. Con una implementación sencilla, un optimizador adaptativo puede simplemente encontrar un equilibrio entre la compilación justo a tiempo y la interpretación de instrucciones. En otro nivel, la optimización adaptativa puede aprovechar las condiciones locales de los datos para eliminar bifurcaciones y utilizar la expansión en línea.

Una máquina virtual Java como HotSpot también puede desoptimizar código previamente compilado con JIT. Esto permite realizar optimizaciones agresivas (y potencialmente inseguras), al tiempo que se puede desoptimizar el código posteriormente y volver a una ruta segura. ^{[ 11 ] [ 12 ]}

Las máquinas virtuales Java (JVM) 1.0 y 1.1 utilizaban un recolector de basura de marcado y barrido , que podía fragmentar el montón después de la recolección de basura. A partir de Java 1.2, las JVM cambiaron a un recolector generacional , que tiene un comportamiento de desfragmentación mucho mejor. ^{[ 13 ]} Las JVM modernas utilizan una variedad de métodos que han mejorado aún más el rendimiento de la recolección de basura . ^{[ 14 ]}

• Java Quick Starter reduce el tiempo de inicio de la aplicación al precargar parte de los datos de JRE en el inicio del sistema operativo en la caché del disco . ^{[ 27 ]}
• Las partes de la plataforma necesarias para ejecutar una aplicación a la que se accede desde la web cuando no está instalado JRE ahora se descargan primero. El JRE completo ocupa 12 MB; una aplicación Swing típica solo necesita descargar 4 MB para comenzar. Las partes restantes se descargan en segundo plano. ^{[ 28 ]}
• El rendimiento gráfico en Windows mejoró al usar ampliamente Direct3D por defecto, ^{[ 29 ]} y usar sombreadores en la unidad de procesamiento gráfico (GPU) para acelerar operaciones complejas de Java 2D . ^{[ 30 ]}

Se han publicado varias mejoras de rendimiento para Java 7: Se planean futuras mejoras de rendimiento para una actualización de Java 6 o Java 7: ^{[ 31 ]}

• Proporcionar soporte de JVM para lenguajes de programación dinámicos , siguiendo el trabajo de prototipado que se está realizando actualmente en la máquina Da Vinci (Máquina Virtual Multilingüe), ^{[ 32 ]}
• Mejorar la biblioteca de concurrencia existente mediante la gestión de la computación paralela en procesadores multinúcleo , ^{[ 33 ] [ 34 ]}
• Permitir que la JVM utilice tanto el compilador JIT del cliente como el del servidor en la misma sesión con un método llamado compilación por niveles: ^{[ 35 ]}
  • El cliente se usaría en la fase de inicio (porque es bueno en la fase de inicio y para aplicaciones pequeñas),
  • El servidor se utilizaría para la ejecución a largo plazo de la aplicación (porque ofrece un rendimiento superior al del compilador del cliente para este fin).
• Reemplazar el recolector de basura concurrente de baja pausa existente (también llamado recolector de marcado y barrido concurrente (CMS)) por un nuevo recolector llamado Garbage First (G1) para garantizar pausas consistentes a lo largo del tiempo. ^{[ 36 ] [ 37 ]}

Los benchmarks suelen medir el rendimiento de programas pequeños con alta carga computacional. En algunos programas reales, Java supera a C. Un ejemplo es el benchmark de Jake2 (un clon de Quake II escrito en Java mediante la traducción del código C original bajo licencia GPL ). La versión de Java 5.0 ofrece un mejor rendimiento en algunas configuraciones de hardware que su contraparte en C. ^{[ 42 ]} Si bien no se especifica cómo se midieron los datos (por ejemplo, si se utilizó el ejecutable original de Quake II compilado en 1997, lo cual podría considerarse deficiente, ya que los compiladores de C actuales podrían lograr mejores optimizaciones para Quake), se observa cómo el mismo código fuente de Java puede experimentar un enorme aumento de velocidad simplemente actualizando la máquina virtual, algo imposible de lograr con un enfoque completamente estático.

Para otros programas, la contraparte en C++ puede, y generalmente lo hace, ejecutarse significativamente más rápido que su equivalente en Java. Una prueba de rendimiento realizada por Google en 2011 mostró una diferencia de un factor de 10 entre C++ y Java. ^{[ 43 ]} En el otro extremo, una prueba de rendimiento académica realizada en 2012 con un algoritmo de modelado 3D mostró que la JVM de Java 6 era entre 1,09 y 1,91 veces más lenta que C++ en Windows. ^{[ 44 ]}

Algunas optimizaciones que son posibles en Java y lenguajes similares pueden no ser posibles en ciertas circunstancias en C++: ^{[ 45 ]}

• El uso de punteros al estilo C puede dificultar la optimización en lenguajes que admiten punteros,
• El uso de métodos de análisis de escape es limitado en C++ , por ejemplo, porque un compilador de C++ no siempre sabe si un objeto será modificado en un bloque de código dado debido a los punteros , ^{[ nota 1 ]}
• Java puede acceder a los métodos de instancia derivados más rápidamente que C++ a los métodos virtuales derivados debido a la búsqueda adicional en la tabla virtual de C++. Sin embargo, los métodos no virtuales en C++ no sufren cuellos de botella de rendimiento relacionados con la tabla virtual y, por lo tanto, presentan un rendimiento similar al de Java.

La JVM también es capaz de realizar optimizaciones específicas del procesador o expansión en línea . Además, la capacidad de desoptimizar código ya compilado o expandido en línea a veces le permite realizar optimizaciones más agresivas que las realizadas por lenguajes de tipado estático cuando intervienen funciones de bibliotecas externas. ^{[ 46 ] [ 47 ]}

Los resultados de las micropruebas comparativas entre Java y C++ dependen en gran medida de las operaciones que se comparen. Por ejemplo, al comparar con Java 5.0:

• Las operaciones aritméticas de 32 y 64 bits, ^{[ 48 ] [ 49 ]} la entrada/salida de archivos , ^{[ 50 ]} y el manejo de excepciones ^{[ 51 ]} tienen un rendimiento similar al de programas C++ comparables.
• Las operaciones en matrices ^{[ 52 ]} tienen un mejor rendimiento en C.
• El rendimiento de las funciones trigonométricas es mucho mejor en C. ^{[ 53 ]}

Notas

La escalabilidad y el rendimiento de las aplicaciones Java en sistemas multinúcleo están limitados por la tasa de asignación de objetos. Este efecto se conoce a veces como "pared de asignación". ^{[ 54 ]} Sin embargo, en la práctica, los algoritmos modernos de recolección de basura utilizan múltiples núcleos para realizar la recolección, lo que en cierta medida alivia este problema. Se ha informado que algunos recolectores de basura soportan tasas de asignación superiores a un gigabyte por segundo, ^{[ 55 ]} y existen sistemas basados ​​en Java que no tienen problemas para escalar a varios cientos de núcleos de CPU y montones de varios cientos de GB. ^{[ 56 ]}

La gestión automática de memoria en Java permite un uso eficiente de estructuras de datos inmutables y sin bloqueo, cuya implementación resulta extremadamente difícil, o incluso imposible, sin algún tipo de recolección de basura. Java ofrece varias de estas estructuras de alto nivel en su biblioteca estándar, en el paquete java.util.concurrent, mientras que muchos lenguajes utilizados históricamente para sistemas de alto rendimiento, como C o C++, aún carecen de ellas.

El tiempo de inicio de Java suele ser mucho más lento que el de muchos otros lenguajes, como C , C++ , Perl o Python , porque muchas clases (y, sobre todo, las clases de las bibliotecas de clases de la plataforma ) deben cargarse antes de poder utilizarse.

En comparación con entornos de ejecución populares similares, para programas pequeños que se ejecutan en una máquina Windows, el tiempo de inicio parece ser similar al de Mono y un poco más lento que el de .NET . ^{[ 57 ]}

Parece que gran parte del tiempo de inicio se debe a operaciones de entrada/salida (E/S) en lugar de a la inicialización de la JVM o la carga de clases (el archivo de datos de clase rt.jar por sí solo ocupa 40 MB y la JVM debe buscar muchos datos en este archivo grande). ^{[ 27 ]} Algunas pruebas mostraron que, si bien el nuevo método de verificación de bytecode dividido mejoró la carga de clases en aproximadamente un 40 %, solo logró una mejora de inicio de alrededor del 5 % para programas grandes. ^{[ 58 ]}

Si bien se trata de una pequeña mejora, es más visible en programas pequeños que realizan una operación simple y luego finalizan, ya que la carga de datos de la plataforma Java puede representar muchas veces la carga de la operación real del programa.

A partir de Java SE 6 Update 10, el JRE de Sun incluye una herramienta de inicio rápido que precarga los datos de clase al arrancar el sistema operativo para obtener los datos de la caché del disco en lugar de hacerlo directamente del disco.

Excelsior JET aborda el problema desde otra perspectiva. Su optimizador de inicio reduce la cantidad de datos que deben leerse del disco al iniciar la aplicación y hace que las lecturas sean más secuenciales.

En noviembre de 2004, se lanzó públicamente Nailgun , un "cliente, protocolo y servidor para ejecutar programas Java desde la línea de comandos sin incurrir en la sobrecarga de inicio de la JVM". ^{[ 59 ]} Introdujo por primera vez una opción para que los scripts usaran una JVM como demonio , para ejecutar una o más aplicaciones Java sin la sobrecarga de inicio de la JVM. El demonio Nailgun es inseguro: "todos los programas se ejecutan con los mismos permisos que el servidor". Cuando se necesita seguridad multiusuario , Nailgun es inapropiado sin precauciones especiales. Los scripts donde el inicio de la JVM por aplicación domina el uso de recursos, ven mejoras en el rendimiento de tiempo de ejecución de uno a dos órdenes de magnitud . ^{[ 60 ]}

El uso de memoria de Java es mucho mayor que el de C++ porque:

• En Java, existe una sobrecarga de 8 bytes por cada objeto y de 12 bytes por cada matriz ^{[ 61 ]} . Si el tamaño de un objeto no es múltiplo de 8 bytes, se redondea al siguiente múltiplo de 8. Esto significa que un objeto que contiene un campo de un byte ocupa 16 bytes y necesita una referencia de 4 bytes. C++ también asigna un puntero (generalmente de 4 u 8 bytes) para cada objeto cuya clase declara funciones virtuales , directa o indirectamente . ^{[ 62 ]}
• La falta de aritmética de direcciones hace que la creación de contenedores eficientes en memoria, como estructuras con espaciado reducido y listas enlazadas XOR , sea actualmente imposible ( el proyecto OpenJDK Valhalla pretende mitigar estos problemas, aunque no pretende introducir aritmética de punteros; esto no se puede hacer en un entorno con recolección de basura).
• A diferencia de malloc y new, la sobrecarga de rendimiento promedio de la recolección de basura se acerca asintóticamente a cero (más precisamente, a un ciclo de CPU) a medida que aumenta el tamaño del montón. ^{[ 63 ]}
• Partes de la biblioteca de clases de Java deben cargarse antes de la ejecución del programa (al menos las clases utilizadas dentro de un programa). ^{[ 64 ]} Esto genera una sobrecarga de memoria significativa para aplicaciones pequeñas.
• Tanto la recompilación del binario de Java como la del código nativo normalmente se realizarán en memoria.
• La máquina virtual utiliza una cantidad considerable de memoria.
• En Java, un objeto compuesto (una clase A que utiliza instancias de B y C) se crea mediante referencias a instancias asignadas de B y C. En C++, el coste en memoria y rendimiento de este tipo de referencias se puede evitar cuando la instancia de B y/o C existe dentro de A.

En la mayoría de los casos, una aplicación C++ consumirá menos memoria que una aplicación Java equivalente debido a la gran sobrecarga de la máquina virtual de Java, la carga de clases y el redimensionamiento automático de memoria. Para programas en los que la memoria es un factor crítico a la hora de elegir entre lenguajes y entornos de ejecución, es necesario realizar un análisis de costo-beneficio.

El rendimiento de las funciones trigonométricas es malo en comparación con C, porque Java tiene especificaciones estrictas para los resultados de las operaciones matemáticas, que pueden no corresponderse con la implementación de hardware subyacente. ^{[ 65 ]} En el subconjunto de punto flotante x87 , Java desde la versión 1.4 realiza la reducción de argumentos para seno y coseno en software, ^{[ 66 ]} causando una gran pérdida de rendimiento para valores fuera del rango. ^{[ 67 ]}

La Interfaz Nativa de Java (JNI ) genera una sobrecarga elevada, lo que dificulta cruzar el límite entre el código que se ejecuta en la JVM y el código nativo. ^{[ 68 ] [ 69 ] [ 70 ]} El Acceso Nativo de Java (JNA) proporciona a los programas Java un acceso sencillo a las bibliotecas compartidas nativas ( bibliotecas de vínculos dinámicos (DLL) en Windows) únicamente mediante código Java, sin JNI ni código nativo. Esta funcionalidad es comparable a Platform/Invoke de Windows y ctypes de Python . El acceso es dinámico en tiempo de ejecución sin generación de código. Sin embargo, tiene un coste, y JNA suele ser más lento que JNI. ^{[ 71 ]}

Swing se ha considerado más lento que los kits de herramientas de widgets nativos , ya que delega la representación de widgets a la API 2D pura de Java . Sin embargo, las pruebas comparativas que comparan el rendimiento de Swing con el Kit de herramientas de widgets estándar , que delega la representación a las bibliotecas GUI nativas del sistema operativo, no muestran un claro ganador, y los resultados dependen en gran medida del contexto y los entornos. ^{[ 72 ]} Además, el nuevo framework JavaFX , diseñado para reemplazar a Swing, aborda muchos de los problemas inherentes de Swing.

Algunas personas creen que el rendimiento de Java para la computación de alto rendimiento (HPC) es similar al de Fortran en pruebas de rendimiento intensivas en cómputo, pero que las JVM todavía tienen problemas de escalabilidad para realizar comunicaciones intensivas en una red de computación en malla . ^{[ 73 ]}

Sin embargo, las aplicaciones de computación de alto rendimiento escritas en Java han ganado competiciones de evaluación comparativa. En 2008, ^{[ 74 ]} y 2009, ^{[ 75 ] [ 76 ]} un clúster basado en Apache Hadoop (un proyecto de computación de alto rendimiento de código abierto escrito en Java) fue capaz de ordenar un terabyte y un petabyte de enteros más rápidamente. Sin embargo, la configuración de hardware de los sistemas participantes no era fija. ^{[ 77 ] [ 78 ]}

Los programas en Java se inician más lentamente que los de otros lenguajes compilados. ^{[ 79 ] [ 80 ]} Por lo tanto, algunos sistemas de evaluación en línea, especialmente los alojados por universidades chinas, utilizan límites de tiempo más largos para los programas Java ^{[ 81 ] [ 82 ] [ 83 ] [ 84 ] [ 85 ]} para ser justos con los concursantes que utilizan Java.