Quanta velocità dà un hyper thread? (in teoria)
Risposte:
Come altri hanno già detto, questo dipende interamente dal compito.
Per illustrare questo, diamo un'occhiata a un benchmark reale:
Questo è stato tratto dalla mia tesi di laurea (attualmente non disponibile online).
Questo mostra l' accelerazione relativa 1 degli algoritmi di adattamento delle stringhe (ogni colore è un algoritmo diverso). Gli algoritmi sono stati eseguiti su due processori quad-core Intel Xeon X5550 con hyperthreading. In altre parole: c'erano un totale di 8 core, ognuno dei quali può eseguire due thread hardware (= "hyperthreads"). Pertanto, il benchmark verifica l'accelerazione con un massimo di 16 thread (che è il numero massimo di thread simultanei che questa configurazione può eseguire).
Due dei quattro algoritmi (blu e grigio) si ridimensionano più o meno linearmente su tutto l'intervallo. Cioè, beneficia dell'hyperthreading.
Altri due algoritmi (in rosso e verde; scelta sfortunata per i non vedenti) scalano linearmente fino a 8 fili. Dopo ciò, ristagnano. Ciò indica chiaramente che questi algoritmi non beneficiano dell'hyperthreading.
La ragione? In questo caso particolare è il carico di memoria; i primi due algoritmi richiedono più memoria per il calcolo e sono vincolati dalle prestazioni del bus di memoria principale. Ciò significa che mentre un thread hardware è in attesa di memoria, l'altro può continuare l'esecuzione; un caso d'uso privilegiato per i thread hardware.
Gli altri algoritmi richiedono meno memoria e non devono attendere il bus. Sono quasi interamente legati al calcolo e usano solo l'aritmetica dei numeri interi (operazioni sui bit, in effetti). Pertanto, non vi è alcun potenziale per l'esecuzione parallela e nessun beneficio dalle condutture di istruzioni parallele.
1 Vale a dire un fattore di accelerazione di 4 significa che l'algoritmo viene eseguito quattro volte più veloce di se fosse eseguito con un solo thread. Per definizione, quindi, ogni algoritmo eseguito su un thread ha un fattore di accelerazione relativo di 1.
Il problema è che dipende dall'attività.
L'idea alla base dell'hyperthreading è fondamentalmente che tutte le CPU moderne hanno più di un problema di esecuzione. Di solito più vicino a una dozzina o giù di lì adesso. Diviso tra Integer, virgola mobile, SSE / MMX / Streaming (come si chiama oggi).
Inoltre, ogni unità ha velocità diverse. Vale a dire che potrebbe essere necessario un ciclo di unità matematiche 3 intero per elaborare qualcosa, ma una divisione in virgola mobile a 64 bit potrebbe richiedere 7 cicli. (Questi sono numeri mitici non basati su nulla).
L'esecuzione fuori servizio aiuta molto a mantenere le varie unità il più complete possibile.
Tuttavia, ogni singola attività non utilizzerà ogni singola unità di esecuzione in ogni momento. Nemmeno la suddivisione dei thread può essere d'aiuto.
Quindi la teoria diventa fingendo che ci sia una seconda CPU, un altro thread potrebbe essere eseguito su di essa, usando le unità di esecuzione disponibili non utilizzate dalla tua transcodifica audio, che è roba SSE / MMX al 98%, e le unità int e float sono totalmente inattivo ad eccezione di alcune cose.
Per me, questo ha più senso in un singolo mondo di CPU, la falsificazione di una seconda CPU consente ai thread di attraversare più facilmente quella soglia con poca (se presente) codifica aggiuntiva per gestire questa falsa seconda CPU.
Nel mondo core 3/4/6/8, con CPU 6/8/12/16, aiuta? Boh. Tanto? Dipende dai compiti a portata di mano.
Quindi, per rispondere effettivamente alle tue domande, dipenderà dalle attività del tuo processo, quali unità di esecuzione sta utilizzando e nella tua CPU, quali unità di esecuzione sono inattive / sottoutilizzate e disponibili per quella seconda CPU falsa.
Si dice che alcune "classi" di materiale computazionale ne traggano beneficio (vagamente genericamente). Ma non esiste una regola rigida e veloce, e per alcune classi, rallenta le cose.
Ho alcune prove aneddotiche da aggiungere alla risposta di geoffc in quanto in realtà ho una CPU Core i7 (4 core) con hyperthreading e ho giocato un po 'con la transcodifica video, che è un compito che richiede una quantità di comunicazione e sincronizzazione ma ha abbastanza parallelismo con cui è possibile caricare completamente un sistema in modo efficace.
La mia esperienza con il gioco su quante CPU sono assegnate all'attività in genere utilizzando i 4 core "extra" hyperthreaded equivaleva a un equivalente di circa 1 CPU in più di potenza di elaborazione. I 4 core "hyperthreaded" aggiuntivi hanno aggiunto circa la stessa quantità di potenza di elaborazione utilizzabile che va da 3 a 4 core "reali".
Certo, questo non è strettamente un test equo in quanto tutti i thread di codifica sarebbero probabilmente in competizione per le stesse risorse nelle CPU, ma per me ha mostrato almeno un piccolo aumento della potenza di elaborazione complessiva.
L'unico vero modo per mostrare se aiuta davvero sarebbe quello di eseguire contemporaneamente diversi test di tipo intero / a virgola mobile / SSE su un sistema con hyperthreading abilitato e disabilitato e vedere quanta potenza di elaborazione è disponibile in un controllo ambiente.
Dipende molto dalla CPU e dal carico di lavoro, come altri hanno già detto.
Le prestazioni misurate sul processore MP Intel® Xeon® con tecnologia Hyper-Threading mostrano un aumento delle prestazioni fino al 30% sui benchmark delle applicazioni server comuni per questa tecnologia
(Questo mi sembra un po 'conservatore.)
E c'è un altro documento più lungo (che non ho ancora letto tutti) con più numeri qui . Un aspetto interessante di quel documento è che l'hyperthreading può rallentare alcune attività.
L'architettura Bulldozer di AMD potrebbe essere interessante . Descrivono ciascun core come efficacemente 1,5 core. È una specie di hyperthreading estremo o multi-core sub-standard a seconda di quanto sei sicuro delle sue probabili prestazioni. I numeri in quel pezzo suggeriscono un accelerazione dei commenti tra 0,5x e 1,5x.
Infine, le prestazioni dipendono anche dal sistema operativo. Si spera che il sistema operativo invii i processi alle CPU reali , preferibilmente agli hyperthread che si stanno semplicemente mascherando come CPU. Altrimenti in un sistema dual-core, potresti avere una CPU inattiva e un core molto occupato con due thread che si bloccano. Mi sembra di ricordare che ciò è accaduto con Windows 2000 sebbene, ovviamente, tutti i sistemi operativi moderni siano adeguatamente in grado.