Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
papafoxtrot

Architettura Ed Efficienza Delle Pipelines - Funzionamento Dell'hyper Threading

Recommended Posts

L'altro giorno nel mio divagare saltando di palo in frasca mi sono ritrovato a descrivere per alcuni utenti, in termini abbastanza semplici, anche perché personalmente davvero non saprei fare di meglio, il funzionamento dell'Hyper threading dei processori Intel. Lo trovo in fin dei conti un argomento affascinante :)

Immagino che a qualcuno possa far piacere trovare una piccola descrizione in termini molto semplicistici, per pura passione personale, e così aggiusto un po' il mio post lunghetto e ne faccio una specie di breve blog.


Edited by papafoxtrot

Share this post


Link to post
Share on other sites

Tutto comincia da qui: si sentono affermazioni scorrette sul numero di core a disposizione, considerando una CPU intel multicore con Hyper threading, quali gli attuali Nehalem.

Qualcuno parla deliberatamente di CPU a 8 core, riferendosi in realtà ai ben noti core i7 quad core... qualcuno parla di 4 core, ma il sistema ne vede 8, qualcuno, più ferrato, parla di core logici e core fisici... Salvo poi affermare che la CPU ha 4 core fisici e 4 logici... Chi ha una visione più corretta della questione parla di 4 core fisici ed 8 logici. Siamo sulla buona strada. Quanti core ha un core i7 920? 4. Quanti core logici ha? Core logici è un po' un nome improprio. Tecnicamente un core i7 quad core ha quattro core, di cui ogni core è in grado di amministrare due threads.

E' comunque scorretto pensare, ad esempio, che una CPU dual core con HT (dual core in grado di elaborare in totale 4 threads) sia analoga ad un vero quad core, ma sprovvisto di HT. Da una parte si hanno 2 core che lavorano ognuno su due threads; dall'altra si hanno 4 core indipendentil, ognuno al lavoro su un processo. La domanda fondamentale è: ma perché un core dovrebbe lavorare a più di un processo? E quanti processi conviene fare amministrare ad un singolo core?

Una cosa più difficile da comprendere è il fatto che in realtà i due threads non vengono elaborati dal core nello stesso momento, ma l'uno in alternativa all'altro.

Ogni core di una CPU dotata di Hyper threading è dunque in grado di eseguire, alternativamente, non simultaneamente, due thread.

Per capire a cosa può servire un simile modo di procedere di un elaborazione: prima un processo, poi una parte di un altro, poi si torna a lavorare sul primo, si deve prima accennare al funzionamento delle pipeline, ed ai principali problemi connessi all'uso delle stesse.


Edited by papafoxtrot

Share this post


Link to post
Share on other sites

Le pipeline come catene di montaggio

Pensiamo per un attimo ad una unità di elaborazione in grado di eseguire un istruzione per ciclo di clock. Nel tempo di un clock viene prelevato un dato in memoria, viene prelevata l'istruzione da eseguire, viene applicata al dato ed il dato elaborato viene riscritto in memoria.

Pensiamo ora a come possiamo raddoppiare la potenza elaborativa di questa semplice unità. Possiamo raddoppiarla, ottenendo due unità, ciascuna delle quali esegue un istruzione completa in un ciclo di clock.

Non otteniamo però un efficiente sfruttamento dell'hardware che abbiamo costruito. Man mano che il dato si muove attraverso l'unità di elaborazione, sempre composta da più parti che eseguono operazioni diverse, le parti non interessate rimangono inoperose.

Pensiamo ad un officina che debba eseguire una lavorazione meccanica su un grezzo: il grezzo deve essere prelevato dal magazzino, portato in officina, mascherato, presentato in macchina e via dicendo. Dopo la lavorazione deve essere reimballato e riportato in magazzino.

Sta di fatto che finché viene eseguita una di queste semplici operazioni, le restanti operazioni sono ferme. Il magazziniere non sta prelevando il nuovo pezzo, la macchina sta lavorando, ma sul piano di lavoro non posso preparare altri pezzi da lavorare... e via seguitando con simili esempi.

E' possibile ottenere una sorta di parallelismo delle operazioni organizzando quella che comunemente viene chiamata catena di montaggio.

Se intanto che il meccanico lavora alla macchina il magazziniere estrae dal magazzino un altro pezzo uguale e lo passa ad un operaio che lo prepoari per la lavorazione, l'addetto alla macchina avrà già il nuovo grezzo bello che pronto su cui lavorare appena terminato il lavoro sul primo.

