Linux y los 64 bits, el binomio perfecto

Vislumbrando el futuro

La reciente aparición de la arquitectura de 64 bits destina a los PC de

sobremesa y portátiles se enfrenta a un primer inconveniente: la

ausencia de software. O al menos, a la de aplicaciones que permitan

sacar el máximo provecho a los nuevos microprocesadores. Windows XP

64-Bit se está haciendo desear tanto por usuarios como por montadores,

que por el momento sólo pueden acceder a sistemas operativos de

Microsoft destinados a servidores.

Durante estos primeros meses

de convivencia con los procesadores de ocho octetos para el mercado

doméstico, nos hemos encontrado ante una situación que casi podríamos

tildar de absurda: todos los análisis que se han llevado a cabo en la

prensa escrita como en Internet (y han sido muchos) se centran

exclusivamente en el rendimiento de aplicaciones y juegos destinados a

las actuales plataformas de 32 bits. Bien es cierto que las versiones

disponibles del Athlon 64 (la «estándar» y la de alta gama, bautizada

como FX-51) han dado buenas muestras de su potencia en este segmento,

pero parece que nadie se da cuenta de que esa compatibilidad con la

arquitectura x86-32 es sólo una inteligente manera de facilitar la

migración a los 64 bits.

Además, no existen bancos de

pruebas para los ocho octetos. Nuestros conocidos SYSmark y 3DMark están

orientados a las plataformas de 32 bits y, al igual que el resto de

tests, no son capaces de vislumbrar las posibilidades que ofrece la

nueva arquitectura. Y mucho nos tememos que esa será la situación hasta

que aparezca la versión de Windows XP compatible con este desarrollo de

AMD. Prácticamente, no existen iteraciones específicas para esta

plataforma de ninguna de las aplicaciones «tradicionales», y es probable

que los nuevos Word, Excel, Photoshop, Winamp, Premiere o 3dsmax vean la

luz tras la presentación oficial del esperado Windows XP 64-Bit de

Microsoft. Como también lo harán, por supuesto, los respectivos bancos

de pruebas.

¿Demasiado pronto?

Tan temprano ha sido el lanzamiento de los «micros» de 64 bits para el

segmento doméstico que casi nadie ha podido acompañar a AMD en el

apartado software. Las distribuciones Linux han sido las grandes

beneficiadas en este terreno, ya que la propia filosofía del sistema

operativo y del movimiento Open Source resultan perfectas. La licencia

GPL, bajo la que se auspician la gran mayoría de los desarrollos para

Linux, obliga a los desarrolladores a proporcionar el código fuente

junto con los propios ejecutables de la aplicación.

Como

comprobaréis en las pruebas reunidas, la metodología ha tenido una

primera etapa generalizada, en la que se han compilado los fuentes con

ciertas opciones especiales. La alternativa destinada a obtener binarios

compatibles con la arquitectura x86-64 (que añade las extensiones

necesarias de 64 bits al juego de instrucciones disponibles en la

tradicional x86) se aplica al compilador gcc, que gracias al flag -m64(o m32, en el caso de querer obtener ejecutables de 32

bits) proporciona este tipo de capacidad. Básicamente, el procedimiento

ha consistido en elegir ciertos programas que ofrecen una idea del

rendimiento final de estos sistemas. Una vez compilados, podemos

comparar su comportamiento si los ejecutamos siguiendo ciertos patrones

y opciones, que comentamos más adelante.

Opteron vs Athlon 64

Las comparaciones entre los dos buques insignia de AMD no han sido tan

numerosas como las que han aparecido entre el reciente Athlon 64 y los

desarrollos de Intel. Los «micros» de la serie Opteron están destinados

a servidores y estaciones de trabajo de gran calado. Su precio y

prestaciones los alejan del sector de consumo, que acapara sin ningún

complejo su «hermano pequeño», el Athlon 64, del que el FX-51 es su

alumno aventajado.

La idea de este artículo es mostrar la

