¿Windows tiene problemas de afinidad y le echamos la culpa a AMD?

(Y lo peor es que aparentemente es más fácil cambiar todas las BIOS antes que arreglar Windows.)

Voy a tratar de explicar por qué Windows no hace un uso óptimo del procesador a raíz de que su planificador de CPU (CPU scheduler) tiene muy pobre afinidad natural.

Cuando se tiene más de un procesador (o más de núcleo en un procesador) los procesos se pueden ejecutar en cualquiera e incluso a lo largo de su ejecución pueden pasar de uno a otro. Sin embargo, mudar un proceso a otro procesador es una operación costosa y que debe evitarse sobre todo en el caso de procesos que hacen uso de CPU en forma intensiva.

¿Por qué es costosa?

  • Primero porque cada procesador (o núcleo) tiene sus propias memorias caché L1 y L2 y al mudar un proceso a otro procesador hay que volver a leer de la RAM o de la caché L3 los datos e instrucciones que se necesitan. Si el proceso hubiera seguido en el mismo procesador habría sido altamente probable que sus datos todavía estuvieran en las cachés. Cuantas más veces se mude un proceso de procesador más tiempo se perderá en recargar las cachés.
  • Segundo porque el procesador al que el proceso fue reasignado puede estar en un estado de ahorro de energía y le tomará un tiempo (por ejemplo 1 milisegundo) activarse y volver a la velocidad máxima.

Eso último es exactamente lo que pasa con Windows Vista, Seven y Server 2008 en los procesadores AMD Phenom X3 y X4. Cuando se tiene una tarea que requiere usar el 100% de CPU como puede ser el caso de ver una película en HD o comprimir audio o video, típicamente sólo uno de los 3 ó 4 núcleos está trabajando a la velocidad máxima (2,2 GHz por ejemplo) y los demás en la mitad (1,1 GHz). Eso es bueno, porque se ahorra energía, se emite menos calor y se puede reducir la velocidad de los ventiladores disminuyendo el ruido y todo eso sin perder rendimiento.

Como Windows hace rebotar los procesos entre los diferentes procesadores casi constantemente (todos lo notan), transcurre luego de cada cambio un tiempo en el que el proceso se ejecuta a 1,1 GHz. Además hay que sumar el tiempo para que las cachés L1 y L2 se invaliden y repoblarlas con datos traídos desde las memorias más lentas (L3 y RAM).

El resultado es que a la larga el rendimiento es menor cuantos más cambios de núcleo hay.

El concepto de Afinidad justamente busca evitar esos problemas tratando dentro de lo posible que un proceso que se está ejecutando en un procesador siga haciéndolo ahí. El sistema operativo Linux tenía también problemas de afinidad en su versión 2.4, pero desde la versión 2.6 responde muy bien en ese aspecto.

Ahora, ¿por qué se llega al extremo de decir que el manejo de Cool’n’Quiet del AMD Phenom X4 tiene un bug? Está claro que el rendimiento de los benchmarks ejecutados en Windows es inferior con Cool’n’Quiet habilitado que deshabilitado, pero no es culpa del hardware sino del software.

El resultado sería igualmente bueno al medido sin Cool’n’Quiet

  • si el planificador de CPU de Windows fuera mejor;
  • o si deshabilitáramos 3 de los 4 núcleos del Phenom;
  • o si le asignáramos una CPU Affinity Mask al proceso que hace el benchmark;
  • o si le especificáramos al proceso la afinidad a uno de los núcleos desde el administrador de tareas;
  • o si no usáramos Windows.

El problema de la afinidad de Windows ya es muy conocido y hasta la base de datos FirebirdSQL tiene incorporada una configuración para que se pueda obligar a Windows a ejecutarla en un determinado procesador para evitar el pésimo desempeño ocasionado por ir de un procesador al otro a cada rato. Está claro ahí mismo que eso sólo es necesario en Windows y en ningún momento se menciona que sea un problema del AMD Phenom X4. De hecho el problema y su solución puntual están ahí escritas desde antes de que existiera ese modelo.

En procesadores como los de Intel que tienen muchos núcleos y la característica de hyperthreading, manejar bien la afinidad es vital ya que el costo del cambio de un procesador a otro no es el mismo al cambio de un núcleo a otro ni el mismo del cambio de un thread a otro dentro del mismo núcleo. Veamos:

  • Puede haber 2 procesadores físicos cada uno en su socket en cuyo caso no comparten nada y pasar un proceso de uno a otro tendría el máximo costo.
  • Puede haber dos núcleos dentro de un procesador, en cuyo caso comparten la caché L3 y el costo sería algo inferior.
  • Puede haber 2 threads dentro de un núcleo en cuyo caso comparten todo: L1, L2 y L3, pero ambos threads compiten por el uso de determinados recursos del propio procesador lo que podría ocasionar menor rendimiento.