Il primo componente impiegherà dunque diverse unità di tempo per passare dallo stato di semilavorato, in magazzino, allo stato di prodotto lavorato, di nuovo in magazzino. Dopo uan sola unità di tempo sarà però già stato riprotato in magazzino un secondo pezzo, e dopo due unità di tempo un terzo pezzo.

Un simile modo di procedere è ovviamente comune nell'industria e prende il nome di catena di montaggio. Ed è comune anche in informatica, dove prende il nome di pipeline.

Ogni pipeline è dunque composta di diversi stadi, ad ognuno dei quali viene operata una trasformazione sul dato in transito.

Dividendo il lavoro in 3 stadi (estrazione dal magazzino, lavorazione, reimmissione in magazzino) otteniamo quasi le stesse prestazioni che otterremmo triplicando tutto l'hardware a disposizione: tre magazzinieri, tre carrelli, tre macchine, tre operai... Stiamo però usando solo una macchina, un operaio, un magazziniere, un carrello...

In quattro unità di tempo eseguiamo il lavoro che eseguiremmo in tre unità di tempo triplicando l'hardware.

Ovviamente per funzionare una pipeline necessità di un hardware apposito. Il magazziniere necessità di un carrello e di spazio per venire fuori dal magazzino e depositare il semilavorato. Un operaio deve preparare il semilavorato su una seconda tavola, finché il primo operaio lavora alla macchina sulla prima tavola, e così via.

La pipeline richiede dunque un hardware più sviluppato di un unità elaborativa semplice quale quella ipotizzata all'inizio di questo capitolo.

Abbiamo ottenuto la sorta di parallelismo cercata senza raddoppiare l'intera unità di elaborazione, e stiamo sfruttando potenzialmente tutti gli operatori che partecipano al lavoro. Ognuno ad ogni unità di tempo esegue una volta la sua operazione. In un ciclo di clock ogni dato avanza di un passo nella pipeline.

Ciò che è importante della struttura a pipeline è che è possibile aumentare considerevolmente la velocità di lavoro del processore, perché ogni stadio del lavoro può essere eseguito immediatamente, senza attendere il completamento dell'intera operazione sul dato successivo.

Se l'officina è troppo piccola non è possibile estrarre un semilavorato dal magazzino finché l'operaio sta lavorando all'altro. Non è possibile preparare un semilavorato su una tavola della macchina, perché la macchina ha una tavola sola e l'operaio ci sta lavorando...

Non si puù lavorare alla macchina intanto che il magazziniere passa col carrello per riportare in magazzino il pezzo lavorato...

Insomma si allarga un po' l'officina e si riesce a lavorare in modo molto più efficiente. La pipeline informatica richiede l'inserimento di registri tra uno stadio e l'altro. Spazio per estrarre un nuovo semilavorato, tavola per prepararlo, allinearlo, mascherarlo... Spazio per passare col carrello a riportare il pezzo in magazzino, girando intorno alla macchina e incrociando contemporaneamente l'altro magazziniere che se ne esce dal magazzino con l'altro carrello ed un futuro pezzo da lavorare.


Edited by papafoxtrot

Share this post


Link to post
Share on other sites

Gli stalli della pipeline

Per necessità di sintesi evitiamo l'analisi di quale sarebbe il numero di stadi ottimale per la pipeline. Ogni stadio ha un costo... dobbiamo pagare il magazziniere nuovo, dobbiamo comprare un nuovo carrello, una nuova tavola, ci vuole più spazio in officina...

E ogni stadio ha una sua latenza. Il magazziniere ci mette un po' a scaricare il semilavorato sui piedi delloperaio, poi questo potrà prenderlo e metterlo sulla tavola, allinearlo, girarlo, bloccarlo e via dicendo, ma a quel punto impiegherà un po' per passare la tavola in macchina.

Insomma la pipeline ha una lunghezza ottimale che dipende da queste latenze e da quanto costa l'aggiunta di uno stadio (il magazziniere nuovo...), che in termini informatici è rappresentata dal costo dell'introduzione del nuovo registro. Allo stesso tempo più è alta la latenza in ogni stadio meno conviene aggiungere stadi nuovi.

Il parallelismo tra la pipeline di un processore e la piccola officina però non regge in termini pratici. L'officina che abbiamo ipotizzato lavora su pezzi tutti uguali, disponibili in quantità in magazzino.

Pensiamo al seguente insieme di operazioni da eseguire:

input A, B, D

