Come funziona l'affinità del processore Windows con le CPU hyperthreaded?

Come funziona l'affinità del processore Windows con le CPU hyperthreaded? Facciamo un esempio (nella foto) di un sistema con quattro core, ciascuno con un core virtuale hyper-thread.

1. Quali core corrispondono a ciascuna "CPU" di seguito?
2. (Diciamo) CPU 6 e CPU 7 sotto rappresentano un core; l'HT e il vero core?
3. Se, ad esempio, CPU 6 rappresenta un core reale e CPU 7 un core HT, un thread assegnato solo a CPU7 otterrà solo le risorse rimanenti di un core reale? (supponendo che il core stia eseguendo altre attività)
4. L'hyperthreading è gestito interamente all'interno del processore in modo tale che i thread siano manipolati internamente? In tal caso, è nell'ambito della CPU o dell'ambito principale? Esempio: se le CPU 6 e 7 rappresentano un core, non importa a quale processo è assegnato perché la CPU assegnerà le risorse appropriate a un thread in esecuzione?
5. Ho notato che i processi a thread singolo di lunga durata vengono rimbalzati un po 'attorno ai core, almeno secondo il task manager. Questo significa che l'assegnazione di un processo a un singolo core migliorerà leggermente le prestazioni (evitando cambi di contesto e invalidazioni della cache, ecc.)? In tal caso, posso sapere che non sto assegnando a "solo un core virtuale"?

Questo è tutto molto vago e confuso per me. HT è fantastico, ma sembra sicuramente ridurre la trasparenza dell'allocazione delle risorse.

Quali core corrispondono a ciascuna "CPU" di seguito?

Supponendo che abbiamo Core 1, 2, 3 e 4, CPU4 e CPU5 rappresentano il core 3.

(Diciamo) CPU 6 e CPU 7 sotto rappresentano un core; l'HT e il vero core?

Non c'è distinzione tra i due: entrambi hanno interfacce hardware fisiche con la CPU, l'interfaccia logica è implementata nell'hardware (consultare la scheda tecnica del processore Intel Core, Volume 1 per maggiori dettagli). Fondamentalmente, ogni core ha due unità di esecuzione separate, ma condivide alcune risorse comuni tra loro. Questo è il motivo per cui in alcuni casi l'hyperthreading può effettivamente ridurre le prestazioni.

Se, ad esempio, CPU 6 rappresenta un core reale e CPU 7 un core HT, un thread assegnato solo a CPU7 otterrà solo le risorse rimanenti di un core reale? (supponendo che il core stia eseguendo altre attività)

Vedi sopra. Un thread assegnato a SOLO CPU6 o SOLO CPU7 verrà eseguito alla stessa velocità esatta (supponendo che il thread faccia lo stesso lavoro e che gli altri core nel processore siano inattivi). Windows conosce i processori abilitati per HT e lo scheduler dei processi tiene conto di questi aspetti.

L'hyperthread è gestito interamente all'interno del processore in modo tale che i thread siano manipolati internamente? In tal caso, è nell'ambito della CPU o dell'ambito principale? Esempio: se le CPU 6 e 7 rappresentano un core, non importa a quale processo è assegnato perché la CPU assegnerà le risorse appropriate a un thread in esecuzione?

Tutti e due. L'hardware vero e proprio non pianifica su quali core eseguire i programmi, questo è il lavoro del sistema operativo. La CPU stessa, tuttavia, è responsabile della condivisione delle risorse tra le unità di esecuzione effettive e Intel impone come è possibile scrivere codice per renderlo il più efficiente possibile.

Ho notato che i processi a thread singolo di lunga durata vengono rimbalzati un po 'attorno ai core, almeno secondo il task manager. Questo significa che l'assegnazione di un processo a un singolo core migliorerà leggermente le prestazioni (evitando cambi di contesto e invalidazioni della cache, ecc.)? In tal caso, posso sapere che non sto assegnando a "solo un core virtuale"?

Questo è un comportamento normale e no, assegnarlo a un singolo core non migliorerà le prestazioni. Detto questo, se per qualche motivo vuoi assicurarti che un singolo processo sia eseguito solo su un singolo core fisico, assegnalo a qualsiasi singolo processore logico.

