Intel Hyper-Threading e Microsoft Windows 7

No è sbagliato.

Windows in presenza di core nativi lavorerà come ha sempre lavorato, mentre in presenza di hyperthreading abbinerà solamente certi applicativi (o flussi di codice) sui due core logici. Non tutti i codici vengono eseguiti decentemente su un architettura SMT.

Bello! Chi è? John Fante?

Ancora con sto menu classico?? Ragazzi, ma perché fossilizzarci il cervello con un'interfaccia grafica risalente ai tempi del Windows 95... Dai, un po' di elasticità mentale, altrimenti va a finire che ci rincitrulliamo prima del tempo!

Ma poi come fai a dire che il menu classico era più veloce da usare? Ma hai mai provato a digitare 3 letterine dell'applicazione che vuoi lanciare, nel menu start di Vista/7 ? Senza contare che le applicazioni più usate di recente vengono automaticamente inserite nella parte sinistra del menu d'avvio...

Certo che se ti ostini ad usare il menu start di Vista andando ogni volta in "Tutti i programmi" per cercare il programma da lanciare, stile menu classico, allora stai fresco...

Infine, se ti fa più comodo, le applicazioni più usate le puoi anche fissare sulla nuova barra di Win7...

Cos'è che non funziona? Se hai trovato un bug, vieni a segnalarlo nell'apposito thread linkato anche nella mia firma.

Il nome è diverso, diversa è l'implementazione, ma il fine è lo stesso.

Il simultaneous multithreading è l'usare più istruzioni contemporaneo nello stesso core.

Il symmetric multiprocessing è l'usare diversi core per più istruzioni contemporanee.