C = A + B

E = D - 1

Nessun problema. Estraiamo A e B dalla memoria, estraiamo l'operatore (+). Eseguiamo l'operazione e abbiamo C.

Contemporaneamente, di seguito ad A e B abbiamo letto dalla memoria D, il numero 1, e l'operatore (-), e al ciclo successivo terminiamo anche questa operazione.

La pipeline procede a rpieno regime.

Ora anliziamo il caso seguente:

Input: A, B

C = A + B

D = 2 x C

E = D - 1

La pipeline non può operare come nel caso precedente. A e B vengono inseriti in pipeline, ma non possiamo inserire dietro di loro anche C e D, perché non sappiamo quanto vale C.

La pipeline va in stallo. Gli stadi della pipeline che rimangono dietro ad A e B rimarranno vuoti fino a che C non esce da davanti alla Pipeline.

A quel punto sarà possibile leggere C, il 2, ed il - e calcolare D.

C'è nel frattempo un altro stallo. Finché non esce D non si può leggerlo dalla memoria, assieme all'1 e al -... E non si può iniziare il calocolo di E.

Questo tipo di problema è tuttavia aggirabile, entro un certo limite.

Pensiamo ad un frammento di codice più lungo:

Input: A, B, F, G

C = A + B

D = 2 x C

E = D - 1

H = F + G

Non posso leggere C e dunque non posso calcolare D. Però posso fare un altra cosa. Posso intanto leggere F e G, e iniziare a calcolare H. Nel frattempo la pipeline lavora e C esce da davanti. A quel punto letti F e G posso leggere C, il 2 ed il x (Nel ciclo in cui leggevo F e G C è uscito dalla pipeline si è reso disponibile).

Nascono così le architetture out of order.

La sequenza ottimale per eseguire queste oeprazioni è

leggo A, B e l'operatore +

eseguo A+B e nel frattempo la prima parte della pipeline esegue C=A+B

eseguo H=F+G e intanto la prima parte della pipeline legge 2 e C

eseguo D = 2xC.

Eccellente! La pipeline è piena e non stalla! Lavora a pieno regime.

Già, ma ci vuole un dispositivo apposito, uno che studi le operazioni che dovrò eseguire in futuro e le riordini in modo che la catena di montaggio abbia sempre operazioni da eseguire ad ogni stadio.

Quante operazioni devo mettere in mezzo tra la lettura di A e B e la lettura di 2 e C affinché la pipeline non salti un ciclo? Almeno il numero di stadi della pipeline meno uno.

Ecco quindi un problema delle pipeline lunghe. Più è lunga la pipeline, più devo andare a cercare operazioni "indipendenti" da riordinare in modo che siano eseguite una dietro l'altra. Se il codice prevede molte interdipendenze tra le istruzioni da eseguire, potrei non riuscire a trovare abbastanza operazioni indipendenti all'interno di quel processo.

D'altro canto quest'operazione di riordino dipende fortemente da che processore sto usando. Il compilatore non al può eseguire in modo ottimale, perché come abbiamo visto il numero di istruzioni da inserire (e dunque da cercare) dipende da quanto è lunga la pipeline...

Un caso analogo al precedente è questo:

C = A + B

if C>10 then

D = 2 x C

else

D = 3 x C

E = D - 1

A e B vangono lanciati nella pipeline, ma dietro di loro non possiamo introdurre D ed il nuovo operando. Non solo non abbiamo subito C, ma anche quando avremo C, non sapremo se introdurre il 2 o il 3 finché C non sarà confrontato col valore 10.

Le istruzioni condizionali introducono quindi salti nel codice, e provocano dunque un notevole impatto sulle prestazioni della pipeline.

Prima di poter calcolare D dovremo attendere di avere C, poi reintrodurre C nella pipeline assieme al 10, confrontarli, e quando dalla pipeline uscirà il responso potremmo procedere per calcolare D.

Dato che dobbiamo aspettare questo C per due giri dell'intera pipeline, sarà necessario inserire non n-1, ma 2n-2 istruzioni indipendenti dietro ad A e B per fare si che la pipeline non salti un ciclo.

Inizia così ad emergere il più grande difetto della pipeline, le relazioni di interdipendenza tra le varie istruzioni del codice.


Edited by papafoxtrot

Share this post


Link to post
Share on other sites

Come lavora l'Hyper Threading