El mal llamado bug de Cool’n’Quiet no hace más que poner en evidencia o agravar un problema que ya estaba y que sigue estando en la forma en que Windows planifica el uso de la CPU.

La solución que adoptó AMD en su Phenom II de no permitir que los núcleos operen a diferentes velocidades mitiga una de las consecuencias, pero tiene el costo de desperdiciar energía, generar más calor y no permitir la reducción de ruido provenientes de los ventiladores. El problema de la caché L2 sigue sin solución y afecta a cualquier marca de procesador. De hecho cada tanto alguien encuentra el problema y recurre a establecer manualmente la afinidad de un proceso en Windows.

El otro día estuve codificando un video de 9,1 GB a Theora. Tardó 6 horas y como tengo un widget en el escritorio que me muestra a cuántos gigahertz se está ejecutado cada núcleo, se veía claramente que siempre era el mismo el que estaba ocupado y los otros tres estaban libres casi todo el tiempo (tengo habilitado el Cool’n’Quiet). Eso es porque uso Linux.

Ventajas de los Drivers Libres

Ahora que finalmente el soporte 3D está llegando a las placas de video ATI se hacen más evidentes las ventajas de que el código fuente de los drivers esté disponible.

Soporte a Largo Plazo

El driver libre para ATI Radeon soporta todos los modelos lanzados al mercado desde 2000. En cambio el driver Catalyst de ATI ya no soporta modelos tan viejos y menos en Windows 7. Algo similar ocurre con las placas NVidia. El driver que provee el fabricante no soporta tantos modelos como el driver libre.

Integración

Cada vez que sale una versión nueva de Linux o del servidor gráfico, si es necesario, se adaptan todos los drivers libres para que sigan funcionando correctamente. En cambio los otros drivers suelen tardar más en ser adaptados y dejan a mucha gente si soporte un tiempo. Además los drivers libres son integrados por las propias distribuciones de Linux y vienen “andando de fábrica” mientras que los drivers de los fabricantes los debe bajar el usuario de la página oficial e instalarlos siguiendo las instrucciones.

Soporte de Errores

Si bien los drivers libres a veces se deben hacer sin las especificaciones oficiales que los fabricantes no publican, los programadores que los hicieron se ocupan de arreglar los errores y de hacer las mejoras que sean posibles. En el caso de AMD/ATI, entre 2007 y 2008 publicó la documentación necesaria para sus placas de video Radeon y los drivers libres se están haciendo en base a ella. Es así que ahora cualquiera puede reportar errores o incluso participar de las mejoras. En cambio ATI y NVidia son más propensos a escuchar a los fabricantes de juegos que a los usuarios y desde ya que no se puede participar de las mejoras de sus drivers.

Hoy los drivers de los fabricantes son más completos y en algunos casos puede ser que sean más rápidos, pero a la larga los drivers libres van completarse y van a alcanzar el rendimiento del otro reteniendo las otras ventajas antes explicadas.

Soporte 3D en Linux

Logo de ATI Radeon

Cuando en abril salga Ubuntu 10.04 Lucid Lynx se supone que finalmente tendremos soporte 3D para placas de video ATI con los drivers radeon y radeonhd hechos en base a las especificaciones que AMD publicó cuando compró ATI. En particular la documentación necesaria para usar el hardware de video para operaciones 3D fue publicado el 29 de diciembre de 2008 y llegaron al kernel 2.6.32 que salió 3 de diciembre de 2009.

Según la página de esos drivers libres, se necesita esa versión del kernel y la versión 7.7 de la biblioteca gráfica mesa. Lucid Lynx parece estar preparado ya que trae:

  • xserver-xorg-video-radeonhd 1.3.0-2
  • linux-generic 2.6.32.15.16
  • mesa 7.7-4

