¿Cómo funciona la afinidad del procesador de Windows con las CPU hiperprocesadas?

¿Cómo funciona la afinidad del procesador de Windows con las CPU hiperprocesadas? Usemos un ejemplo (en la imagen) de un sistema con cuatro núcleos, cada uno con un núcleo virtual hiperhilo.

1. ¿Qué núcleos corresponden a cada "CPU" a continuación?
2. ¿(Digamos) CPU 6 y CPU 7 a continuación representan un núcleo; El HT y el núcleo real?
3. Si, por ejemplo, la CPU 6 representa un núcleo real y la CPU 7 un núcleo HT, ¿un hilo asignado solo a la CPU7 obtendrá solo los recursos sobrantes de un núcleo real? (suponiendo que el núcleo ejecuta otras tareas)
4. ¿El hyperthreading se gestiona por completo dentro del procesador de tal manera que los hilos están malabarizados internamente? Si es así, ¿está eso en el alcance de la CPU o en el alcance central? Ejemplo: si la CPU 6 y 7 representan un núcleo, ¿no importa a qué proceso se le asigne porque la CPU asignará recursos según corresponda a un hilo en ejecución?
5. Noté que los procesos de un solo subproceso de larga ejecución rebotan bastante en los núcleos, al menos según el administrador de tareas. ¿Significa esto que asignar un proceso a un solo núcleo mejorará un poco el rendimiento (evitando cambios de contexto e invalidaciones de caché, etc.)? Si es así, ¿puedo saber que no estoy asignando "solo un núcleo virtual"?

Todo esto es muy vago y confuso para mí. HT es excelente, pero seguro que parece reducir la transparencia de la asignación de recursos.

¿Qué núcleos corresponden a cada "CPU" a continuación?

Suponiendo que tenemos Core 1, 2, 3 y 4, CPU4 y CPU5 representan el núcleo 3.

¿(Digamos) CPU 6 y CPU 7 a continuación representan un núcleo; El HT y el núcleo real?

No hay distinción entre los dos: ambos tienen interfaces de hardware físico para la CPU, la interfaz lógica se implementa en hardware (consulte la Hoja de datos del procesador Intel Core, Volumen 1 para más detalles). Básicamente, cada núcleo tiene dos unidades de ejecución separadas, pero comparte algunos recursos comunes entre ellas. Esta es la razón por la cual, en ciertos casos, hyperthreading realmente puede reducir el rendimiento.

Si, por ejemplo, la CPU 6 representa un núcleo real y la CPU 7 un núcleo HT, ¿un hilo asignado solo a la CPU7 obtendrá solo los recursos sobrantes de un núcleo real? (suponiendo que el núcleo ejecuta otras tareas)

Véase más arriba. Un subproceso asignado a SOLO CPU6 o SOLO CPU7 se ejecutará a la misma velocidad exacta (suponiendo que el subproceso haga el mismo trabajo y los otros núcleos del procesador estén inactivos). Windows conoce los procesadores habilitados para HT, y el planificador de procesos tiene en cuenta estas cosas.

¿El hyperthreaded se gestiona por completo dentro del procesador de tal manera que los hilos están malabarizados internamente? Si es así, ¿está eso en el alcance de la CPU o en el alcance central? Ejemplo: si la CPU 6 y 7 representan un núcleo, ¿no importa a qué proceso se le asigne porque la CPU asignará recursos según corresponda a un hilo en ejecución?

Ambos. El hardware en sí mismo no programa en qué núcleos ejecutar programas, ese es el trabajo del sistema operativo. Sin embargo, la propia CPU es responsable de compartir los recursos entre las unidades de ejecución reales, e Intel dicta cómo puede escribir código para que esto sea lo más eficiente posible.

Noté que los procesos de un solo subproceso de larga ejecución rebotan bastante en los núcleos, al menos según el administrador de tareas. ¿Significa esto que asignar un proceso a un solo núcleo mejorará un poco el rendimiento (evitando cambios de contexto e invalidaciones de caché, etc.)? Si es así, ¿puedo saber que no estoy asignando "solo un núcleo virtual"?

Ese es un comportamiento normal, y no, asignarlo a un solo núcleo no mejorará el rendimiento. Dicho esto, si por alguna razón desea asegurarse de que un solo proceso se ejecute solo en un único núcleo físico, asígnelo a un único procesador lógico.