In pratica abbiamo visto che all'interno di una sequenza di istruzioni può accadere una situazione nella quale l'elaborazione non può procedere finché un certo dato inserito nella pipeline non è stato completamente elaborato, e dunque finché il dato non esce dalla pipeline. Questa condizione è chiamata stallo della pipeline.

Allora cosa possiamo fare per rimediare a questo problema? Posso far svolgere alla pipeline delle istruzioni indipendenti, su degli altri dati.

Carico la pipeline con altri dati ed altre istruzioni e finché non sono riuscito ad approntare dati e istruzioni per il primo thread lavoro sul secondo. Quando anche il secondo per qualche motivo va in stallo riprendo a lavorare sul primo, che intanto potrà procedere.

Insomma l'HT permette di mantenere un maggior impiego della pipeline.

Nuovo parallelo:

Allo stabilimento della FIAT hanno finito le marmitte per le punto, e senza marmitta non possono andare avanti a montare niente. Così finché non gli arrivano le marmitte tutta la catena di montaggio della punto è ferma.

Senza HT l'intero stabilimento della FIAT dovrebbe rimanersene li ad aspettare le marmitte con gli operai cassintegrati.

Con l'HT la catena di montaggio, finché aspetta le marmitte delle punto, si metterà a montare delle Panda.

Quando anche alla panda mancheranno... boh, i semiassi, metteranno da una parte le panda, e riprenderanno con le punto... nel frattempo sono arrivate le marmitte.

Questo esempio non è del tutto corretto, perché le marmitte sono forniture indipendenti. L'esempio sarebbe più calzante se le marmitte fossero montate dalla stessa catena di montaggio, che più avanti delle punto in costruzione, sta costruendo marmitte. Finché non hanno finito di costruire le marmitte la catena resterebbe vuota.

Non mi viene in mente un esempio così adeguato ed allo stesso tempo così semplice, purtroppo.

Però l'esempio ci fa vedere alcune cose:

1) Se voglio abilitare l'HT mi serve spazio... Finché lavoro sulle panda tutte le Punto mezze costruite le devo mettere da qualche parte. Serve quindi il raddoppio dei registri di cui ho parlato. Si parla di un +5% di spazio occupato, dunque di una CPU un 5% più grande.

2) Come visto precedentemente posso cercare di aggirare lo stallo della pipeline. Se in anticipo riesco a capire che devo fare prima le marmitte, e poi le punto, non devo poi fermarmi ad aspettare le marmitte. Per eseguire un codice in maniera ottimizzata devo quindi riordinare le istruzioni in modo da limitare al massimo gli stalli della pipeline. Questo riordino non può essere fatto completamente a livello di compilatore, perché non so, ad esempio, quanti stadi è lunga la pipeline, e dunque con quanti cicli di clock di anticipo devo iniziare ad approntare i dati (alias, quanto tempo prima devo iniziare a costruire le marmitte).

Se riesco a svolgere questo lavoro ottimamente l'HT nonserve più a nulla.

3) Più è lunga la catena di montaggio, più soffrirà in caso di stallo. Se la catena è di 5 stadi, in caso di stallo resterà ferma per soli 4 cicli di clock, se la catena è di 50 stadi, ci vorranno 50 cicli prima che il dato necessario esca dalla catena e si possa ripartire (alias, se la catena è lunga ci vogliono più cicli prima che riesco a terminare le marmitte e intanto tutti gli operai dei 50 stadi prima rimangono a girarsi i pollici).

4) Se la pipeline è più lunga può operare a frequenza maggiore, come per una catena di montaggio, più riesco a dividere il lavoro in fasi elementari, più queste fasi saranno brevi e la caena procede in fretta.

Questo è il grosso motivo per cui il P4 è diventato lo stereotipo del fallimento in ambito CPU. Era stata scelta una pipeline lunghissima, che offriva velocità di clock maggiori, ma d'altra parte soffriva troppo degli stalli.

Terminato il paragone con lo stabilimento della FIAT possiamo dire che:

L'HT richiede il raddoppio dei registri di ogni stadio della pipeline, in modo che se un processo va in stallo posso arrestarlo e lasciarlo in sospeso, e nel frattempo liberare la pipeline perché possa elaborare altre istruzioni, relative ad un altro thread.

Le esecuzioni dei due thread vengono portate avanti simultaneamente, ma alternativamente. Prima l'uno, poi quando il primo va in stallo si passerà all'altro, e quando questo dovrà fermarsi si tornerà al primo.

