Como este creo que llevo leidos unos 10, todos mas o menos partidistas lanzando teorias absurdos. Sobre este en particular hay dos puntos "interesantes" a comentar.
El primero la afirmacion de que el rendimiento a gran escala de Java es superior al de C/C++ es sistemas grandes. Evidentemente todo esta basado en hipotesis, porque o nadie ha querido, o ha nadie le ha interesado o nadie ha creido posible desarrollar un sistema de gran escala basado en Java. Ese es de porsi es un argumento que desbarata cualquier afirmacion de ese tipo sobre Java. Pero con ese "pero" aparte, hace bastante gracia ver como alguien puede reconocer que en micro-benchmarks gana C/C++ a Java y sin embargo cuando aumenta la escala se invierten las cartas.
El fulano sustenta tan descabellada teoria basandose en que los programas Java almacenan mas informacion sobre tipos, y que ello "por supuesto" aumenta el rendimiento. ¿?, yo sigo dandole vueltas. El tio ademas se atreve a argumentar que claro eso lo puede aprovechar un compilador inteligente o astuto. Siendo como es la comprobacion de tipos estatica en C/C++ la comparacion resulta absurda. La otra chamacanada es sostener que la optimizacion dinamica puede mejorar el rendimiento de los programas, algo totalmente falso y que ademas tampoco tiene ninguna base. La mera tarea de analizar los bytecodes ya supondria una ralentizacion enorme, jamas seria una mejora respecto de la compilacion estatica. De hecho el JIT de java hace lo contrario, recompila estaticamente para la arquitectura, esta afirmacion es algo erronea pero en esencia es eso.
Las arquitecturas EPIC, exigen un mayor trabajo al compilador para optimizar el codigo, sin embargo como disponen de una salvajada de registros (512 en total en IA64)esa tarea se ve enormemente facilitada, hasta tal punto que con compiladores algo maduros superan en teoria con creces a las arquitecturas tradicionales. La consecuencia es que la compilacion estatica puede buscar las combinaciones mas adecuadas de intrucciones a paralelizar. Dinamicamente el desaprovechamiento seria brutal dado que no habria tiempo para analizar las dependencias entre datos y los emparejamientos. Es como poner a disposicion del usuario un mapa entero de la ciudad y obligarle a ver solo los 10 primeros metros, nunca encontraria el camino optimo.
De todos modos como ya he comentado como este articulo hay un monton mas, aunque tan desafortunados como este he visto pocos. Ojo yo solo he rebatido unos argumentos, no digo que el lenguaje sea malo ni nada por el estilo, Java tiene su sitio, rebuscado, pero lo tiene, al igual que otros muchos lenguajes que no han sido masivamente utilizados como herramienta de marketing. La realidad de Java fuera de los applets y algunas aplicaciones embebidas es a dia de hoy nula, por mucho que se quiera decir lo contrario. De hecho MS ha dejado de incluir la runtime de Java en XP y no ha pasado nada.
Otro triste articulo partidista.
(Puntos:1)
El primero la afirmacion de que el rendimiento a gran escala de Java es superior al de C/C++ es sistemas grandes. Evidentemente todo esta basado en hipotesis, porque o nadie ha querido, o ha nadie le ha interesado o nadie ha creido posible desarrollar un sistema de gran escala basado en Java. Ese es de porsi es un argumento que desbarata cualquier afirmacion de ese tipo sobre Java. Pero con ese "pero" aparte, hace bastante gracia ver como alguien puede reconocer que en micro-benchmarks gana C/C++ a Java y sin embargo cuando aumenta la escala se invierten las cartas.
El fulano sustenta tan descabellada teoria basandose en que los programas Java almacenan mas informacion sobre tipos, y que ello "por supuesto" aumenta el rendimiento. ¿?, yo sigo dandole vueltas. El tio ademas se atreve a argumentar que claro eso lo puede aprovechar un compilador inteligente o astuto. Siendo como es la comprobacion de tipos estatica en C/C++ la comparacion resulta absurda. La otra chamacanada es sostener que la optimizacion dinamica puede mejorar el rendimiento de los programas, algo totalmente falso y que ademas tampoco tiene ninguna base. La mera tarea de analizar los bytecodes ya supondria una ralentizacion enorme, jamas seria una mejora respecto de la compilacion estatica. De hecho el JIT de java hace lo contrario, recompila estaticamente para la arquitectura, esta afirmacion es algo erronea pero en esencia es eso.
Las arquitecturas EPIC, exigen un mayor trabajo al compilador para optimizar el codigo, sin embargo como disponen de una salvajada de registros (512 en total en IA64)esa tarea se ve enormemente facilitada, hasta tal punto que con compiladores algo maduros superan en teoria con creces a las arquitecturas tradicionales. La consecuencia es que la compilacion estatica puede buscar las combinaciones mas adecuadas de intrucciones a paralelizar. Dinamicamente el desaprovechamiento seria brutal dado que no habria tiempo para analizar las dependencias entre datos y los emparejamientos. Es como poner a disposicion del usuario un mapa entero de la ciudad y obligarle a ver solo los 10 primeros metros, nunca encontraria el camino optimo.
De todos modos como ya he comentado como este articulo hay un monton mas, aunque tan desafortunados como este he visto pocos. Ojo yo solo he rebatido unos argumentos, no digo que el lenguaje sea malo ni nada por el estilo, Java tiene su sitio, rebuscado, pero lo tiene, al igual que otros muchos lenguajes que no han sido masivamente utilizados como herramienta de marketing. La realidad de Java fuera de los applets y algunas aplicaciones embebidas es a dia de hoy nula, por mucho que se quiera decir lo contrario. De hecho MS ha dejado de incluir la runtime de Java en XP y no ha pasado nada.