versatilidad de las distribuciones Linux a la hora de ofrecer toda la

potencia de las nuevas soluciones tecnológicas, y hacerlo con la ayuda

de dos de las dos soluciones de referencia actualmente. Para ello, nada

mejor que recordar brevemente sus aspectos más destacados. Conviene

señalar las ventajas más claras que aporta el uso de procesadores que

trabajan con palabras de ocho octetos. La más clara e importante reside

en la posibilidad de disponer de un mapa de memoria que casi podríamos

calificar de ilimitado. Con direcciones físicas de 40 bits, es factible

que cualquier aplicación compilada para sacar provecho de esta

plataforma disponga de un espacio de memoria de medio Tbyte, una cifra

mareante y que asegura su futuro durante los próximos años. Los

registros adicionales de 64 bits que permitirán movimientos de palabras

de ocho octetos (como los frecuentes shiftsy unrolls

usados a bajo nivel), las optimizaciones aplicadas sobre ejecutables

tanto estáticos como dinámicos o la enorme amplitud del ancho de banda

entre los diversos componentes, son algunas otras. También es importante

el soporte absoluto del juego de instrucciones SSE2, algo que afecta a

las aplicaciones Linux, que pueden aplicar un parámetro especial durante

la compilación para valerse de dicho soporte.

Los secretos de la compilación

Durante las pruebas, hemos podido elegir opciones avanzadas de

compilación que permiten sacar todo el rendimiento a los binarios

finales. No obstante, hay que señalar que, aunque la mayoría de

aplicaciones pueden ser compiladas sin problemas activando los flags

adecuados, existen incompatibilidades entre la arquitectura y los códigos

fuente que no están orientados a su uso en la plataforma de ocho

octetos. Así ha sucedido con el propio núcleo, ya que necesitábamos que

la misma versión pudiese ser compilada en los dos PC, y que no pudo

hacerse de forma conjunta. De esta forma, el tiempo de compilación del kernelde Linux un dato habitualmente usado para evaluar máquinas bajo

este SSOO no pudo ser obtenido e incluido entre las pruebas de

evaluación. En lugar de eso, hemos incorporado algunos tiempos de

referencia para la compilación de utilidades como MPlayer o lame, menos

voluminosas en tamaño, pero válidas para obtener una primera

aproximación.

Como comentamos, el compilador es el encargado

de ofrecer un verdadero valor añadido sobre la arquitectura en la que

trabaja. En la actualidad, existen tres desarrollos que ofrecen