Il succo è che per entrambi sono necessarie diverse istruzioni contemporanee, quindi un software granulare e la cui granularità di istruzioni non sia poi di intralcio (un es. lo esplico un po' sotto).

"Artificio" non significa "trucco", può essere "idea, invenzione, trovata, accorgimento, escamotage, stratagemma", ma soprattutto "espediente" (il termine che intendevo).
L'HT è un espediente che, a fronte di un deficit prestazionale con applicazioni single-threaded (e qualche altro problemino), apporta un benefit relativamente grande con quelle multi-threaded.
Di fatto, sia nel caso di Netburst che Nehalem, è utilizzato per sfruttare al meglio le CPU, ma mentre nel primo caso c'era una vera e propria necessità (data dalla lunga pipeline, al contrario dei più scattanti Athlon, e poi c'era l'aggiunto beneficio le CPU dell'epoca fossero single-core, e quindi guadagnavano parecchio anche nei task di ufficio), nella sua seconda rivisitazione su Nehalem è più come un facile sovrappiù da implementare (qualche transistor in più, il tutto però poi sperando nel lavoro dei developers (ovvio che se non escono applicazioni in grado di sfruttare gli 8 core, i 16 core grazie al SMT ce li possiamo fare al padellino).
HT è comunque anche criticato, non è che sia la panacea di tutti i mali (anzi). Aveva molto più senso una volta (P4), quando invece era molto criticato. Buona infatti l'idea di riutilizzarlo in Atom.

Non sono al corrente di ciò, mi auguro comunque tu non voglia confrontare SIMD con VLIW con MIPS o che altro... L'Hyper Threading è molto più vicino a una semplice soluzione MIMD.

In realtà si tratta proprio di sistemare un bug dello scheduler: se abbiamo 4 core fisici e 4 core logici, uno scheduler decente che abbia da allocare 4 thread dovrebbe caricare solo i 4 core fisici (o tutt'alpiù usare una qualche logica di controllo che lasci uno fisico libero per eventuali altri...)... uno scheduler invece buggatino caricherebbe semplicemente i primi 4 core che trova... ovvero 2 fisici e relativi 2 logici, lasciando quindi gli altri 2 core fisici a idlare.
Ovvio in una soluzione del genere lasciare l'hyperthreading attivo è addirittura dannoso.


Abbiamo Bill Gates con noi... peccato "eGuru", come sempre succede, si dimentichi di andare un po' nel tecnico... giustificare... tanto fumo...

Nooo vi prego basta con l'HT, non ne posso più di perdere una marea di tempo in ricerche alla Sherlock Holmes ogni volta che devo fare delle verifiche per il licensing di qualche macchina...

a: "Ok abbiamo 4 cpu"
b: "Si ma quanti socket?"
c: "1? 2? 4? E quanti utilizzati?"
a: "Ma sono cpu dual core o quad core?"
b: "Aspetta... potrebbero essere Xeon single core..."
c: "Ok fermi tutti... un bel respiro... qualcuno cerchi la fattura di acquisto o l'ordine"
a: "No perchè il prodotto X conta le licenze per socket... ma il prodotto Y le conta per core... il prodotto Z per utenti, ma a patto che i socket siano meno di N"
b: "Fermi ragazzi ci stiamo ingarbugliando..."
c: "E se fossero due schifosissimi P4 Xeon con HyperThreading?!?!?"
a: "Tra l'altro se ci fosse l'HyperThreading non è detto che sia attivo... ricordate dal cliente XYZ dove tutti i server avevano hyperthreading disattivato da bios?"
a, b, c si guardano con occhi pallati: "NOOOOOOO!!!!!!"
a: "Ok qualcuno scarichi la versione giusta dell'IBM DSA..."
b: "Lascia perdere... non sono macchine IBM"
c: "Oh santa polenta... Ok allora scendiamo in sala, apriamo lo chassis e guardiamo quante cazzo di cpu ha quella maledetta macchina e quanti socket"
a: "Non si può è un blade e va spento tutto prima di toglierla"

a, b, c..... SBONK!

Ecco la scena tipo in una azienda a caso quando si tratta di fare l'inventario dell'hw per il conteggio delle licenze...
Vi prego, torniamo alle buone vecchie cpu single core... vada per i multicore, quelli son facili da individuare... ma l'HyperThreading no!!!! E' una piaga biblica!

xp non aveva la stessa potenzialità?

Infatti. L'Hyper-Threading è supportato sin dai tempi di XP:

Windows XP e la tecnologia Hyper-Threading
http://support.microsoft.com/kb/810231
"in Windows XP Home è possibile utilizzare al massimo un (1) processore fisico. Poiché, tuttavia, è supportata la funzionalità Hyper-Threading, il sistema operativo è in grado di sfruttare il secondo processore virtuale."

ok in questo caso ovvio che è diversa la cosa qui bisogna gestirli almeno 4 fisici e 4 virtuali

Non è affatto detto che le modifiche allo scheduler per migliorare il supporto al SMT vadano a migliorare le prestazioni in ambito SMP.


A questa stregua possiamo considerare ILP e TLP sullo stesso piano, l’obiettivo è sempre lo stesso.
L’obiettivo è il medesimo, il nome è diverso, l’idea alla base è diversa, l’implementazione è diversa ed anche la gestione è differente.

Il succo è che per entrambi sono necessarie diverse istruzioni contemporanee, quindi un software granulare e la cui granularità di istruzioni non sia poi di intralcio (un es. lo esplico un po' sotto).


Ti sbagli, SMT (TLP), di cui HT è un’implementazione, è un’idea degli anni 70 e non è nata per sopperire ai problemi riscontrati con le applicazioni single-threaded ma è nata come sviluppo parallelo dell’ILP.
Se HT è un espediente allora consideriamo espedienti anche tutte le tecniche di ILP e magari anche il pipelining delle istruzioni.


Questo non è del tutto corretto, il processore dispone della circuiteria necessaria per tentare di sfruttare HT anche quando non si fa uso esplicito del parallelismo (ci sono implementazioni di SMT in processori differenti dai Pentium 4, Pentium XE, Core i7 ed Atom che fanno decisamente meglio da questo punto di vista).


Se parliamo di SMT, esistono implementazioni dell’architettura MIPS che dispongono di SMT a 4 vie, IBM coni suoi POWER5 e POWER6 supporta SMT a 2 vie e se proprio vogliamo parlarne anche gli Intel Itanium fanno uso di una specie di SMT pur essendo fondamentalmente dei VLIW.
SMT è un’idea buona a priori dal mio punto di vista, non potrà sempre portare benefici (tranne nei casi in cui la cache fa da collo di bottiglia) ma nella maggior parte dei casi è un passo avanti.


Chiamalo bug, io dico che semplicemente Windows non disponeva ancora di un supporto decente al SMT.