E' chiaro che l'HT non consente di raggiungere le prestazioni di due pipeline parallele. Ed è altrettanto chiaro, ora, come non sia corretto parlare di core logico e fisico. Il core è uno, il sistema ne vede due perché può allocare due threads per ogni core del processore, e il processore lavorerà per un certo tempo all'uno e per un certo tempo all'altro threads.

Questo modo di procedere potrà apparire disordinato, ma consente di impiegare ottimamente le risorse.

D'altro canto a volte il multi threading è svantaggioso. Se il processo che è in esecuzione non è multi threaded, non è dunque suddivisibile in thread indipendenti e distinti, il sistema non potrà inviare al core due thread dello stesso processo.

E' il caso dei videogiochi. Se un videogioco impiega al massimo quattro core (tipicamente due alla fisica, uno alla grafica, uno all'audio), il sistema non potrà inviare al processore 8 thread relativi al videogioco. E allora accade che invia su di un core un thread relativo al videogioco... ed uno relativo... boh, all'antivirus che è in background.

A quel punto si verifica il fatto negativo. Se il thread del videogioco stalla all'interno della pipeline questa si metterà a lavorare all'altro thread, e finché questo non andrà anch'esso in stallo il core non lavorerà più al primo thread. Il software single threaded dunque subisce un rallentamento delle prestazioni quando eseguito su una CPU multi threaded, perché la pipeline non opera sul thread di interesse non solo per i cicli necessari a risolvere lo stallo, ma anche per tutti i cicli che intercorrono fino al successivo stallo del thread concorrente.

L'esecuzione di processi concorrenti si riperquote in modo interessante sui consumi. Se si ativa l'HT le CPU scaldano di più. Ciò è ovvio se si pensa che con Hyper threading attivato diminuiscono i cicli durante i quali gli stadi della pipeline rimangono inoperosi (in idle). Più migliorano le prestazioni, più la differenza di calore dissipato è grande.

O meglio, più un thread è affetto da stalli e dunque causa inoperatività della pipeline, meno la CPU consumerà.


Edited by papafoxtrot

Share this post


Link to post
Share on other sites

Molto interessante..grazie della spiegazione semplice anche per chi, come me, non ci capisce una cippa...

:hello: :hello:

Bebbu

P.S.

Ho un unico dubbio.....quando devo iniziare a fare le marmitte? :lol:

Share this post


Link to post
Share on other sites

Ottima spiegazione!

semplice ed, a parer mio, esaustiva.

mi sorge una domanda, ora: si può affermare che meno una applicazione vada in stallo durante le operazioni, meno torni utile l'HT? ed il fatto che una applicazione vada più o meno in stallo, dipende da come esegue le istruzioni e quindi da come è programmata? si potrebbe dire, in linea teorica, che una applicazione perfettamente funzionante, non ottiene vantaggi nell'HT?

grazie

Share this post


Link to post
Share on other sites

Sicuramente in un certo qual modo gli stalli delle pipeline dipendono da come è programmato un software.I salti incocondizionati, ad esempio, a qualunque corso di programmazione di base ti ti dicono che sono da evitare.Poi dipende non solo da come viene scritto un programma, ma anche dal tipo di programma stesso. Ci sono codici che per forza di cose comportano un maggior numero di interdipendenze, che quindi possono causare lo stallo della pipeline.Un secondo elemento importante è il compilatore. Se si compilasse il software in abse all'hardware a disposizione, cosa che si fa per alcune applicazioni open source, per le quali è distribuito il codice sorgente, il software sarebbe più ottimizzato, e dunque più veloce su quella CPU. Ad esempio perché, come dicevo in questa spiegazione molto semplificata, un compilatore deve sapere quanto è lunga la pipeline per sapere quante istruzioni indipendenti deve inserire tra due legate da un vincolo di interdipendenza, per evitare lo stallo.Di certo quando una pipeline diviene di una certa lunghezza è quasi impossibile evitare totalmente uno stallo a qualche punto del workflow...Per cui certo, l'HT mostra un influenza diversa a seconda del software usato, sia per motivi fisiologici legati al software (alle istruzioni che esegue), sia per come è stato scritto il software, sia per come è stato compilato.

Share this post


Link to post
Share on other sites

hai saltato la parte di Forwarding delle pipelines... ma sono tutto sommato delle raffinatezze (??si può dire??) e delle ottimizzazioni ulteriori del flusso di lavoro del processore per scavalcare l'utilizzo di alcuni registri ed evitare gli stalli...

Share this post


Link to post
Share on other sites

