Es amd64 para servidor en produccion ?

[Daniel Serpell]

Hola!

El Mon, Jul 07, 2008 at 01:46:35PM -0400, Aldrin Martoq escribio:
> 
[...]
> Ambos mundos 32bits y 64 bits tienen ventajas y desventajas respecto de
> las aplicaciones actuales.
> 
> Por lo tanto, lo que digo es que no deberiamos tener distros 64bits y
> otras 32bits; sino que el default debiera ser 32bits y solo las
> aplicaciones que se beneficien tengan la opcion 64bits.
> 

Lamentablemente, eso no es tan simple como parece.

Pese a que los vendedores de CPUs quieren hacer creer lo contrario, los
modos de 64 bits y 32 bits *no* son compatibles entre ellos en la
arquitectura.

Si el núcleo (código a nivel supervisor) corre en modo 32 bits, no se
puede ejecutar código de usuario en 64 bits. Por esto, si quieres tener
aplicaciones de 64 bits, necesitas un núcleo de 64 bits - esto es un
kernel compilado para AMD64.

Ahora viene el segundo problema: los controladores de hardware que
corren en el núcleo deben estár compilados también para AMD64. Esto
significa que los que utilizan drivers binarios deben conseguir estos
drivers para 64bits.

Luego de convertir el núcleo y los drivers, viene el problema número 3:
las aplicaciones que acceden al hardware desde modo usuario también
necesitan saber que el núcleo es de 64 bits - es el caso del X.

Esto es necesario ya que la CPU ve al hardware de manera distinta cuando
se encuentra en modo 64 bits - la principal diferencia es que al ser
mayor el rango de direcciones el hardware se mapea a travez de una MMU
de entrada/salida - la IOMMU.

Bueno, por lo pronto tenemos entonces:

 * Kernel de 64 bits.
 * Drivers de 64 bits.
 * X en 64 bits
 * Bibliotecas del X (para que X funcione) de 64 bits.

Todo esto en RAM, utilizando recursos.

¿Para qué entonces quieres ahora tener alguna aplicación en 32 bits?

Si es por compatibilidad, eso no es problema. Las aplicaciones normales
de 32 bits corren sin problema, basta tener instaladas las bibliotecas
de 32 bits al lado de las de 64.

Si es por velocidad, las aplicaciones compiladas nativamente para 64
bits son más rápidas, sobre todo porque la ABI de 64 bits es mejor -
permite el paso de más argumentos en registros y utiliza los registros
de XMM para punto flotante, no el stack de FPU antiguo.

Si es por tamaño del código - algo sensible si se pretende maximizar la
utilización de los cachés L1 de la CPU - en realidad ahorras un 20% en
promedio - un ejemplo con un pequeño programa:

 $ gcc -m64 -O2 -fomit-frame-pointer -Wall -c -o ff-x86-64.o ff.c
 $ gcc -m32 -O2 -fomit-frame-pointer -Wall -c -o ff-x86.o ff.c
 $ size ff-x86*
    text   data    bss    dec    hex filename
   11960      0     18  11978   2eca ff-x86-64.o
   10067      0     10  10077   275d ff-x86.o

Finalmente, todo se reduce a:

* El plugin propietario de Flash que no funciona bien en 64 bits:
  Al menos en mi casa parece funcionar bien (osea, igual de mal que en
  mode 32 bits) en Ubuntu 8.04.

* El soporte de drivers para cierto hardware:
  Idem, al menos en mi caso todo el hardware anda bien.

* Aplicaciones muy antiguas, que hacen suposiciones acerca del hardware
  específicas (mencionabas Linuxthreads).
  En modo 64 bits, debido a las incompatibilidades de la arquitectura,
  ni modo :-(

-------------

PD: Respecto al soporte de más memoria utilizando PAE, la principal
desventaja es que para el I/O debes tener buffers en memoria baja para
realizar DMA desde los dispositivos. Eso implica que el kernel debe
mover memoria de un lado a otro para llenar la "memoria alta" desde
disco o red - bastante costoso en rendimiento.

-------------

     Daniel.