compatibilidad con las máquinas de 64 bits en Linux: Intel C Compiler ( http://developer.intel.com/software/products/compilers/ ),

Portland Group Compiler (pgc, en www.pgroup.com/ ) y GNU C Compiler (gcc, http://gcc.gnu.org/ ), el más extendido, al venir de serie

con cualquier distribución de Linux. No hemos podido, ni era nuestro

objetivo, extrapolar los resultados obtenidos con otros compiladores,

aunque sí es cierto que una de las pruebas ha demostrado que ciertas

optimizaciones del código llevadas a cabo por el compilador pueden ser

fundamentales. La prueba oblCPU es una muestra de ello, al mostrar los

índices de un ejecutable generado con gcc y con otro compilado con icc.

El gcc encierra ciertos secretos que, a fuerza de pruebas, consiguen sacar el

máximo partido de los ejecutables. No hemos querido afinar demasiado

para no «aprovecharnos» en demasía de las opciones de la arquitectura,

centrándonos en aplicar las mejoras clave de la tecnología de AMD. Los

parámetros como la activación del juego de instrucciones SSE2 para el

que los Athlon64 y Opteron están preparados o la generación de

ejecutables con una optimización aún mayor (-O4, por

ejemplo) eleva los tiempos de compilación y sólo en ciertos casos

(aplicaciones multimedia que soporten esas extensiones, por ejemplo) se

hará evidente la mejora. El primero de esos progresos es el fla

g, que posibilita activar las extensiones de 64 bits y que se especifica

mediante el parámetro -m64. Si queremos realizar el mismo

proceso para generar un binario de 32 bits, debemos incluir la opción m32en la máquina con el sistema de 64 bits instalado.

Otra

opción para optimizar el código viene determinada por el flagO, que facilita la aplicación de distintos niveles de mejora

que tienen repercusión en el tiempo de compilación. Es más que

conveniente valerse al menos de la optimización «de segundo nivel», que

vendría con -O2, aunque muchos benchmarkspublicados

en Internet se centran en ejecutables compilados con -O3. Los

resultados de las pruebas varían sensiblemente en uno y otro caso.

A partir de aquí surgen otras alternativas, siendo la más importante para el

caso del Opteron la referida al uso o no de la tecnología SMP de

multiproceso, que permite combinar la potencia de los dos «micros». El

parámetro mpes el encargado de activar esta capacidad,

aunque su aplicación depende de la utilidad a compilar. En este último

caso, hemos querido señalar la diferencia entre el proceso simple y el

multiproceso simétrico con una herramienta que nos viene al pelo. Se

trata de The Gimp, que en su versión 1.2.5 incluye esta selección

preprocesando los ficheros de compilación Makefilecon la

sentencia ./configure with-mp=yes. Hemos adjuntado los tiempos de

proceso para diversos filtros sobre una imagen JPEG y la diferencia

entre ambos resultados es increíble: casi el doble de rendimiento, lo

que resulta lógico si pensamos que uno de los procesadores no trabajará

a no ser que empleemos esta mejora.

La última de las opciones,

que no afecta a los binarios, pero sí a los tiempos de compilación, es

el flagj, que determina el número de hilos o threads

distintos que puede utilizar la máquina durante el proceso de

generación del código objeto. Por defecto, este valor es ilimitado, pero

se puede ajustar según la cifra de procesadores. De acuerdo con diversos

estudios, parece que la opción optima sería -j 16, es

decir, un máximo de 16 hilos durante la compilación. Esto sólo afectará

al proceso de obtención del ejecutable, y no al rendimiento final del

programa.

Por último, hay que señalar que otra de las ingeniosas

ayudas de Linux en las tareas de benchmarkingreside en la

existencia del comando time, que posibilita cronometrar con

exactitud el tiempo empleado para cualquier operación requerida.

Anteponiéndolo al resto de la sentencia, cuando ésta se ejecute,

aparecerá también cuánto ha tardado. Un ejemplo clásico es el famoso time make, que indica lo que emplea en compilarse una aplicación que ya

hemos preprocesado correctamente con los habituales scripts configur

e.

Distribuciones para todos

Ya mencionamos en el especial sobre la plataforma de 64 bits que Linux

había sido pionero en el desarrollo de una versión para la arquitectura

AMD64. En concreto, la reputada SUSE LINUX rebautizada oficialmente en

mayúsculas) ha lanzado al mercado su versión Professional 9.0 tanto para

x86-32 como para x86-64, mientras que en el caso de Opteron dispone de

SLES (SUSE LINUX Enterprise Server), basada en una 8.2 de escritorio a

la que se han añadido numerosas mejoras y herramientas en el apartado de

tareas servidoras. Esta última también funciona sobre Athlon 64, y como

peculiaridad cuenta la certificación del consorcio United Linux. Por lo

demás, se trata de una distribución perfectamente utilizable por un

usuario convencional, que, por otro lado, encontrará en la 9.0 para

Athlon 64 una referencia más válida para entornos de sobremesa.

Éstas han sido las elegidas para poder ejecutar el banco de pruebas sobre

Athlon 64 y Opteron, y ya adelantamos que su comportamiento ha sido

perfecto en todos los aspectos. De hecho, no notamos en absoluto que

estamos ante una máquina y un sistema operativo de ocho octetos, porque

todos los procesos se realizan de forma idéntica a los acometidos con

plataformas de 32 bits. El entorno de escritorio, la configuración de

los diversos apartados del sistema operativo y el uso de las

herramientas incluidas no cambian, de manera que el aprovechamiento de

los nuevos recursos es totalmente transparente para el usuario.

Incluso sus asistentes de instalación son exactamente iguales que

aquellos disponibles en sus homólogas de 32 bits. El buen comportamiento

de yast2se vuelve a poner de relieve en este apartado, con la

posibilidad de redimensionar particiones Windows (FAT32 y NTFS) sin

problemas. Curiosamente, en la versión para Athlon 64 contamos con un

DVD de doble cara, un soporte inusual que facilita la puesta en marcha,

ya que, por un lado, contiene los binarios y ficheros necesarios para

completar la instalación, y, por otro, incorpora todos los fuentes de

las herramientas incluidas, como es norma en una distribución que sigue

la licencia GPL.

Paralelamente, la SLES se compone de cuatro CD

de instalación, que iremos introduciendo en el lector según los pida.

Una vez completado el proceso, descubrimos entornos totalmente

operativos y que funcionan con una estabilidad a prueba de bomba. Ha

sido una agradable sorpresa comprobar cómo todas las aplicaciones que

utilizamos en máquinas de 32 bits funcionan sin problemas con las

mejoras que se derivan de su compilación específica para la nueva

micro-arquitectura. El único problema con el que nos hemos encontrado no

depende directamente de SUSE, afectando a los controladores de la

tarjeta gráfica. Mientras que los driversincluidos

funcionan a la perfección si no queremos disponer de la aceleración 3D,

no ocurre lo mismo al intentar activar esta opción. Como muchos sabréis,

las distribuciones Linux deúltima generación avisan de este aspecto

durante la instalación, ya que NVIDIA proporciona controladores

específicos para las tarjetas gráficas basadas en su motor gráfico, y

son éstos los únicos capaces de dar soporte a las extensiones GLX que

activan la aceleración 3D y, por extensión, el uso deOpenGL. Esto afecta

a juegos y herramientas de diseño 3D, como blender, que

hubiésemos querido incluir en el banco de pruebas. Sin embargo, el

proceso de instalación de estos driverses bastante

engorroso y su resultado desastroso, ya que el servidor de ventanas se

muestra incompatible con el hardware y la pantalla se queda en negro,

sin posibilidad de recuperar la sesión. Esperamos que NVIDIA lo resuelva

pronto, ya que el parche 4499 publicado especialmente para la

distribución de SUSE no ha resuelto este contratiempo.

También conviene apuntar que hemos lidiado con los habituales

inconvenientes de la compilación de grandes desarrollos que no dependen

tanto de sí mismos como del uso de librerías y otras pequeñas utilidades

que pueden complicar el proceso. Las dependencias entre versiones

instaladas en el sistema y las necesarias por el código fuente pueden

ser fuente de quebraderos de cabeza para aquellos no familiarizados con

los procesos de generación de código objeto. Por esta razón, ciertos

tests que nos hubiera gustado incluir no han sido abarcados.

Para

completar el apartado de pruebas, hemos instalado también dos

distribuciones más para la máquina basada en Athlon 64. La primera de

ellas no es otra que Mandrake 9.2, en su edición de 64 bits ( ). Aunque se trata

de la Release Candidate 1, nuestraimpresión es que el desarrollador

francés ha hecho un excelente trabajo, presentándose como una

alternativa perfecta a los productos de SUSE LINUX. La segunda sí está

claramente enfocada al banco de pruebas, ya que contamos con una SUSE

LINUX Professional 9.0, pero en su edición de 32 bits. Evidentemente, el

funcionamiento es perfecto, y ha resultado ser una referencia

importantísima para mostrar las diferencias de rendimiento entre las

aplicaciones en sus versiones para 32 y 64 bits.

Las pruebas En

las siguientes líneas comentaremos con más profundidad los análisis que

hemos decididoaplicar. Los resultados están orientados tanto a dar una

visión del buen hacer de ambos «micros» en tareas tradicionales de

entornos sobremesa como a corroborar las mejoras que se han llevado a

cabo en las uevas arquitecturas.

En primer lugar, lame-3.93.1

permite conocer el tiempo necesario para la conversión de un archivo WAV

en uno MP3, lo que ofrece una idea de la potencia de unas soluciones que

son capaces de transformar un fichero original de casi seis minutos en

apenas 20 segundos. La misma conversión, pero ahora en el apartado de

vídeo, se ha encargado de hacerla la utilidad mencoder, que surge de la

compilación de Mplayer-1.0pre3 y que, en este caso, se convierte en un

sencillo fichero MPEG-1 de 30 segundos.

Mención especial se

merece The Gimp, que hemos compilado en ambas plataformas en una versión

antigua pero estable (la 1.2.5, algo a lo que nos obligó la SLES para

Opteron) y mediante la cual hemos obtenido distintos tiempos de

procesamiento. A partir de aquí, están las pruebas técnicas, que miden

la potencia bruta y características como la caché o el trabajo con

enteros y reales.

En este sentido, una de las primeras pruebas es

la denominada oblCPU, desarrollada por OpenBench Labs (www.open-mag.co

m). A lo largo de sus 25 tests, arroja cifras que hemos simplificado para no

«marearos». Baste decir que la media aritmética indicada permite

confirmar el comportamiento de la plataforma. Entre estos análisis

independientes (que en el ámbito del bench-markingse suelen

denominar confusamente kernels) se encuentran algunos tan

conocidos como el algoritmo de las torres de Hanoi, una versión de

LINPACK o ciertas funciones matemáticas de Gauss. Así pues, es en el

procesamiento matemático puro en donde hay que valorar estos resultados.

Precisamente, las pruebas LINPACK también se han incluido en otro apartado y

provienen directamente de su desarrollador oficial ( www.netlib.org/linpack/ ). Como se explica en su web, el

objetivo es evaluar la potencia de un procesador a la hora de resolver

sistemas de ecuaciones lineales.

También nos hemos valido del

conocido nbench, un desarrollo independiente y de libre distribución que

parte del test BYTEmark, y especialmente adaptado a Linux/Unix. De

nuevo, nos encontramos con una serie de pruebas independientes que

ofrecen unos resultados numéricos que permitirán comparar diferentes

plataformas.

A su vez, cachebench estudia el comportamiento de

las memorias caché de los procesadores mediante el análisis del tiempo

invertido en diversos procesos. En concreto, se pasan ocho tipos de

pruebas que, entre otros aspectos, posibilitan conocer el rendimiento en

lecturas, modificaciones y escrituras en caché, mientras que dos de

ellas se reservan un apartado especial: el examen de las funciones memset()y memcpy(), que se utilizan frecuentemente en la

programación en lenguaje C. La ejecución de cachebench ofrece una serie

de ficheros con información numérica, que facilita un visionado más

sencillo gracias a la generación de un gráfico PostScript tanto para

Athlon 64 como para Opteron. Su inserción permite contemplar el

comportamiento de las nuevas caché de nivel 2 de 1 Mbyte que incluyen

los «micros» con tecnología AMD64.

Conclusiones aplastantes

El objetivo de medir el rendimiento de las máquinas de 64 bits bajo

Linux se ha cumplido plenamente, ya que hemos comprobado las ventajas de

utilizar aplicaciones compiladas para 32 y 64 bits. Las diferencias

entre las dos primeras columnas resultan determinantes, y confirman esa

excelente sensación que ofrecen estos «micros» y que se verá plenamente

satisfecha cuando el software esté desarrollado por y para la

arquitectura x86-64.

Los valores que arroja la máquina basada en

Opteron son, en su mayoría, inferiores a los del Athlon 64. La

explicación es muy sencilla: los programas utilizados no aprovechan la

tecnología SMP, que se beneficia de la presencia de dos «micros», por lo

que en realidad son los guarismos correspondiente a uno solo. Al ser más

veloz el Athlon 64 (2,0 GHz frente a 1,6 GHz del Opteron), la diferencia

es clara, pero no debe llevarnos a engaños: el potencial y escalabilidad

de Opteron es mayor.

Si lanzamos más y más procesos, el sistema

operativo se encargará mediante el schedulerde planificar a

qué tarea se dedican recursos y durante cuánto tiempo. Que este

planificador disponga de dos «micros» sólo permite repartir cargas de

trabajo, mientras que con uno las aplicaciones abiertas funcio-nan más

lentamente. Así pues, si contamos con escenarios en los que muchas

tareas se están ejecutando al mismo tiempo, los resultados finales

confirmarán que la máquina con dos obtendrá una clara ventaja. Hemos

observado esta circunstancia en las pruebas con The Gimp, el soft que

nos ha permitido aplicar el flagde multiproceso simétrico y que

hace que los tiempos de aplicación de los filtros se reduzca a la mitad,

superando aquellos logrados por el Athlon 64.

¿No es oro todo lo que reluce?

Aunque Linux resulta hoy la mejor opción para sacar partido a los nuevos

«micros» de AMD, también es cierto que el ciclo de vida de estas

soluciones en los entornos de sobremesa no ha hecho más que empezar.

Esto afecta a un apartado esencial: el software aún no está preparado

para esta nueva plataforma. Los desarrollos incluidos en las nuevas

versiones de Linux se basan en el mismo código fuente que los

programadores han ingeniado para las arquitecturas tradicionales, por lo

que no existen, en la inmensa mayoría de los casos, mejoras que afecten

a toda la nueva serie de avances tecnológicos que se han aplicado a los

Athlon 64 y Opteron.

También hay que recordar que la programación

orientada a SMP es escasa, salvo en aplicaciones típicamente servidoras.

Las bases de datos, los servidores web o aquellos dirigidos al trabajo

colaborativo (correo electrónico incluido) sí dan soporte para estas

opciones, lo que sin duda saca el jugo a la plataforma más empresarial

de AMD. Esperemos que los desarrolladores tomen en cuenta las ventajas

de estas arquitecturas y las apliquen en sus desarrollos. Aunque los

compiladores hacen un trabajo excepcional a la hora de generar binarios

que saquen partido de esas ventajas técnicas, es en el código donde

habrá que introducir unos cambios que marcarán la diferencia

¿Quo vadis, Intel?

Un paseo por Internet permite comprobar la superioridad de los nuevos

procesadores de AMD frente a las soluciones de Intel. Las pruebas no

hacen sino confirmar las buenas cifras de rendimiento que arrojan el

Athlon 64 y su versión FX-51, y que sobresalen especialmente en el

apartado lúdico.

Las comparaciones con los últimos P4 EE son

también cuantiosas, pero en pocos medios se hace una verdadera reflexión

sobre la situación del mercado. Os aconsejamos una visita a la webde

X-bit labs (www.xbitlabs.com/arti-cles/editorial/display/intel.htm

l), donde nos ha llamado la atención un artículo dedicado a las

posibles acciones de Intel para afrontar el lanzamiento del Athlon 64.

El autor las divide en cuatro posibilidades: continuar su línea de

«micros» x86/IA32 sin introducir extensiones del juego de instrucciones

para los 64 bits; crear una extensión propietaria a la arquitectura x86

e incompatible con la lanzada por AMD; aprovechar la arquitectura IA64

usada en la familia Itanium y adaptarla al mercado de sobremesa, y

licenciar la tecnología AMD64 para integrar las extensiones de AMD en

sus procesadores. Mientras que descarta la primera y tercera opciones,

justifica cómo implementar una solución de cero o licenciar la

tecnología de su rival representan las alternativas más probables. ¿Se

valdrá Intel de la arquitectura de su rival?