Hola libertonianos, os comentaré mi experiencia en lo referente a arquitecturas 64-bit.
En mi trabajo estamos portando ciertas aplicaciones de genética a una nueva máquina IBM que saldra este año (aún bajo desarrollo) basada en arquitectura PPC970. Es la denominada pBlade, actualmente ya se pueden encontrar en el mercado, pero solo con procesadores Intel Xeon.
Estas máquinas se venden en tarjetas (tipo Rack empotrado en armarios) y poseen 2 procesadores RISC-PPC970. Además estan siendo diseñadas para llevar GNU/Linux como sistema operativo y unas versiones de GCC o XLC (de IBM) de 64-bits como compiladores por defecto.
Bueno al grano,... Aunque mucha gente piense que la arquitectura de 64-bits ofrece más rendimiento, esto no es siempre cierto. Nosotros hemos estado sacando benchmarks de nuestras aplicaciones portadas, y la mayoria de veces ofrece algo de mejor rendimiento cuando estas se compilan en 32-bits que cuando se hacen en 64-bits.
Para entenderlo mejor, pongamos un ejemplo para la arquitectura PPC970-RISC:
- Imaginemos que tenemos un texto en una zona de memoria X, y conocemos la @ del primer carácter. Esta zona de memoria la veremos mediante una @ de 64-bits (ya que compilamos el programa en arquitectura de 64-bits, por ejemplo usando el flag -m64 de gcc o -q64 de xlc).
msg:
- .string "Hola, libertonianos!\n"
- len = . - msg # Longitud del mensaje
- Pongamos por ejemplo que lo queremos hacer ahora es printar ese mensaje de texto por pantalla. Lo que deberemos hacer es cargar la dirección de memoria del primer carácter en un registro determinado, para luego realizar una llamada a sistema (sc o interrupción software) que nos printe el texto. Veamos como sería esto en código máquina RISC:
En 32-bit:
- lis 4,msg@ha # Cargamos parte alta de @ del mensaje (bits 16-31) en reg 4
- addi 4,4,msg@l # Cargamos 16 bits restantes en parte baja del registro
- li 5,len # Caracteres a printar
- sc # Llamada al kernel (sc o int)
Como vemos nos ha llevado 2 instrucciones cargar una zona de memoria de 32-bits hacia un registro.
Algunos de vosotros os preguntareis, pero porque no carga entonces toda la @ de 32 bits en una única instrucción?
La respuesta es muy sencilla,... por que no se puede, es imposible.
Recordemos que los RISC tienen la limitación de que las instrucciones poseen longitud fija de 32-bits. Por lo tanto si restamos los bits de codigo de operación (lis, li, sc, ...) los bits del identificador del registro y demás tan solo nos quedan 16 bits para la carga del operando. Por ello debemos realizar esta operación en dos fases.
En cambio en 64-bit passa lo siguiente:
- lis 4,msg@highest # Cargamos bits 48-63 en registro 4
- ori 4,4,msg@higher # Cargamos bits 32-47 en registro 4
- rldicr 4,4,32,31 # Shift izq de los bits del reg 4, para cargar el resto
- oris 4,4,msg@h # Cargamos bits 16-31
- ori 4,4,msg@l # Cargamos bits 0-15
- li 5,len
- sc # Printamos el mensaje
Ahora en cambio, hemos necesitado 5 instrucciones para cargar una @ de memoria de 64-bits.
Eso es... de 2 instrucciones (32-bit) hemos pasado a necesitar 5 (64-bit) para cargar la @ en un registro y printar el texto. Consecuencia... ciertos programas se ejecutan ligeramente más lentos.
Por ello mi opinión es: Procesadores de 64-bits? si, pero solo si es realmente necesario (corremos aplicaciones en sistemas multiusuario con un gran consumo de E/S y de memoria).
Si deseamos tener computadores dedicados a realizar, por ejemplo, búsquedas en B.D. o en secuencias genéticas, que pueden llegar a ser realmente grandes (nosotros tratamos con algunas de hasta 9 Gigas) y deseamos que más de un usuario pueda realizar peticiones (más de un programa de búsqueda corriendo) el espacio de memoria es crítico y por lo tanto necesitaremos forzosamente un direccionamiento de 64-bit. En cambio para uso doméstico lo considero, nada más que por ahora, una autentica burrada.
En definitiva en mi casa me sigo quedando con mi arquitectura 32-bit.
Saludos!
"All those moments, will be lost in time like tears in rain..." - Blade Runner
|
