¿Qué razones podría tener un programador para querer desactivar hyperthreading?

Mi compañía acaba de comprar computadoras nuevas para reemplazar las viejas máquinas con Windows XP de 2GB. Alguien en mi equipo notó que venían con hyperthreading deshabilitado, y les dijo a todos que reiniciaran y lo encendieran. ¿Hay algún beneficio en programar en una máquina con hyperthreading deshabilitado?

Sí, he trabajado en una aplicación que funcionó mejor cuando se ejecuta en una máquina con HT deshabilitado .

Lo que sucedió fue que el código original crearía el doble que los subprocesos cuando se ejecuta en una máquina con hiperprocesos (lo que supondría que es una especie de punto de HT). Sin embargo, el rendimiento de esos hilos era muy sensible a la cantidad de caché disponible para el hilo. Con el doble de subprocesos luchando por una cantidad fija de caché, el caché disponible por subproceso era demasiado bajo y se producía una agitación: habría muchas más fallas de caché, más accesos a la memoria principal y el rendimiento tuvo un impacto sustancial en comparación con la ejecución con menos subprocesos y más caché por subproceso (que es lo que obtuvo si ejecutó la aplicación en una máquina con HT deshabilitado).

La solución definitiva fue hacer que la aplicación verificara mejor la plataforma HW y tomara en cuenta los tamaños de caché y la cantidad de caché considerada necesaria por subproceso al decidir cuántos subprocesos crear. En cualquier caso, el problema desapareció rápidamente con la generación posterior de CPU, que duplicó el tamaño de la caché (y en realidad comenzamos a ver un beneficio modesto de HT en ese momento). Sin embargo, todo el episodio dejó un legado largo y duradero de recomendar que HT siempre se desactive en cualquier plataforma en la que se ejecute nuestro SW, y las respuestas rápidas "¿ esa máquina no tiene HT habilitado? " Responde a cualquier problema de rendimiento. (Creo que el problema fundamental es que la mayoría de los no geeks simplemente no entienden qué es realmente HT).

No conozco los detalles técnicos, pero aparentemente si una aplicación (o el sistema operativo) no está optimizada para el subprocesamiento, el subproceso puede realmente disminuir el rendimiento.

Incluso Intel recomienda desactivarlo en este caso:

No se recomienda el uso de los siguientes sistemas operativos de escritorio con la tecnología Hyper-Threading. Si está utilizando uno de los siguientes sistemas operativos de escritorio, se recomienda que desactive la tecnología Hyper-Threading en el programa de configuración del BIOS del sistema: [...]

(Fuente: http://www.intel.com/support/processors/sb/CS-017343.htm )

Entonces, tal vez el fabricante (o el proveedor) quería tener cuidado.

Más que probable, el OEM solo estaba siendo conservador. Los OEM a menudo se envían con funciones avanzadas deshabilitadas (como HT, bit No-Execute, vt, etc.) desactivadas. La razón es que alguna circunstancia rara puede hacer que esas configuraciones fallen, y las personas que realmente desean las funciones pueden activarlas fácilmente.

Además, algunos errores raros en los sistemas operativos han dado lugar a posibles problemas de seguridad cuando algunas funciones están habilitadas. La tecnología de virtualización, por ejemplo, una vez tuvo ese problema. Entonces, es solo que el vendedor es conservador.

Hyperthreading es generalmente útil para escritorios interactivos, como máquinas de programación. Sin embargo, es posible que algunas personas quieran desactivarlo si sus aplicaciones se ejecutarán en servidores sin HT. Solo para reducir posibles diferencias de hardware.

Hyperthreading no agrega nuevos núcleos a la CPU. Todavía tiene una unidad aritmética / lógica, una unidad de coma flotante (...) por núcleo. Entonces, si tiene múltiples hilos / procesos que hacen cosas muy diferentes, HTT puede mejorar el rendimiento. Pero si tiene varios subprocesos que hacen más o menos las mismas cosas (no es raro en las aplicaciones de cálculo de números), el rendimiento puede verse gravemente afectado por HTT.

¿Quizás problemas de coherencia de caché en código multiproceso masivo? Si tiene cachés de CPU discretos, es teóricamente posible que dos subprocesos tengan los mismos datos en caché y los modifiquen al mismo tiempo con valores diferentes. Si tiene un caché unificado en algún punto entre las CPU y la memoria principal (ya sea L2 o L3), entonces es probable que exista algún mecanismo que evite esto, pero en CPU de gama baja con cachés más pequeños, tal vez no.

Alternativamente, puede ser posible que al habilitar hyperthreading en chips que no lo admitan arroje un código durante la POST, por lo que el proveedor de BIOS simplemente lo deja porque no saben qué tipo de CPU tendrá el sistema.

Una razón para no desactivar hyperthreading en una máquina desarrolladora es que puede ocultar algunos errores sutiles de subprocesos múltiples. Pero esto solo se aplica realmente en una máquina de procesador único de un solo núcleo. Multi-core expondrá, en todo caso, más errores de subprocesos múltiples durante las pruebas.

OTOH, dudo que vea un procesador de un solo núcleo con hyperthreading deshabilitado de forma predeterminada. Mi voto es sobre la respuesta de Sleskes.

Se escribió una gran cantidad de software antiguo en máquinas de un solo núcleo, y puede haber tenido errores al ejecutarlo en una máquina multinúcleo. Probablemente, la instrucción realmente tenía la intención de decir "Esto no funciona en máquinas multinúcleo", es solo que durante mucho tiempo, hyperthreading fue la única máquina multinúcleo que vería en uso común.