La razón por la cual el proceso "rebota" se debe al programador del proceso. Este es un comportamiento normal, y lo más probable es que experimente un rendimiento reducido al limitar en qué núcleos se puede ejecutar el proceso (independientemente de cuántos subprocesos tenga), ya que el planificador de procesos ahora tiene que trabajar más para que todo funcione con las restricciones impuestas. Sí, esta penalización puede ser insignificante en la mayoría de los casos, pero la conclusión es que, a menos que tenga una razón para hacerlo, ¡no lo haga !

Se supone que el diseño de la CPU está organizado para que un sistema operativo que no puede reconocer todas sus CPU obtenga el máximo rendimiento posible. Eso significará que se enumerará un núcleo virtual de cada núcleo físico antes de que se enumere un segundo núcleo virtual de cualquier núcleo físico.

Por ejemplo, supongamos que tiene cuatro núcleos hiperprocesados, denominados A, B, C y D. Si supone que A y B comparten un caché L2 y C y D comparten un caché L2, el orden debería ser algo así como:
0 = A1 1 = C1 2 = B1 3 = D1 4 = A2 5 = C2 6 = B2 7 = D2

De esa manera, un sistema operativo que solo toma dos CPU puede usar todo el caché L2. Además, un sistema operativo que solo toma cuatro CPU puede usar todas las unidades de ejecución.

Nuevamente, así es como se supone que debe ser.

Por supuesto, si está utilizando un sistema operativo que comprende la topología de su CPU, no importa. El BIOS completa una tabla que explica qué núcleos comparten unidades de ejecución, cuáles comparten cachés, etc. Todos los sistemas operativos modernos que es probable que utilice y que sean totalmente compatibles con su CPU comprenden la topología completa de la CPU.

1. La forma en que corresponden depende de cómo su CPU y placa base enumeran e identifican los núcleos. Lo que se supone que debe suceder es que los sockets físicos se enumeran primero, los núcleos lógicos a continuación y los núcleos virtuales al final. En su caso, los núcleos 0-3 deben ser núcleos físicos y 4-7 los núcleos HT virtuales. La razón principal de esto es que, en caso de que ejecute un sistema operativo que no pueda manejar todas las unidades de ejecución disponibles, es más probable que obtenga las unidades más independientes primero que las compartidas. No sería bueno si un sistema operativo hipotético de 2 CPU solo encontrara un par HT en su sistema en lugar de 2 núcleos distintos. (Este fue un problema real para algunos sistemas HT anteriores, antes de que los programadores del núcleo pudieran actualizarse para las nuevas CPU).
2. No. Ver 1.
3. No. HT es más complejo que eso. Recuerde que los 2 núcleos virtuales a menudo comparten algunos recursos mientras que otros bits están separados, pero que solo uno u otro puede ejecutarse a la vez.
4. Más o menos. Su ejemplo (dados los supuestos) es generalmente correcto. Sin embargo, si la aplicación puede saber qué tipo de carga de trabajo se está ejecutando, puede ayudar al sistema operativo a programar los subprocesos de manera adecuada.
5. Hay una muy buena razón para el salto central: distribuir la carga de trabajo térmica. Dado que, en muchos casos, los cachés de nivel superior (L2, L3) se comparten en todos los núcleos de todos modos, el salto de núcleo no tendrá un impacto significativo en el rendimiento, pero el impacto térmico será significativo porque no tendrá un "punto caliente" en el núcleo que se ejecuta constantemente mientras que los otros permanecen inactivos. Ahora, cruzar sockets en un sistema de sockets múltiples (particularmente un sistema NUMA) puede tener un impacto significativo en el rendimiento. Sin embargo, la mayoría de los programadores lo saben y lo tienen en cuenta.

En última instancia, lo que se reduce a esto es que a menudo hay poco que usted (como usuario final) pueda hacer con la afinidad de subprocesos para impactar significativamente el rendimiento además de asegurarse de que está ejecutando un sistema operativo actualizado que conoce los diversos bits en tu sistema.

Si encuentra cargas de trabajo en las que la asignación manual de afinidad tiene un impacto significativo, infórmelo como un error al desarrollador de la aplicación para que el programa pueda repararse.