y dale
A riesgo de acaparar la portada de Libertonia, allá vamos otra vez: ¿alguien necesita realmente un procesador de 64 bits? ¿Para qué exactamente? En la primera parte ya vimos que los procesadores AMD Athlon 64 eran más eficientes que los Pentium 4; que otros fabricantes (desde los Alpha de DEC a principios de los 90 hasta IBM en 2001 con el G5) han pasado ya por ahí; y que hasta Intel ha copiado el juego de instrucciones y lo ha llamado EM64T (cosa que por cierto irritó bastante a Linus Torvalds).
Otras familias de 64 bits han llegado y se han marchitado; pero los amd64 parece que están triunfando sin reservas. ¿Es por necesidad, por conveniencia, o por tontería humana?
pura matemática
Hay aplicaciones que se quedan cortas con 32 bits. ¿Cuándo se necesitan 64 bits sin más remedio?
32 bits dan para contar hasta 4 294 967 296; es decir, poco más de cuatro mil millones. Son exactamente 4 gigabytes de capacidad, abreviado como 4 GB.
Para hacer la cuenta de la vieja, basta recordar que añadir 10 bits es como multiplicar por un factor de 1024, poco más de 1000. Por tanto, añadir 30 bits será como multiplicar tres veces por un poco más de 1000, es decir por mil millones; y nos quedan 2 bits que son 4. En total, 4 x 1000 x 1000 x 1000 = cuatro mil millones, y nos quedamos pelín cortos.
Según la IEC se trataría de "gibibytes" o GiB, pero aborrezco esta palabreja. No creo que pase nada por usar factores diferentes para bytes que para kilos, pero todo sea por la precisión; donde digo GB, leed GiB.
En la tierra somos oficialmente más de seis mil millones; así que si quisiéramos usar un registro de 32 bits para contar a todos los habitantes del mundo mundial nos quedaríamos cortos. En general, nuestro pentium 4 o nuestro K7 no saben contar hasta más de 4 GB. ¿Cómo es que podemos usar discos duros de más de 4 GB?
Aviso: lo que sigue es una ilustración simplificada del formato de discos HFS de Apple, porque es el que mejor conozco; seguramente el formato ext2 funcione de forma similar. De todas formas, si buscáis rigor mirad en la wikipedia.
La respuesta es sencilla: gracias al truco del almendruco. Lo primero que se hace es dividir el disco en bloques lógicos de varios bytes; en HFS eran de 512 bytes. Luego se agrupan estos bloques en unidades de asignación, en número variable para cada disco: tantos bloques lógicos dan una unidad de asignación. Como el valor es de 16 bits, como mucho podemos tener 65535 bloques lógicos por unidad de asignación. A su vez, el número de unidad de asignación se manipula como un valor de 16 bits, lo que da para direccionar sólo 65536 unidades de asignación.
Pero esto quiere decir que en total tenemos más de 4 GB. Así que, al recorrer un fichero, es necesario guardar por separado la unidad de asignación donde nos encontramos (16 bits), el bloque lógico dentro de la unidad (otros 16 bits) y la posición dentro del bloque (512 valores, o sea 9 bits). Para manejarnos por el disco necesitaremos tres registros de 16 bits; como mucho podríamos agrupar dos de estos valores en un solo registro de 32 bits, y el otro suelto.
Y lo que es peor, el tamaño de la unidad de asignación fue creciendo; cuando los discos duros de 6 GB se volvieron comunes, la 65536-ava parte era ya de casi 100 kB, tamaño mínimo que ocupaban los ficheros: un desperdicio. En un momento dado Apple tuvo que modificar radicalmente el formato para permitir ficheros de más de 4 GB y aprovechar mejor el espacio, lo que nos trajo el formato HFS+. Ahora ya es necesario usar explícitamente tres registros de 32 bits para recorrer un fichero, aunque este manejo lo realiza el sistema operativo. Nuestro programa verá el fichero como una secuencia ininterrumpida de bytes; normalmente bastará con un registro de 32 bits, pero para recorrer ficheros realmente grandes necesitaremos un registro de 64 bits, o dos de 32.
ocupando registros
En general, para manejar números grandes se usan varios registros. Es algo que se hace rutinariamente en matemáticas; a menudo se quiere trabajar con precisión infinita. Los cálculos de criptografía asimétrica (claves públicas y privadas), por ejemplo, usan números con millones de cifras; a menudo se requieren más de 1000 bits para contener los valores intermedios, y hoy día incluso las claves. El procesador internamente manejará los bits de 32 en 32, como máximo; cuando ya se han usado todos los registros del procesador, es necesario guardar a memoria los cálculos que llevamos hechos y continuar con los siguientes.
Como podréis imaginar, estos cálculos son muy lentos, y bastante engorrosos para su uso habitual. ¿Se nota la lentitud realmente, o estamos hablando de los típicos milisegundos interesantes sólo a nivel teórico? En este caso es algo perceptible. Cuando nos conectamos a un sitio seguro (a una dirección que comienza por https
, o con un certificado personal como los que se usan en Hacienda) hay siempre una pausa de unos segundos; nuestro ordenador está haciendo los cálculos necesarios (con precisión infinita) para verificar que el certificado remoto es auténtico. Hasta hace poco no eran raros los retardos del minuto para los paranoic... estooo, valientes que usaban claves segurísimas; digamos, 2048 bits.
Cuantos más registros usemos, más lento irá todo; por lo tanto, los cálculos realmente largos se aceleran considerablemente al usar 64 bits. Hay que tener en cuenta que los procesadores hace ya tiempo que tienen unidades de cálculos de 64 bits; por ejemplo las extensiones MMX de Intel. Una librería decente acelerada para MMX ya nos hará el servicio; en este sentido, los procesadores de 64 bits consiguen integrar estas unidades sin necesidad de modos especiales o cambios de contexto.
amd64 el memorioso
Hay sin embargo un caso especialmente grave: el manejo de memoria sería lentísimo si usáramos más de un registro. Como se podría esperar, si nuestros registros tienen 32 bits, no tendremos forma de direccionar más de 4 GB. Ahora mismo las máquinas domésticas ya llegan al GB; es razonable pensar que un servidor crítico necesite bastante más. ¿Se puede superar este límite?
Ciertos procesadores antiguos de 16 bits (como el 8086) conseguían superar los 64 kB teóricos usando una técnica parecida a la de los discos duros, llamada en este caso paginación; se usaba un registro extendido, más grande de lo normal, para recordar direcciones de memoria. Esta técnica es muy vieja: ya los microprocesadores de 8 bits (como el Z80 que se encontraba dentro del ZX Spectrum o el Amstrad CPC, o el 6510 del Commodore 64) tenían registros especiales, de 16 bits, para direccionar memoria.
Así ocurre con los Pentium 4 modernos: como aclararon los lectores cuando el editor de LWN se pasó a los 64 bits, traen extensiones para usar 36 o 40 bits de direccionamiento. El problema surge cuando queremos manipular esas direcciones de memoria gigantes: la aritmética de punteros se vuelve más lenta que una peli de Bertolucci.
En la práctica, el límite de los 4 GB se ha mantenido impertérrito ante el desarrollo de estas extensiones. Si queremos más memoria y sobre todo poder manejarla, necesitamos definitivamente un procesador de 64 bits.
Ojo: estos procesadores no dan necesariamente acceso a 16 millones de terabytes; posiblemente la controladora de memoria sólo llegue a los 48 bits, lo que nos dará unos míseros 256 TB. Por ahora habrá que conformarse.
somos demasiados, y casi todos primos
Como vimos arriba, 32 bits no dan para asignarle un valor a cada persona del planeta. Si quisiéramos hacer una base de datos y asignarle un DNI a toda la población mundial, necesitaríamos más de 32 bits; indexar esa base de datos en un procesador de 32 bits sería lentísimo, ya que haría falta más de un registro y todas las operaciones se complican.
¿Cuánto se complican? La respuesta es: lamentablemente, mucho. Pensemos qué ocurre cuando queremos cruzar dos valores de la tabla de "ciudadanos del mundo", por ejemplo para indexar a un matrimonio. Si estamos usando dos registros para cada índice, el matrimonio nos ocupará cuatro registros. Podríamos simplificar y hacer una nueva tabla de matrimonios, ya que al fin y al cabo no puede haber más de tres mil millones de enlaces de este tipo. Pero supongamos que queremos seguir la pista a los "primos"; cada individuo puede tener hasta decenas de primos. La lista de cada pareja posible de primos ahora nos ocuparía cuatro de los preciosos registros de nuestro procesador, con lo que la base de datos sería completamente inmanejable si sólo tenemos 32 bits.
cuádruple precisión
Lo anterior es un ejemplo palmario de otro caso en el que se requieren 64 bits: cuando necesitamos hacer muchísimos cálculos muy rápidos, y estos exceden de 32 bits.
Hace décadas que pasaron los tiempos es que un escritor afamado como Asimov podía decir que los ordenadores daban respuestas inteligentes y quedarse tan pancho. Ahora sabemos que los ordenadores son sólo herramientas, y además bastante tontas. Por ejemplo, para sumar 1 y 1, al ordenador le sale 0 y se lleva 1; la anota en la siguiente columna y sigue sumando. Sí, amigos: un procesador moderno no sabe sumar 1 y 1 sin "llevarse". Así, para sumar (o restar) dos valores de 64 bits, primero se dividen los dos en parte pequeña (los primeros 32 bits) y parte grande (los últimos 32 bits); se suman primero las partes pequeñas; si se desborda el resultado se "lleva" internamente ese bit. Para terminar se suman las partes grandes de los números junto con el bit "llevado", y tenemos un nuevo valor de 64 bits.
Pero normalmente los valores con los que se quiere operar son de 32 bits; dan resolución suficiente para las aplicaciones más complejas, ¿no? Pues la triste realidad es que incluso para operar con valores de 32 bits, a veces hacen falta 64; por ejemplo para multiplicar dos números. Si ambos son de 32 bits, el resultado tendrá inevitablemente 64 bits; con lo que estaremos ocupando dos registros con los factores y otros dos con el producto. Las multiplicaciones de dos valores de 64 bits resultan en uno de 128 bits; el número de registros requerido es criminal.
más real que la realidad misma
No sólo en matemáticas complejas o en bases de datos de primos en la CIA se requiere manejar grandes números. La física moderna ha abandonado el laboratorio masivamente para fiarse cada vez más de las simulaciones de ordenador, que requieren de mucha precisión para ser realistas. Y qué simulación más apta para un ordenador que las imágenes de síntesis. Hablo de los cálculos de raytracing necesarios para la simulación foto-realista de imágenes 3D.
Aquí no importa tener el último modelo de tarjeta gráfica, porque no es un juego 3D; las tarjetas, por potentes que sean, sólo saben aproximar los objetos mediante la combinación de muchos triángulos. Por eso una rueda al ampliarla es posible que tenga 30 lados en vez de 10, pero siempre acaba siendo un polígono. Pero en nuestro ordenador casero podemos hacer simulaciones profesionales más sofisticadas, tipo Buscando a Nemo, en las que se sigue la trayectoria de cada rayo de luz por separado. Y además con un programa libre y gratuito. Si no os lo creéis es que no conocéis POV-Ray.
En la comparativa de linuxhardware.org de la que ya hemos abusado bastante, se usa POV-Ray para poner cara a cara a un Pentium 4 (con extensiones de 64 bits) con un amd64. El resultado es pasmoso: de 38 (P4 @ 3.2 GHz) a 18 minutos (Athlon 64 a 2.8 GHz). Mis propias pruebas con povbench dan resultados más modestos (de 40 para el P4 @ 2.4 GHz, a 29 minutos para el Athlon 64 3200+ a 2 GHz), pero aún así significativos.
eliminando complejidad
La arquitectura amd64 no sólo aumenta cosas; también, en ciertos aspectos significativos, las disminuye. La venerable arquitectura x86 tiene ya más de 20 años; en ese tiempo ha acumulado un montón de telarañas, que se aclararon sólo parcialmente con el 386 y sus registros de 32 bits. Sorprende a los programadores de ensamblador el corto número de registros de propósito general, que obligan a escribir a memoria a menudo valores intermedios; y tienen una arquitectura interna compleja, con el controlador de memoria independiente.
Los procesadores Athlon 64 de AMD aumentan el número de registros disponibles, además de integrar la controladora de memoria en el chip lo que disminuye la latencia de los accesos. Al mismo tiempo mantienen totalmente la compatibilidad hacia atrás, de manera que se puede ejecutar a la vez código de 32 y 64 bits. Por otro lado, el ancho de banda entre la memoria y el procesador aumenta; se puede acceder a más memoria más rápidamente.
Por supuesto, los amd64 mantienen unos bajos consumos de memoria, sobre todo en comparación con los Pentium 4 de última generación. No hay que dejarse engañar por las cifras publicadas por los fabricantes; no entienden lo mismo por TDP o potencia de diseño térmico (Thermal Design Power). Donde los procesadores de Intel tienen un consumo típico de 86 W, en los AMD encontramos un consumo máximo similar o incluso menor. Por ejemplo, Tom's Hardware encuentra que el consumo en reposo de un Pentium 4 es mayor que el consumo máximo de un Athlon 64.
Si eres un programador de assembler y sólo quieres simplificar tu código para simulación de, digamos, un túnel de viento, las extensiones de Intel EM64T te servirán igualmente. Si además quieres las mejoras de arquitectura asociadas, no está tan claro que te vayas a quedar contento.
No se da aquí la flexibilidad que tienen los procesadores PowerPC, por ejemplo: dado que el código de 64 bits es una extensión natural del de 32 bits, los programas no tienen que cambiar de modo ni juego de registros; pueden usar 32 y 64 bits simultáneamente. Así, podemos usar una librería de 32 bits contra un programa de 64, y al revés. En x86_64, por darle su nombre oficial en Linux, hay que elegir las librerías adecuadas al tipo de programa.
muchos bits, ¿pocos sistemas?
Así, si el sistema operativo no va a 64 bits, los programas no lo aprovecharán. Como ya vimos, Microsoft sólo ha sacado al mercado la versión de Windows de 64 bits para fabricantes; los usuarios domésticos no pueden comprarla por separado. Esto limita las posibilidades para muchos usuarios.
Por suerte, existe Linux. Como nos contó jorginius en un comentario, se creó en una situación parecida a la actual: Linus Torvalds se puso en el '91 a programar un kernel de 32 bits para su 386 porque el software propietario no le permitía aprovechar su nueva máquina a fondo. Pues bien, para conseguir que tu nuevo amd64 dé todo lo que aguanta la burra, necesitarás una versión de GNU/Linux.
Alternativamente, podrás usar un sistema de la familia *BSD, pero dado que mis conocimientos de estas aguas son mínimos tirando a nulos, mejor no me meto. Sólo os diré que comparten gran parte del software, por no decir casi todo, entre sí y con GNU/Linux; y la mayor parte del tiempo las mejoras son mutuas.
Linux está ajustado desde hace mil años para funcionar en procesadores Alpha y otras diez arquitecturas exóticas; con lo que los programas funcionando a pleno rendimiento y aprovechando los 64 bits de x86-64 están a una distro de distancia. Sólo algunos casos patológicos (como OpenOffice.org 1.x) no compilan en 32 bits; y si dependemos del software propietario (plug-in de Flash, JDK de Sun, drivers para ATI y nVidia) tenemos que esperar a que a la casa que lo publica le dé por sacar una nueva versión. Pero el resto, una ingente cantidad de software gratis y disponible libremente, está esperando.
En mi diario he probado en tres ocasiones distintas varias distros: Ubuntu, Debian, Mandriva, OpenSUSE y Gentoo. He encontrado distintos grados de madurez; al final estoy usando Mandriva, con el ojo puesto en Gentoo.
y por fin terminamos
Los procesadores de 64 bits de AMD no sólo dan mayor rendimiento en cálculos con números grandes; tambien traen cambios internos y mejoras de arquitectura que sería absurdo despreciar, manteniendo precios razonables y bajo consumo. En cuanto a la adopción por Intel de la arquitectura (camuflada como EM64T), es una pobre imitación con bastantes menos ventajas.
Estamos en un momento dorado para el software libre, y le llevamos bastante ventaja al propietario en ciertos aspectos cruciales. Si eres nuevo, es el momento de bajarte una distro y hacerle un hueco en tu disco duro; si eres veterano, actualízate y disfruta de tu nueva arquitectura. No te arrepentirás.
Quedo esperando vuestros comentarios y correcciones ¡sin piedad!