¿Cuántas CPU se deben utilizar con Hyperthreading?

Digamos que tengo una CPU de servidor con 18 núcleos, con hyperthreading activado, lo que significa que puedo ver 36 cpus en htop.

Para utilizar completamente la CPU y no afectar el rendimiento de un solo hilo, ¿debería apuntar a que los 36 "núcleos" se ejecuten al 100%, y los núcleos HT simplemente harán menos trabajo y aún reportarán el 100%, o eso significaría que el ¿Los núcleos "completos" ya están siendo interrumpidos por la tarea en su "núcleo HT" y, por lo tanto, realizan menos trabajo de un solo subproceso?

Soy consciente de que hay muchas variables que afectan el rendimiento de HT, solo quiero saber qué significan los medidores de CPU cuando se trata de HT.

Si se permite que el segundo núcleo virtual contribuya cuando el primero estaría bloqueado, es mejor que no , por lo que obtendrá (al menos) un poco más de trabajo.

La pregunta es: ¿cuándo tener dos hilos diferentes hace que uno funcione peor? La predicción de rama y las dependencias entre instrucciones no cambiarán. Esperando el acceso a la memoria ahora ... los dos hilos compiten por el acceso a la memoria, tanto en la utilización de caché como en el ancho de banda.

Si tiene algunas CPU funcionando con HT y otras no, ¿eso también significa que asignará hilos específicos a un tipo u otro? Creo que no: sus programas ejecutarán sus hilos en núcleos virtuales aleatorios. Entonces, ¿cómo ayuda dividir la configuración? Como cada CPU tiene su propia memoria caché, el único efecto se debe al ancho de banda de la memoria y la carga de la coherencia de la memoria caché.

En general, llega a un punto en el que tener algo más que podría estar haciendo es más costoso que dejar que algunas unidades de ejecución de la CPU estén inactivas. Esto no depende de la cantidad de subprocesos directamente, sino de lo que están haciendo los subprocesos y la arquitectura de memoria detallada y los matices de rendimiento de los diversos componentes.

No hay una respuesta simple. Incluso con un programa específico en mente, la máquina puede diferir de la de las personas que relatan sus propias experiencias.

Tienes que probarlo tú mismo y medir lo que es más rápido, con ese trabajo específico en esa máquina exacta. E incluso entonces, puede cambiar con las actualizaciones de software y el cambio de uso con el tiempo.

Echa un vistazo al volumen 3 de la obra magna de Anger . Si observa detenidamente algún procesador específico, puede encontrar recursos limitantes entre los muchos pasos necesarios para ejecutar el código. Debe encontrar un caso en el que el exceso de compromiso haga que se ejecute más lentamente, en lugar de no tomar más trabajo. En general, eso significaría algún tipo de almacenamiento en caché; y donde el recurso se comparte entre subprocesos.

¿Qué significa el medidor de CPU: informa todo el tiempo que no ha pasado ejecutando el subproceso inactivo. Ambos hilos lógicos asignados a un núcleo no estarán inactivos aunque el trabajo real realizado en uno de ellos pueda ser pequeño. El tiempo dedicado a la tubería se atascó durante algunos ciclos hasta que los resultados estén listos, se recupere la memoria, las operaciones atómicas estén cercadas, etc. Del mismo modo, no causa que el hilo se archive como "no listo", por lo que no estará inactivo, y el tiempo todavía se muestra como en uso. Esperar en RAM no se mostrará como inactivo. Solo algo como E / S bloqueará el hilo y detendrá el tiempo de carga hacia él. Un mutex de sistema operativo en general lo hará, pero con el surgimiento de sistemas multinúcleo ya no es algo seguro, ya que un "spinlock" no hará que el hilo vuelva a la plataforma.

Por lo tanto, un medidor de CPU del 100% no significa que todo funcione sin problemas, si la CPU a menudo está atascada esperando memoria. Un número menor de núcleos lógicos que muestren el 90% bien podría estar haciendo más trabajo, ya que termina la reducción de números y ahora está esperando en el disco.

Así que no te preocupes por el medidor de CPU. Mire el progreso real realizado, solo .

