Rendimiento de hyperthreading intensivo FP en los últimos Xeons

Question

Recientemente hemos adquirido una estación de trabajo dual Intel X5650 para ejecutar una simulación intensiva de punto flotante, en Ubuntu 10.04.

Cada X5650 tiene 6 núcleos, por lo que hay 12 núcleos en total. El código es trivialmente paralelo, así que lo he estado ejecutando principalmente con 12 hilos y observando aproximadamente el "1200%" de la utilización del procesador a través de "arriba".

HyperThreading está habilitado en el BIOS, por lo que el sistema operativo ve nominalmente 24 núcleos disponibles. Si aumento el número de subprocesos a 24, la parte superior informa de aproximadamente 2000% de utilización del procesador; sin embargo, no parece que el rendimiento real del código aumente en 20/12.

Mi pregunta es: ¿cómo funciona HyperThreading en la última generación de Xeons? ¿Se beneficiaría un código intensivo de coma flotante al programar más de un hilo por núcleo? ¿La respuesta cambia si el conjunto de trabajo está en el orden del tamaño de caché, en comparación con varias veces más grande, o si hay operaciones de E/S sustanciales (por ejemplo, escribir salidas de simulación en el disco)?

Además, ¿cómo debo interpretar los porcentajes de utilización del procesador desde "arriba" cuando está habilitado el hyperthreading?

Answer 1

Con HT, el sistema operativo programará 2 hilos en cada núcleo al mismo tiempo. La utilización informada por top es básicamente la cantidad promedio de subprocesos en el estado "en ejecución" durante su intervalo de muestreo (generalmente 1 segundo). Los subprocesos en ejecución están disponibles para que se ejecute la CPU, pero es posible que no se esté trabajando mucho, p. si están estancados principalmente en fallas de caché.

Cuando un hilo está bloqueado en E/S reales (red, disco, etc.), el sistema operativo lo desprogramará desde el núcleo y programará otro hilo listo, por lo que HT no ayudará.

HT intenta obtener una mayor utilización de las unidades de ejecución de matemáticas sin duplicar realmente mucho hardware en el núcleo. Si un subproceso tiene suficiente paralelismo de nivel de instrucción y no pierde mucho el caché, entonces mayormente se llenará los recursos del núcleo y HT no ayudará. Para las aplicaciones pesadas de FP con datos que no caben en la memoria caché, HT probablemente no ayude mucho, ya que ambos hilos utilizan las mismas unidades de ejecución (matemáticas SSE) y ambos necesitan más que la caché completa; de hecho, es probable herir ya que estarán compitiendo por la memoria caché y agitando más. Por supuesto, depende exactamente de lo que esté haciendo y de cómo sean sus patrones de acceso a los datos.

HT en su mayoría ayuda en el código ramificado con patrones de acceso irregulares e impredecibles. Para un código intensivo en FP, a menudo puedes mejorar con 1 hilo por núcleo y un diseño cuidadoso de tus patrones de acceso (por ejemplo, buen bloqueo de datos).

Answer 2

He desarrollado un código paralelo de muy alto rendimiento y embarazoso que se ejecutará en tantos núcleos como estén disponibles. Inicialmente se ejecutó en una computadora portátil AMD de 2 núcleos, pero cuando pasé a una computadora portátil Intel 2-core + HT la mejora de la ejecución fue marginal: la presencia de una CPU de generación posterior, dos núcleos más (HT) y 670Mhz de reloj de la CPU superior podrían no ser notado Cuando restringí el código a dos hilos que no eran de HT, la aceleración esperada en el caso de 2 núcleos se produjo de repente y pude respirar mejor.

Cuando cambié el nivel de optimización del compilador de 3 a 2 y finalmente 1 hyperthreading comenzó a mostrar su promesa. Los mejores resultados se obtuvieron en el nivel de optimización 1 y fue aproximadamente un 50% mejor que el caso de 2 códigos sin HT.

Lo que creo que sucede es que el código muy bien escrito y optimizado utiliza un núcleo al máximo, en la medida en que básicamente no hay recursos adicionales disponibles para ejecutar un segundo hilo.Por supuesto, se ejecutará el segundo subproceso pero los dos hilos colisionarán siempre que necesiten el mismo recurso. Harán esto mucho más a menudo debido al alto nivel de optimización.

Al tener un código menos optimizado o más denso, hubo una oportunidad para que los hilos "intercalen" sus accesos a los recursos del núcleo en mayor medida. Esto dio lugar a dos subprocesos cada uno alrededor del 75% de la tasa que el código más altamente optimizado se ejecutaría en un núcleo. Cuando lo resuma, el código menos optimizado en dos hilos produciría 1.5 veces el rendimiento del más optimizado en uno.

He entretenido la idea de escribir código para ver qué nivel de "intercalación" de recursos básicos que se puede lograr y la hipótesis de que tal subproceso pasaría la mitad de su ejecución de un bucle interno en una CPU. en el otro. El resultado esperado "sería" que uno ejecute un medio bucle interno detrás del otro para lograr el mejor "intercalado" de recursos.