Grazie Gigi, a dire la verità non è che sia informatissimo sulla materia.. Quello che so a riguardo, grosso modo, l'ho scritto qui.

Una volta bisogna che facciamo una bella chiaccheirata, a riguardo!

Share this post


Link to post
Share on other sites

ahahah, va bene!

Sono sistemi molto curiosi, e da programmare, le pipeline, non sono difficilissime (io non ne sono ancora in grado)... mentre hyper threading e architetture superscalari sono ancora inarrivabili come programmazione, anche per un pubblico esperto...

Leggevo ultimamente un po' di articoli proprio sulle architetture superscalari, e devo dire che mi stupisco sempre di più di come possano funzionare... :eek: :eek: perchè hanno un sistema di previsione (probabilistica) del registro da cui prendere le informazioni prima che queste vengano calcolate e scritte :TeapotBlinkRed: :TeapotBlinkRed: :lol:

Purtroppo questi ultimi sistemi di architettura non fanno parte del mio corso di architettura, mentre le pipeline sì.

Share this post


Link to post
Share on other sites

oddio, non ne ho idea. più che altro dipende dalla specialistica che vado a fare...

Dovrei guardare un attimo il piano di studio delle mie magistrali... se c'è o è a elettronica o è a informatica...

Ecco, ho controllato. alla magistrale di ingegneria informatica si studia calcolo parallelo e architetture superscalari...


Edited by GG25

Share this post


Link to post
Share on other sites

Ah ecco... pareva strano!

Anche perché anche tutte le architetture GPU (VLIW di AMD, superscalari per le nvidia), e le architetture dei processori vettoriali (il CELL di IBM, le pipeline vettoriali dei power 7 e via discorrendo) dove si studiavano, altrimenti...!?

In ogni caso buono studio! Ne avrai da perderti via... :D

Share this post


Link to post
Share on other sites

ottima spiegazione

ma per essere ancora più semplicista..qunto guadagna un "quad" con 8 threat riapetto ad un quad "liscio"(a parita di architettura) ipoteticamente?!

non credo sia logico pensare che raddoppi le prestazioni

ma in termini percentuali?!

crazie


Edited by sins85

Share this post


Link to post
Share on other sites

Beh, non è difficile da scoprire... basta che guardi i test dei core i5 760 (quad core 2,8GHz) contro i core i7 860 quad core (2,8GHz con HT)...

Oppure guardi i confronti eseguiti sui sandy bridge, core i5 2500 e core i7 2600, tenendo conto di quei 100MHz di differenza...

In ogni caso ovviamente non si guadagna il 100%... Il multi threading funziona recuperando i tempi morti in seguito allo stallo della pipeline, non aggiungendo potenza teorica... Questa è la prima cosa che ho cercato di mettere in evidenza.

Il guadagno dipende molto dal programma. In media si guadagna un 15% circa, ma il vantaggio può crescere al 20% ed in alcuni casi anche di più.

In primo luogo bisogna che il software sia multi-thread. Se un software ha un thread solo è impossibile dividerlo tra i due thread amministrabili dalla pipeline, e dunque non guadagnerà nulla. Anzi, dato che il sistema operativo assegnerà all'altro thread un task diverso, di un'altra applicazione, quando la pipeline che sta lavorando sul tuo task stalla, passa all'altro processo e vi rimane per un certo tempo (presumibilmente finché non si ha uno stallo anche li), per cui il tuo processo potrebbe rimanere fermo anche dopo che lo stallo si è risolto, perdendo in prestazioni.

In alcuni casi infatti, è conveniente disabilitare l'yper threading. Lo si fa in alcuni sistemi server.

Poi, ammesso che il software è multi threaded, il guadagno in prestazioni dipende dal tipo di processo che si sta svolgendo e da quant bene è scritto il software. paradossalmente, se il software non presenta alcun salto e gli algoritmi di branch prediction funzionano perfettamente, l'Hyper threading non serve a niente, perché la pipeline non stalla mai. L'hyper threading evita che la pipeline si fermi in caso di miss prediction, che è tanto più probabile quanto più "disordinato" è il codice. In caso di salto incondizionato la miss prediction è assicurata. Infatti, prima lezione di programmazione ti dicono sempre, e te lo ripetono ad ogni lezione successiva: "Mai usare il go to"... Eppure a volte qualcuno non ce la fa e lo usa... I programmi complessi purtroppo possono averne molti...

Insomma peggiore è il software, più l'hyper threading funziona, limitando i danni.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...
Aspetta! x