[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Java es lento
- To: mindfood@xxxxxxxxxxxxxxx
- Subject: Java es lento
- From: Rafael Luque Leiva <rafael.luque@xxxxxxxxxxxxxxx>
- Date: Tue, 07 Feb 2006 22:55:02 +0100
- Delivered-to: mailing list mindfood@orange-soft.com
- Delivered-to: moderator for mindfood@orange-soft.com
- Mailing-list: contact mindfood-help@orange-soft.com; run by ezmlm
- Organization: Orange Soft
- User-agent: Mozilla Thunderbird 1.0.7 (X11/20050923)
Hola,
Últimamente he escuchado a varias personas quejarse de que "Java es lento". No es de extrañar, puesto que en mi opinión se trata de un mito bastante extendido entre los desarrolladores. El objetivo de este mail es explicar no sólo porqué esto no es cierto, sino que en realidad se podría decir (en términos generales) que *Java puede ser más rápido que C* [1].
Como muchos sabréis, Java proclama el "write once, run anywhere" (WORA) como uno de sus grandes logros. Esto significa que el código que se escribe puede ejecutarse directamente en una gran variedad de plataformas. Gracias a que las especificaciones del lenguaje están claramente definidas, normalmente se puede esperar que el código Java que escribes se pueda ejecutar en cualquier otra plataforma distinta a la de desarrollo. Por ejemplo, en mi caso escribo y compilo código en mi PC con GNU/Linux que luego se ejecuta en arquitecturas RISC con HP-UX o Tru64.
Para lograr esto el código Java no se compila directamente al código máquina nativo de una plataforma concreta, sino a un lenguaje intermedio común denominado bytecode, que es ejecutado por la máquina virtual Java (JVM). Las primeras versiones de JVM interpretaban los bytecodes. En aquel entonces Java era verdaderamente lento en comparación con los
lenguajes compilados. Quizá por este motivo, existe la creencia errónea de que Java es un lenguaje interpretado. Actualmente (desde Java 1.2), las JVM compilan los bytecodes a código máquina según los van ejecutando, con lo que en realidad *Java ES COMPILADO* y no debería sorprender que sea tan rápido como cualquier otro lenguaje compilado.
Llegados a este punto, las diferencias de velocidad las marcan los compiladores. El rendimiento dependerá de lo evolucionados que éstos sean y de las optimizaciones que puedan introducir al traducir el código de alto nivel (bytecode, C o MSIL) a las instrucciones del procesador en el que se ejecute. Por ejemplo, uso de registros en lugar de acceso a memoria para variables usadas frecuentemente, poner inline funciones pequeñas y de uso frecuente, eliminar código no utilizado, etc.
Diversos benchmarks que comparan Java frente a C o C++ confirman que Java tiene un rendimiento comparable, cuando no mejor, que el de estos últimos. El artículo "Performance of Java versus C++" [2] recoge 5 de estos benchmarks.
Sin embargo, si Java es un lenguaje compilado como C, ¿cómo es posible que pueda llegar a ser más rápido? Porque Java se beneficia de una tecnología de compilación diferente. La JVM utiliza compiladores dinámicos o JIT (Just-in-time) que generan código máquina en tiempo de ejecución. Mientras que en el caso de C se utilizan los tradicionales compiladores estáticos (p.ej. gcc).
Aquí es donde radica la ventaja de Java. Por un lado, los compiladores dinámicos pueden obtener información muy importante en tiempo de ejecución (sobre el procesador utilizado y sobre el código concreto compilado) que les permite realizar importantes optimizaciones que a un compilador convencional le resultan imposibles. Por otra parte, da la sensación de que los precompiladores ya realizan el mejor trabajo posible, no existiendo margen para mejorarlos, mientras que los compiladores dinámicos evolucionan contínuamente, mejorando su rendimiento en cada nueva versión de JVM.
Esto explica los resultados obtenidos en el estudio "Nine Language Performance Round-up: Benchmarking Math & File I/O" [3] publicado en la revista OSNews, al comparar código ejecutado en JVM 1.4.2 con el código C equivalente compilado con gcc:
"Java 1.4.2 performed as well as or better than the fully compiled gcc C benchmark (...) since it only seems logical that running bytecode within a JVM would introduce some sort of performance penalty relative to native machine code. But for reasons unclear to me, this seems not to be true for these tests."
Como veis el autor de este estudio no consigue explicarse los resultados :-)
[1] http://portal.acm.org/citation.cfm?id=345105.352548
[2] http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
[3] http://www.osnews.com/story.php?news_id=5602
Un saludo,
Rafa
--
Rafael Luque Leiva
Desarrollador de software
Orange Soft - http://www.orange-soft.com
Creando software para las personas
Urbanización Las Castañeras
Arroyo de los Combos, 26 bis
Arroyomolinos, E28939 Madrid
Tel: +34 916 091 075
+34 605 511 847 (móvil)
Fax: +34 916 091 075
GnuPG Key ID: 0x4B9238A2