¿Y no será a que debido a que Java elimina las cosas realmente repugnantes y propensas a errores de C++ el programador se centra en el problema en cuestión y aprovecha mejor su tiempo?
Un ordenador/memoria nuevo tiene un coste ridículo frente al esfuerzo de muchas personas en corregir código C/C++ para hacerlo funcionalmente igual a uno Java. A ver si queremos ejecutar los últimos programas en un 8086 con 128KB de ram, porque incluso en esa máquina los programas en C se ejecutan más lentos que en ensamblador.
Pero esto es una discusión que no lleva a ningún sitio, pues velocidad y facilidad de desarrollo no van por el mismo camino precisamente...
Aunque no te guste que te comenten lo del JIT, ese es el motivo:
A la hora de compilar con C, tu piensas en que máquinas vas a soportar, y le dices al compilador que optimice el programa para el mínimo comun denominador. Sin embargo con java no, compila optimizando para el procesador específico que tienes (o esa es la teoría, no he tocado las tripas).
Ahora, que los programas sean más rápidos los de Java que los de C, es una soberana tontería (olvidándonos que hay gente que usa gentoo, y que para ellos java siempre pierde rendimiento):
El estilo de desarrollo de java hace que los programas sean mucho más lentos, ya que se llegan a hacer herencias de herencias... hasta más de diez veces en algunos casos, se copian bloques gigantescos de memoria sólo para usarlos en alguna función, se hacen cientos de llamadas a la pila, y un larguísimo etcetera.
Sin embargo, el estilo de desarrollo en C tiene en principio más cuidado con esas cosas (Por ejemplo, a la hora de pasar como parámetro una cadena/estructura, se pasa sólo un puntero, y no se anda duplicando las variables como hace java o C++).
Si se programa en Java al mismo estilo que se hace C, es probable que en muchas plataformas java tenga más rendimiento. Ahora si alguien programa en Java como se hace en C, o tiene unas necesidades muy concretas, o tiene muchas ganas de perder el tiempo.
Hay veces que, paradójicamente, añadir capas hace que las cosas vayan más rápido en lugar de más lento. Lo del JIT ya te lo ha explicado bien Hiperion, así que no hablo más de eso. Pero aún hay otra cosa que, aunque parezca añadir complejidad, puede mejorar el rendimiento del programa: la recolección de basura. Sí, la recolección de basura.
Cuando tienes un programa en C de ésos de los que estás orgulloso porque está todo hecho a pelo, sin librerías ni esas mariconadas, y dices "esto tiene que ir como un tiro"... seguramente tengas un montón de mallocs. Los mallocs parecen una forma de gestionar la memoria más sencilla que el recolector de basura, y lo son, ciertamente. Pero resulta que tienes ese código de gestión de memoria repartido en muchas llamadas diversas a la función malloc() a lo largo de todo el código. Por otra parte, si tienes un buen recolector de basura, el código de gestión de memoria está concentrado y ocupará muy poco. Y esto es muy importante, porque quiere decir que puede estar todo en caché.
De ahí que un buen recolector de basura dé mejor rendimiento que los mallocs para programas grandes (también puede uno usar recolectores de basura en C++, claro).
Re:Sobre Java lento en programas de escritorio
(Puntos:0)Y no me cuentes lo del Just in Time, por que por mucho que java compile en ejecución, el programa C++ ya está compilado.
No será que vuestros programadores dominan más el Java que el C++, y por eso le sacan mejor rendimiento?
Re:Sobre Java lento en programas de escritorio
(Puntos:2)Un ordenador/memoria nuevo tiene un coste ridículo frente al esfuerzo de muchas personas en corregir código C/C++ para hacerlo funcionalmente igual a uno Java. A ver si queremos ejecutar los últimos programas en un 8086 con 128KB de ram, porque incluso en esa máquina los programas en C se ejecutan más lentos que en ensamblador.
Pero esto es una discusión que no lleva a ningún sitio, pues velocidad y facilidad de desarrollo no van por el mismo camino precisamente...
Avengers Assemble!!
Re:Sobre Java lento en programas de escritorio
(Puntos:2, Interesante)( http://www.septeto.com/ | Última bitácora: Sábado, 01 Octubre de 2005, 13:34h )
A la hora de compilar con C, tu piensas en que máquinas vas a soportar, y le dices al compilador que optimice el programa para el mínimo comun denominador. Sin embargo con java no, compila optimizando para el procesador específico que tienes (o esa es la teoría, no he tocado las tripas).
Ahora, que los programas sean más rápidos los de Java que los de C, es una soberana tontería (olvidándonos que hay gente que usa gentoo, y que para ellos java siempre pierde rendimiento):
El estilo de desarrollo de java hace que los programas sean mucho más lentos, ya que se llegan a hacer herencias de herencias... hasta más de diez veces en algunos casos, se copian bloques gigantescos de memoria sólo para usarlos en alguna función, se hacen cientos de llamadas a la pila, y un larguísimo etcetera.
Sin embargo, el estilo de desarrollo en C tiene en principio más cuidado con esas cosas (Por ejemplo, a la hora de pasar como parámetro una cadena/estructura, se pasa sólo un puntero, y no se anda duplicando las variables como hace java o C++).
Si se programa en Java al mismo estilo que se hace C, es probable que en muchas plataformas java tenga más rendimiento. Ahora si alguien programa en Java como se hace en C, o tiene unas necesidades muy concretas, o tiene muchas ganas de perder el tiempo.
Re:Sobre Java lento en programas de escritorio
(Puntos:3, Interesante)( http://blog.irreality.eu/ )
Cuando tienes un programa en C de ésos de los que estás orgulloso porque está todo hecho a pelo, sin librerías ni esas mariconadas, y dices "esto tiene que ir como un tiro"... seguramente tengas un montón de mallocs. Los mallocs parecen una forma de gestionar la memoria más sencilla que el recolector de basura, y lo son, ciertamente. Pero resulta que tienes ese código de gestión de memoria repartido en muchas llamadas diversas a la función malloc() a lo largo de todo el código. Por otra parte, si tienes un buen recolector de basura, el código de gestión de memoria está concentrado y ocupará muy poco. Y esto es muy importante, porque quiere decir que puede estar todo en caché.
De ahí que un buen recolector de basura dé mejor rendimiento que los mallocs para programas grandes (también puede uno usar recolectores de basura en C++, claro).
Mi bitácora: Reductio ad Absurdum 2.1 [irreality.eu]