Opinión General sobre Linux 64bits

Alvaro Herrera alvherre en alvh.no-ip.org
Mar Mayo 22 19:48:27 CLT 2007


Matias Valdenegro T. escribió:
> El Lun 21 May 2007, Alvaro Herrera escribió:
> > Horst H. von Brand escribió:
> > > Alvaro Herrera <alvherre en alvh.no-ip.org> wrote:
> > > > Ya, pero cuanto es en un UBench corriendo en un sistema nativo de 32
> > > > bits?  No me sorprenderia que el chroot tenga su costo en tiempo de
> > > > ejecucion (igual no esperaba que fuera un 20%).
> > >
> > > 0%. Exacto. Te lo doy firmado.
> > >
> > > chroot(2) lo unico que hace es cambiar un dato en la estructura del
> > > proceso, que indica donde esta / en el sistema de archivos. Y lo que
> > > hacen a continuacion es tener bibliotecas y demas maquinaria de 32 bits
> > > en ese nuevo ambiente, de forma que programas de 32 bits las encuentren.
> > > Claro, significa cargar mas leseras en RAM (biblitecas de 64 /y/ 32
> > > bits), lo que tendra su impacto indirecto.
> >
> > Hay otro efecto: el de usar bibliotecas de 32 bits que no tienen la
> > posibilidad de usar las mañas especiales de la arquitectura mejorada
> > (mas registros por ejemplo).  Eso no puede tener cero costo.
> 
> Eso no es un costo, es mas que la libreria simplemente no aprovecha todas las 
> gracias de la arquitectura, de hecho precisamente por eso es el benchmark, 
> comparar que ganas teniendo los registros agregados (r8-r16),

Ese es mi punto.  Dado que el ejecutable no puede aprovechar todas las
gracias de la arquitectura, corre mas lento que uno que si puede.  No es
un "costo" pero el resultado final es una disminucion de rendimiento.
Probablemente marginal (no 20%), que es lo que yo decia arriba.

-- 
Alvaro Herrera                          Developer, http://www.PostgreSQL.org/
Tulio: oh, para qué servirá este boton, Juan Carlos?
Policarpo: No, aléjense, no toquen la consola!
Juan Carlos: Lo apretaré una y otra vez.


Más información sobre la lista de distribución Linux