¿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.

Windows 7 Menos Seguro que Vista por Omisión

Windows 7 incorpora una mejora al mecanismo de control de acceso del usuario al sistema (UAC). El objetivo es reducir la cantidad de veces que aparece la ventana pidiendo confirmación y el resultado es que Windows 7 es menos seguro que Vista. ¿Por qué?

Ahora hay una lista de programas que no requieren autorización para adquirir permisos de administrador. Esos programas son por ejemplo la calculadora y el bloc de notas. De esa forma cuando se abre un archivo de sistema con el bloc de notas, nos ahorramos la ventana de confirmación. El problema es que existe una funcionalidad documentada en Windows que permite a cualquier programa ejecutar código como si fuera otro (como el bloc de notas) y por lo tanto es posible para cualquier programa adquirir permisos de administrador sin pedirle confirmación al usuario. En la práctica significa que con la configuración por omisión de Windows 7 toda confirmación es irrelevante, porque un programa malicioso puede no pedir jamás confirmación y obtener los permisos.

La única solución es poner el control en el nivel máximo, lo que revierte el comportamiento a como era en Vista y prohíbe a cualquier programa adquirir permisos de administrador sin pedir confirmación, incluyendo el bloc de notas. Así sí es seguro, pero pregunta a cada rato.

Microsoft dice que la ventanita de confirmación no es una medida de seguridad (a pesar de que su ícono es un escudo) y hace notar que ahora Windows y el Internet Explorer tienen más medidas de seguridad que nunca.

La triste realidad es que Windows no puede encontrar una forma de ser seguro sin hacer que dejen de funcionar muchos programas porque tiene años de tradición y legado dándole a todo usuario control total sobre el sistema y en versiones previas directamente ignorando la separación entre usuarios.

Hay un video mostrando cómo se puede escalar privilegios usando Windows 7: http://leo.lss.com.au/W7E_VID_INT/W7E_VID_INT.htm

Y varios artículos en la prensa describiendo el tema: