Quante CPU dovrebbero essere utilizzate con Hyperthreading?

Diciamo che ho un server CPU con 18 core, con hyperthreading attivo, il che significa che posso vedere 36 CPU in htop.

Per utilizzare appieno la CPU e non influire sulle prestazioni a thread singolo, dovrei puntare a far funzionare tutti e 36 i "core" al 100%, e i core HT faranno solo meno lavoro e continueranno a riportare il 100%, o avere questo significa che il i core "completi" sono già stati interrotti dall'attività sul suo "core HT" e quindi eseguono meno lavoro a thread singolo?

Sono consapevole che ci sono molte variabili che influenzano le prestazioni HT, voglio solo sapere cosa significano i misuratori di CPU quando si tratta di HT.

Se il secondo core virtuale è autorizzato a contribuire quando il primo sarebbe bloccato, è meglio che no , quindi si ottiene (almeno) un po 'di lavoro extra.

La domanda diventa: quando avere due thread diversi fa peggiorare uno? La previsione del ramo e le dipendenze tra le istruzioni non cambieranno. In attesa dell'accesso alla memoria ora ... i due thread competono sull'accesso alla memoria, sia nell'utilizzo della cache che nella larghezza di banda.

Se hai alcune CPU in esecuzione con HT e altre no, significa anche che assegnerai thread specifici a un tipo o all'altro? Non credo: i tuoi programmi eseguiranno i loro thread su core virtuali casuali. In che modo la suddivisione della configurazione aiuta? Poiché ogni CPU ha la propria cache, l'unico effetto è dovuto alla larghezza di banda della memoria e all'onere della coerenza della cache.

In generale, si raggiunge un punto in cui avere qualcosa in più che si potrebbe fare è più costoso che lasciare inattive alcune unità di esecuzione della CPU. Ciò non dipende direttamente dal numero di thread, ma da cosa stanno facendo i thread e dall'architettura di memoria dettagliata e dalle sfumature delle prestazioni dei vari componenti.

Non esiste una risposta semplice. Anche con un programma specifico in mente, la macchina può differire da quella delle persone che raccontano le proprie esperienze.

Devi provarlo tu stesso e misurare ciò che è più veloce, con quel lavoro specifico su quella macchina esatta. E anche allora, potrebbe cambiare con gli aggiornamenti del software e spostando l'utilizzo nel tempo.

Dai un'occhiata al volume 3 dell'opus magnum di Anger . Se si osserva attentamente un processore specifico, è possibile trovare risorse limitanti nella pipeline profonda di molti passaggi necessari per eseguire il codice. È necessario trovare un caso in cui l'eccessivo impegno lo induca a eseguire più lentamente, invece di non impegnarsi di più. In generale ciò significherebbe una sorta di memorizzazione nella cache; e dove la risorsa è condivisa tra i thread.

Cosa significa il misuratore della CPU: segnala tutto il tempo che non viene impiegato per eseguire il thread inattivo. Entrambi i thread logici assegnati a un core non saranno inattivi anche se il lavoro effettivo svolto su uno di essi potrebbe essere piccolo. Il tempo trascorso con la pipeline bloccata per alcuni cicli fino a quando i risultati non sono pronti, la memoria viene recuperata, le operazioni atomiche vengono recintate, ecc. Allo stesso modo non fare in modo che il thread venga archiviato come "non pronto", quindi non sarà inattivo, e il tempo è ancora in uso. L'attesa su RAM non verrà visualizzata come inattiva. Solo qualcosa come l'I / O bloccherà il thread e interromperà il tempo di ricarica. Un mutex del sistema operativo in generale lo farà, ma con l'ascesa di sistemi multicore non è più una cosa certa, poiché uno "spinlock" non farà tornare il thread sullo scaffale.

Quindi, un misuratore di CPU del 100% non significa che tutto vada liscio, se la CPU è spesso bloccata in attesa di memoria. Un numero inferiore di core logici che mostrano il 90% potrebbe benissimo fare più lavoro, poiché termina il crunching del numero e ora è in attesa sul disco.

Quindi non preoccuparti del misuratore della CPU. Guardate i progressi reali compiuti, solo .

I misuratori di CPU sono pessimi per dirti quante più prestazioni puoi spremere dalle tue CPU hyperthreaded. Per questo, è necessario eseguire i propri benchmark a vari tassi di abbonamento fisico-core. Esistono alcuni carichi di lavoro che funzionano meglio con HT completamente disattivato, quindi includi anche questo caso nei tuoi test. Potrebbe essere 1: 2 (36 lavoratori paralleli), 1: 1.5 o 1: 2.5! Dipende dal carico di lavoro.

Più in dettaglio, HT è implementato sul silicio in modo da ridurre il tempo che il processore trascorre inattivo quando è necessario cambiare un contesto o fallire una previsione del ramo. Ciò semplifica il raggiungimento dell'utilizzo dell'unità di esecuzione al 100% rispetto ai semplici trucchi del sistema operativo. HT si è evoluto dalla sua introduzione e c'è più parallelismo sui chip moderni rispetto a quelli che usavamo 10 anni fa.

Esistono due profili di esecuzione che influenzeranno il punto ottimale di abbonamento in eccesso:

• Lunga durata dell'esecuzione . Se i tuoi dipendenti corrono per minuti o ore prima del riciclo, come lavori di rendering di grandi dimensioni o modelli di ambiente, otterrai prestazioni single-core più efficienti per lavoratore. Ciò ridurrà il rapporto.
• Breve durata dell'esecuzione . Se i tuoi dipendenti eseguono il ciclo in pochi secondi o piccoli minuti, come i thread delle app web, l'overhead coinvolto nell'accensione di un nuovo processo significa che il tuo rapporto sarà più alto.

Dovresti vedere tutti e 36 i core in esecuzione al 100% - supponendo che il software possa farlo (cosa non banale - la pianificazione può essere complicata con quel numero di core, quindi sono accettabili cali inferiori al 100%).

Ovviamente quando si "divide" un minerale con hyperthreading, il significato di quel 200% non è "2x100% - nel lavoro svolto. Ma questo è invisibile a qualsiasi misurazione presa (che proviene dall'utilizzo della CPU e non ha alcun concetto di lavoro svolto). La quantità di lavoro che viene eseguita dipende da ciò che è il lavoro: da qualche parte sopra 1,5 volte il lavoro senza hyper threading è previsto per la maggior parte del tempo.

Il modo in cui viene implementato l'hyperthreading varia in base allo specifico uarch CPU. Da Nehalem a Skylake, Intel ha ridotto significativamente le parti condivise della pipeline a rapporto fisso (ovvero: 50/50), andando verso strutture dinamicamente condivise.

Ad ogni modo, in termini generali, l'abilitazione di HT ha portato a un'esecuzione a thread singolo leggermente più lenta, ma a causa del funzionamento dello scheduler Linux, ciò si verifica solo quando il numero o il thread in esecuzione è superiore al numero di core fisici. Come in tali situazioni (quando thread> core) in genere si valuta il throughput totale di massima importanza, l'hyperthreading rimane una vincita netta.

Come è possibile? Il punto chiave da capire è che la CPU non presenta i core fisici e quelli virtuali come core uguali, piuttosto espone questi ultimi in un modo che lo scheduler Linux può evitare di programmare su di essi se sono disponibili altri core fisici. In altre parole, utilizza prima tutti i core fisici, quindi inizia a utilizzare quello virtuale.

Ciò significa che, in genere, HyperThreading è una funzione molto preziosa (altri processori, come Power8, utilizza tecniche SMT ancora più profonde) e che per massimizzare la produttività è necessario abilitarlo, caricando la CPU con almeno un thread per core virtuale o fisico. Per un esempio pratico, per ottenere le massime prestazioni da una CPU a 18 core è necessario utilizzare almeno 36 thread.

Esistono due eccezioni:

1. se tutto ciò che vuoi è minimizzare la latenza da un set limitato di thread (dove thread <core fisici), puoi disabilitare HT
2. CPU molto vecchia (Pentium4 e, in modo molto più piccolo, Nehalem) hanno regole di partizione inflessibili che costringono la CPU a dividere molte risorse chiave con un rapporto 50/50, indipendentemente dallo stato / carico del secondo thread. In questo caso, è stato necessario confrontare il caso d'uso per essere sicuri che il throughput aggiunto valga le prestazioni a thread singolo significativamente inferiori.