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

[Xavier Andrade]

On Fri, 16 Nov 2007, Franco Catrin L. wrote:
>
> Supongo que es porque rompen el principio de localidad [1].
>

Principalmente es el costo asociado a llamar una funcion, el paso de
argumentos, guardar registros, etc.

>
> Yo me refería a otros casos pero igual es interesante:
> La máquina virtual de Java puede aplicar inline en algunos métodos siempre 
> y cuando estos métodos no sean sobreescritos, por ejemplo todos aquellos que 
> sean static o final... pero... además en tiempo de ejecución puede deducir 
> que un método puede ser "inlined" de forma segura, porque ya sabe que no 
> esta sobreescrito. De esta forma el programador no necesita cambiar su 
> código y es la máquina virtual quien se hace la astuta, lo malo es que hay 
> programadores que declaran todo como public. [2]
>
> Si no me equivoco los compiladores de C tambien son capaces de reconocer 
> código que conviene dejar como inline.

El problema es que en C, a diferencia de Java, la mayoria de las veces no se
tiene el codigo que se podria hacer inline. A veces no se sabra que funcion
es hasta el momento de la ejecucion (punteros a funciones o funciones
virtuales en C++)

De hecho, algunos compiladores de C/C++ o Fortran en los niveles de
optimizacion mas agresivos (normalmente con el flag -ipa), no compilan el
codigo al generar los .o, sino que al momento de enlazar juntan todas la
fuentes haciendo un analisis completo de la ejecucion para ver que se puede
hacer inline (entre otras optimizaciones), por supuesto esto toma mucho
tiempo y consume cantidades obscenas memoria.

> Y finalmente.. los problemas de rendimiento en aplicaciones de las que me 
> toca ver a mi casi siempre son debido a latencias por I/O :(
>

Bueno, si. Lo que yo menciono se da mas en codigo numerico orientado al
objeto donde la optimizacion a nivel de ejecucion en el procesador cuenta.

Saludos,

Xavier