Los medidores de CPU son muy malos para decirle cuánto más rendimiento puede exprimir de sus CPU hiperprocesadas. Para eso, debe ejecutar sus propios puntos de referencia con varias tasas de sobre-suscripción de núcleo físico. Hay algunas cargas de trabajo que funcionan mejor con HT completamente desactivado, así que incluya ese caso en sus pruebas también. ¡Podría ser 1: 2 (36 trabajadores paralelos), o 1: 1.5, o incluso 1: 2.5! Depende de tu carga de trabajo.

Más detalladamente, HT se implementa en el silicio de manera que reduce el tiempo que el procesador pasa inactivo cuando se necesita cambiar un contexto o falla una predicción de bifurcación. Esto hace que sea más fácil alcanzar el 100% de uso de la unidad de ejecución que con trucos puros del sistema operativo. HT ha evolucionado desde su introducción, y hay más paralelismo en los chips modernos que los que estábamos usando hace 10 años.

Hay dos perfiles de ejecución que afectarán dónde está su punto óptimo de sobre-suscripción:

• Larga duración de ejecución . Si sus trabajadores se ejecutan durante minutos u horas antes del reciclaje, como trabajos de renderizado grandes o modelado de entornos, obtendrá un rendimiento de núcleo único más eficiente por trabajador. Esto reducirá su proporción.
• Corta duración de ejecución . Si sus trabajadores realizan ciclos en segundos o minutos pequeños, como los subprocesos de aplicaciones web, la sobrecarga involucrada en activar un nuevo proceso significa que su proporción será mayor.

Debería ver los 36 núcleos funcionando al 100%, suponiendo que el software pueda hacer eso (lo cual no es trivial, la programación puede ser complicada con esa cantidad de núcleos, por lo que son aceptables las caídas por debajo del 100%).

Obviamente cuando "divide" un mineral con hyperthreading, el significado de esos 200% no es "2x100% - en el trabajo realizado. Pero esto es invisible para cualquier medida tomada (que proviene de la utilización de la CPU y no tiene ningún concepto del trabajo realizado). La cantidad de trabajo que se realiza depende de cuál sea el trabajo: se espera que la mayor parte del tiempo el trabajo sin hiperprocesos sea superior a 1,5 veces.

La forma en que se implementa hyperthreading varía con la CPU uarch específica. De Nehalem a Skylake, Intel redujo significativamente las partes compartidas de la proporción fija (es decir, 50/50) de la tubería, dirigiéndose a estructuras dinámicamente compartidas.

De todos modos, en términos generales, habilitar HT condujo a una ejecución de un solo subproceso ligeramente más lenta, pero debido a cómo funciona el planificador de Linux, esto solo sucede cuando el número o el subproceso en ejecución es mayor que el número de núcleos físicos. Como en tales situaciones (cuando subprocesos> núcleos) normalmente se valora el rendimiento total de máxima importancia, hyperthreading sigue siendo una ganancia neta.

¿Cómo es esto posible? El punto clave a entender es que la CPU no presenta los núcleos físicos y los virtuales como núcleos iguales, sino que expone a estos últimos de una manera que el planificador de Linux puede evitar programarlos si hay otros núcleos físicos disponibles. En otras palabras, primero usa todos los núcleos físicos, luego comienza a usar el virtual.

Esto significa que, en general, HyperThreading es una característica muy valiosa (otros procesadores, como Power8, utilizan técnicas SMT aún más profundas) y que para maximizar el rendimiento debe habilitarlo, cargando la CPU con al menos un hilo por núcleo virtual o físico. Para un ejemplo práctico, para extraer el rendimiento completo de una CPU de 18 núcleos debe usar al menos 36 hilos.

Existen dos excepciones:

1. si todo lo que desea es minimizar la latencia de un conjunto limitado de subprocesos (donde subprocesos <núcleos físicos), puede deshabilitar HT
2. CPU muy antigua (Pentium4 y, de una manera mucho más pequeña, Nehalem) tienen reglas de partición inflexibles que obligan a la CPU a dividir muchos recursos clave en una proporción de 50/50, independientemente del estado / carga del segundo hilo. En este caso, tuvo que comparar su caso de uso para asegurarse de que el rendimiento agregado valga el rendimiento significativamente menor de un solo hilo.