Il motivo per cui il processo "rimbalza" è dovuto all'utilità di pianificazione del processo. Questo è un comportamento normale e molto probabilmente sperimenterai prestazioni ridotte limitando su quali core può essere eseguito il processo (indipendentemente da quanti thread ha), poiché lo scheduler del processo ora deve lavorare di più per far funzionare tutto con le restrizioni imposte. Sì, questa penalità può essere trascurabile nella maggior parte dei casi, ma la linea di fondo è a meno che tu non abbia un motivo per farlo, non farlo !

Il layout della CPU dovrebbe essere organizzato in modo tale che un sistema operativo che non è in grado di riconoscere tutte le CPU ottenga le massime prestazioni possibili. Ciò significa che verrà elencato un core virtuale da ciascun core fisico prima che venga elencato un secondo core virtuale da qualsiasi core fisico.

Ad esempio, supponiamo di avere quattro core hyper-thread, chiamati A, B, C e D. Se si presume che A e B condividano una cache L2 e C e D condividano una cache L2, l'ordine dovrebbe essere simile a:
0 = A1 1 = C1 2 = B1 3 = D1 4 = A2 5 = C2 6 = B2 7 = D2

In questo modo, un sistema operativo che prende solo due CPU può usare tutta la cache L2. Inoltre, un sistema operativo che prende solo quattro CPU può usare tutte le unità di esecuzione.

Ancora una volta, questo è il modo in cui dovrebbe essere.

Naturalmente, se stai utilizzando un sistema operativo in grado di comprendere la topologia della CPU, non importa. Il BIOS compila una tabella che spiega quali core condividono le unità di esecuzione, quali condividono le cache e così via. Ogni moderno sistema operativo che è probabile che utilizzi che supporti completamente la tua CPU comprende l'intera topologia della CPU.

1. La loro corrispondenza dipende da come la CPU e la scheda madre enumerano e identificano i core. Ciò che dovrebbe accadere è che i socket fisici vengano prima elencati, i core logici successivamente e i core virtuali infine. Nel tuo caso, i core 0-3 dovrebbero essere core fisici e 4-7 i core HT virtuali. Il motivo principale di ciò è che nel caso in cui si esegua un sistema operativo che non è in grado di gestire tutte le unità di esecuzione disponibili, è molto probabile che le unità più indipendenti siano prima di quelle condivise. Non sarebbe utile se un ipotetico sistema operativo a 2 CPU trovasse una coppia HT nel tuo sistema invece di 2 core distinti. (Questo è stato un vero problema per alcuni dei primi sistemi HT, prima che gli scheduler del kernel potessero essere aggiornati per le nuove CPU.)
2. No. Vedi 1.
3. No. HT è più complesso di così. Ricorda che i 2 core virtuali spesso condividono alcune risorse mentre altri bit sono separati, ma che solo uno o l'altro può essere eseguito alla volta.
4. Una specie di. Il tuo esempio (dati i presupposti) è generalmente corretto. Tuttavia, se l'applicazione può sapere che tipo di carico di lavoro è in esecuzione, può aiutare il sistema operativo a pianificare i thread in modo appropriato.
5. C'è un ottimo motivo per il core hopping: diffusione del carico di lavoro termico. Dato che in molti casi le cache di livello superiore (L2, L3) sono comunque condivise tra tutti i core, il core hopping non avrà un impatto significativo sulle prestazioni, ma l'impatto termico sarà significativo perché non si avrà un "hot spot" su l'unico core che è costantemente in esecuzione mentre gli altri rimangono inattivi. Ora, l'attraversamento di prese in un sistema a più prese (in particolare un sistema NUMA) può avere un impatto significativo sulle prestazioni. Molti programmatori ne sono consapevoli e lo prendono in considerazione.

In definitiva, ciò che si riduce è che spesso c'è poco che tu (come utente finale) puoi fare con l'affinità dei thread per influire in modo significativo sulle prestazioni oltre a garantire che stai eseguendo un sistema operativo aggiornato che conosce i vari bit in il tuo sistema.

Se trovi carichi di lavoro in cui l'assegnazione manuale dell'affinità ha un impatto significativo, segnalala come bug allo sviluppatore dell'applicazione in modo che il programma possa essere riparato.