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

[Franco Catrin L.]

Xavier Andrade escribió:
> On Fri, 16 Nov 2007, Franco Catrin L. wrote:
>>
>> 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.
>>
>
> Bueno, por ejemplo si se llama repetidamente a rutinas chicas que hacen
> poco, el rendimiento se reduce en al menos un orden de magnitud en
> comparacion al mismo codigo "inlined".
>
> Es decir:
>
> for(i=0; i<N; i++) a[i] = b[i] + c[i];
>
> es muchisimo mas rapido que
>
> for(i=0; i<N; i++) a[i] = sum(b[i], c[i]);
>
> con double sum(double a, double b){ return a + b;}. Y al final muchos
> codigos OO terminan haciendo cosas por el estilo (probablemente no 
> para este
> ejemplo, claro).
Supongo que es porque rompen el principio de localidad [1].

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.
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 :(

[1] http://en.wikipedia.org/wiki/Locality_of_reference
[2] http://java.sun.com/products/hotspot/docs/general/hs2.html

--
Franco