Re: Benchmarking en distintos lenguajes [ Era algo así como cliente en jabber... ]

[Franco Catrin L.]

Rodrigo Fuentealba escribió:
>> La máquina virtual de Java igual te va a compilar el código a código de
>> máquina y eso es lo que va a ejecutar, se demorará la primera vez pero
>> en los casos en donde importa el rendimiento (loops) sólo se hace al
>> principio.  El byte-code no es código interpretado, es código de máquina
>> para una máquina virtual (oh!).
>>     
>
> O sea... es algo así como los compilados de cobol que después tenías
> que ejecutarlos con runcobol...
>   
Segun entiendo esos no son compilados reales, runcobol es un interprete, 
no una maquina virtual.
Tanto Java como .NET utilizan codigo de maquina independiente de la 
máquina, pero es código de máquina al fin (stack, registros, etc).  Es 
por eso que no es dificil aplicar JIT o incluso compilacion previa (GCJ 
en Java o -aot en Mono).

>> Hay algunas cosas que funcionan más rápido en Java pero no por un tema
>> de compiladores, sino que por otros aspectos como por ejemplo el
>> mecanismo de Garbage Collection que funciona de forma asincrona (pero no
>> en paralelo).
>>     
>
> Estuve viendo eso relacionado con Microsoft.NET; jamás se me ocurrió
> aplicar eso a Java. Bueeena!
>   

Sumale eso a que cuando hay suficiente RAM puede funcionar muy bien.  
Piensa en un simple "add" de un puntero al pedir memoria.  Un par de 
lecturas interesantes:

http://www.ibm.com/developerworks/java/library/j-jtp11253/
http://www.ibm.com/developerworks/java/library/j-jtp09275.html

>> El tema de por qué las aplicaciones en Java funcionan lento tiene varias
>> causas, desde complejidad en exeso en el diseño de aplicaciones hasta el
>> uso y abuso de conceptos avanzados de  Estupidez Artificial y Lógica
>> Confusa ;)
>>     
>
> jajajajajaja yeah. Creo que los programadores Java se engrupen mucho
> con lo difíciles que pueden llegar a ser sus aplicaciones; alguien me
> comentó que, de hecho, el inventor de la programación orientada a
> objetos se hizo netamente con el objetivo de ganar más plata nada más.

Yo creo que eso es una leyenda urbana como una entrevista que vi por ahi 
al creador de C++ (AFAIR).
La programación orientada a objetos es de gran ayuda, incluso el kernel 
de Linux es orientado a objetos!

El problema esta cuando el nivel de abstracción te oculta lo que esta 
sucediendo por debajo, y se hacen cosas demás en forma involuntaria.  
Recuerdo que Federico Mena comentaba que muchos problemas de performance 
se habian resuelto simplemente aplicando strace para ver qué estaba 
sucediendo por debajo y ahi encontraron que en aplicaciones como 
OpenOffice (y tambien en GNOME) se abrian y procesaban archivos 
inmutables una y otra vez, en vez de una sola vez al principio.  Es 
facil tener ese problema, cuando las aplicaciones crecen y tienes una 
gran base de código te comienzas (al fin) a enfocar mas en el qué y no 
en el cómo, pero si te descuidas comienzas a mal usar lo que ya tienes.

Tambien hay casos en que la gente no sabe ni le interesa lo que sucede 
por debajo y hacen grandes desastres de aplicaciones, al final le echan 
la culpa a la complejidad del problema, al lenguaje o a la máquina, pero 
objetivamente los problemas que solucionan la mayoria de las 
aplicaciones no son complejos.


--
Franco