En el caso de tener una placa ATI determinamos qué hardware es con esta explicación tomada de la wiki del driver libre:

  * RV505:	Radeon X1550, X1550 64bit
  * RV515:	Radeon X1300, X1550, X1600; FireGL V3300, V3350
  * RV516:	Radeon X1300, X1550, X1550 64-bit, X1600; FireMV 2250
  * R520:	Radeon X1800; FireGL V5300, V7200, V7300, V7350
  * RV530:	Radeon X1300 XT, X1600, X1600 Pro, X1650; FireGL V3400, V5200
  * RV535:	Radeon X1300, X1650
  * RV550:	Radeon X2300 HD
  * RV560:	Radeon X1650
  * RV570:	Radeon X1950, X1950 GT; FireGL V7400
  * R580:	Radeon X1900, X1950; AMD Stream Processor
  * R600:	Radeon HD 2900 GT/Pro/XT; FireGL V7600/V8600/V8650
  * RV610:	Radeon HD 2350, HD 2400 Pro/XT, HD 2400 Pro AGP; FireGL V4000
  * RV620:	Radeon HD 3450, HD 3470
  * RV630:	Radeon HD 2600 LE/Pro/XT, HD 2600 Pro/XT AGP; Gemini RV630; FireGL V3600/V5600
  * RV635:	Radeon HD 3650, HD 3670
  * RV670:	Radeon HD 3690, 3850, HD 3870, FireGL V7700, FireStream 9170
  * R680:	Radeon HD 3870 X2
  * M52:	Mobility Radeon X1300
  * M54:	Mobility Radeon X1400; M54-GL
  * M56:	Mobility Radeon X1600; Mobility FireGL V5200
  * M58:	Mobility Radeon X1800, X1800 XT; Mobility FireGL V7100, V7200
  * M62:	Mobility Radeon X1350
  * M64:	Mobility Radeon X1450, X2300
  * M66:	Mobility Radeon X1700, X1700 XT; FireGL V5250
  * M68:	Mobility Radeon X1900
  * M71:	Mobility Radeon HD 2300
  * M72:	Mobility Radeon HD 2400; Radeon E2400
  * M74:	Mobility Radeon HD 2400 XT
  * M76:	Mobility Radeon HD 2600;(Gemini ATI) Mobility Radeon HD 2600 XT
  * M82:	Mobility Radeon HD 3400
  * M86:	Mobility Radeon HD 3650, HD 3670, Mobility FireGL V5700
  * M88:	Mobility Radeon HD 3850, HD 3850 X2, HD 3870, HD3870 X2
  * RS600:	Radeon Xpress 1200, Xpress 1250
  * RS690:	Radeon X1200, X1250, X1270
  * RS740:	RS740, RS740M
  * RS780:	Radeon HD 3100/3200/3300 Series
  * R700:	Radeon R700
  * RV710:	Radeon HD4570, HD4350
  * RV730:	Radeon HD4670, HD4650
  * RV740:	Radeon HD4770. EXPERIMENTAL AND UNTESTED
  * RV770:	Radeon HD 4800 Series; Everest, K2, Denali ATI FirePro
  * RV790:	Radeon HD 4890
  * M92:	Mobility Radeon HD4330, HD4530, HD4570. EXPERIMENTAL
  * M93:	Mobility Radeon M93. EXPERIMENTAL AND UNTESTED
  * M96:	Mobility Radeon HD4600
  * M97:	Mobility Radeon HD4860. EXPERIMENTAL AND UNTESTED
  * M98:	Mobility Radeon HD4850, HD4870

En la tabla sobre estas líneas están los modelos anunciados comercialmente por los fabricantes como ATI Radeon HD 3200 que es una placa integrada y el chipset correspondiente. Luego muchos chipsets están agrupados por sus características en tres grupos:

  • R500 style hardware: R5xx, RV5xx, RS6xx, RS740, M52 and up
  • R600 style hardware: R6xx, RV6xx, RS780, M64 and up
  • R700 style hardware: RV7xx

Una vez que determinamos si nuestro hardware de video corresponde a la serie R500, la R600 o la R700, podemos ir a ver qué funcionalidades ya están implementadas en el driver libre.

En http://www.x.org/wiki/RadeonFeature se lista el soporte al presente de cada serie para diversos aspectos como la aceleración 2D, 3D  o la salida a TV o HDMI.

Para saber qué aplicaciones 3D (como Compiz, juegos y Google Earth) han sido probadas y cómo funcionan se puede consultar esta página http://www.x.org/wiki/RadeonProgram.

En cuanto pueda voy a probar la versión alfa 3 de Lucid Lynx en mi equipo y voy a ver si puedo hacer andar el soporte 3D o si tendré que esperar a instalarlo en su versión final.

Actualización: efectivamente los efectos del escritorio 3D de Compiz funcionan en la versión alfa 3 de Ubuntu 10.04 Lucid Lynx sin tener que hacer ninguna configuración especial. Lo probé en una ATI Radeon HD 3200 ejecutando desde el disco USB de Ubuntu.

PPA para Karmic con Vorbis aoTuV beta 5.7

Encontré un PPA con la última versión del codec Vorbis disponible, aoTuV beta5.7

https://launchpad.net/~towolf/+archive/codecs

La ventaja de instalar esos paquetes es que obtenemos tenemos mejor calidad para bitrates bajos al comprimir audio en formato Vorbis en todas las aplicaciones existentes. Además se utiliza ese mismo codec para el audio de los videos que comprimimos en formato Theora.

Es así que podemos tener audio comprimido a 64 kbps (muy bajo) con mejor calidad que antes. La comunidad de audiófilos que sigue la evolución de Vorbis unánimemente recomienda usar esta versión por tener mejor calidad a un bitrate dado que la versión oficial.

Cuando salga libvorbis 1.3, se van a integrar los cambios que presenta esa versión, pero podemos ya usarlos sin esperar a que Monty haga su merge.

Página oficial de aoTuV: http://www.geocities.jp/aoyoume/aotuv/