Link alla notizia: http://www.hwupgrade.it/news/cpu/19284.html

Possibile un approccio che preveda il ritorno della tecnologia Hyper-Threading nei sistemi quad core di futura generazione, previsti per la metà del 2008

Click sul link per visualizzare la notizia.

ma non si era detto che su cpu a pipeline corta l'HT è poco utile?

L'integrazione di una tecnologia in qualche modo figlia di Hyper-Threading fa pensare al possibile sviluppo dello scenario software, che con buona probabilità verrà sviluppato seguendo una logica diversa rispetto a quella attuale. Sia i sistemi operativi che i vari applicativi saranno in grado di ripartire il carico di lavoro sui core meno utilizzati, molto meglio di quanto è possibile osservare ora.

Il problema è proprio questo: ormai è possibile acquistare con una spesa ridotta una cpu dual core ma il suo ambito di utilizzo è ancora troppo ridotto e i vantaggi che ne possono derivare ancora pochi...

Che stufita..... Io volevo proci a 256bit e con almeno 512core, così li abbinavo a 16 Terabyte di ram, altrimenti quando me lo prendo sto pc nuovo?

Che stufita..... Io volevo proci a 256bit e con almeno 512core, così li abbinavo a 16 Terabyte di ram, altrimenti quando me lo prendo sto pc nuovo?

se la pensi così, mai :)

premesso che per l'appunto già oggi non si sfruttano i dual core e sono stati lanciati i quad - quindi l'esigenza di un nuovo HT lascia un po' il tempo che trova (anche se deve essere intesa, se ho capito bene, più come un "threading hardware": se hai 8 thread su un quad core il sistema operativo ogni tot deve interrompere i primi 4 thread per eseguire gli altri 4 e così via; se invece hai una sorta di hyperthreading il sistema operativo assegna gli 8 thread direttamente sugli 8 core logici senza nessun overload per lo switch tra l'uno e l'altro)...

premesso questo, io ero rimasto che c'erano dei problemi non da poco a far capire allo scheduler dei vari sistemi operativi quali fossero core logici e quali fisici... il problema è questo: i vari scheduler (ovvero quella parte che si occupa di distribuire i thread sui core, per dirla in breve) a quanto ho capito non riescono a gestire bene il discorso "logico" e "fisico"... per semplificare estremamente il concetto, se hai 2 thread e 8 core disponibili, se hai 8 core fisici non c'è problema, li assegni ai primi 2 liberi; se 4 di questi sono "virtuali" il problema è un po' più delicato in quanto assegnare i 2 thread a un'unità fisica e una logica significa di fatto impiegare un solo core... insomma, che io sappia l'HT comporta più problemi che altro...

Nehalem e Bloomfield andranno a prendere il posto delle soluzioni quad core Yorkfield, che a loro volta andranno a sostituire le prime soluzioni quad core Kentsfield...
non ti danno neanche il tempo di pensare :rolleyes:
Adesso nasce un nuovo dilemma: prendo ora il conroe o aspetto lo Yorkfield su bearlake?

se la pensi così, mai :)
Mai?

Un generale romano del 100 a.C. circa disse: "siamo arrivati al massimo, il livello tecnologico delle nostre armi non sarà mai superato"

No comment. . .

ma non si era detto che su cpu a pipeline corta l'HT è poco utile?
ti confondi con qualcos'altro
no

premesso che per l'appunto già oggi non si sfruttano i dual core e sono stati lanciati i quad - quindi l'esigenza di un nuovo HT lascia un po' il tempo che trova (anche se deve essere intesa, se ho capito bene, più come un "threading hardware": se hai 8 thread su un quad core il sistema operativo ogni tot deve interrompere i primi 4 thread per eseguire gli altri 4 e così via; se invece hai una sorta di hyperthreading il sistema operativo assegna gli 8 thread direttamente sugli 8 core logici senza nessun overload per lo switch tra l'uno e l'altro)...

premesso questo, io ero rimasto che c'erano dei problemi non da poco a far capire allo scheduler dei vari sistemi operativi quali fossero core logici e quali fisici... il problema è questo: i vari scheduler (ovvero quella parte che si occupa di distribuire i thread sui core, per dirla in breve) a quanto ho capito non riescono a gestire bene il discorso "logico" e "fisico"... per semplificare estremamente il concetto, se hai 2 thread e 8 core disponibili, se hai 8 core fisici non c'è problema, li assegni ai primi 2 liberi; se 4 di questi sono "virtuali" il problema è un po' più delicato in quanto assegnare i 2 thread a un'unità fisica e una logica significa di fatto impiegare un solo core... insomma, che io sappia l'HT comporta più problemi che altro...
Già, era uno dei problemi dei Pentium XE 840/955/965. ;)
Comunque IBM utilizza tecnologie simili al HT di Intel per le sue CPU multi-core (forse lo fa anche Sun) quindi il metodo per evitare questi problemi c'è. :p

ti confondi con qualcos'altro :sofico:
Affatto, HT era stato introdotto per sopperire alla scarsa efficienza architetturale delle CPU NetBurst, nelle CPU con la pipeline più corta l'approccio deve necessariamente essere differente. ;)

Affatto, HT era stato introdotto per sopperire alla scarsa efficienza architetturale delle CPU NetBurst, nelle CPU con la pipeline più corta l'approccio deve necessariamente essere differente. ;)
Gia :)
Ma non è detto che l'HT è utile solo con le pipe lunghe...
fino a prova contraria
SO e software dovranno evolvere insieme all'hardware altrimenti 4 core più HT non serviranno a nulla, se non per fare tanti punti con Sandra e pochi sec. con super P

Mai?

Un generale romano del 100 a.C. circa disse: "siamo arrivati al massimo, il livello tecnologico delle nostre armi non sarà mai superato"

No comment. . .

dopo questa sparata, mi stupisco che tu abbia già un pc :rolleyes:

dopo questa sparata, mi stupisco che tu abbia già un pc :rolleyes:

Pure Io :D :D :D :D

Gia :)
Ma non è detto che siano utili solo con le pipe lunghe.

L'Hyperthreading, versione Intel del SMT (Simultaneous Multi-Threading) serviva sui P4 per incrementare l'utilizzazione delle unità di esecuzione, che in caso di cache miss o branch misprediction potevano rimanere in attesa di dati da elaborare per un gran numero di cicli vista la lunghezza delle pipelines che dovevano essere svuotate interamente, mentre utilizzando HT si potevano processare due thread in parallelo e quindi uno stallo bloccava solo uno dei thread, mentre l'altro poteva continuare ad essere elaborato.
Nel caso di CPU con pipeline corte, il SMT utilizzato in questo modo ha meno senso, poichè gli stalli hanno penalità inferiori e quindi l'investimento in termini di transistors per implementare SMT non è stato giudicato conveniente sulle architetture X86. Questo se il numero di unità di esecuzione si mantiene basso, perchè un altro utilizzo dello SMT è quello di poter eseguire più thread in parallelo per poter tenere occupato il numero più possibile elevato di unità.
Questo approccio per esempio è utilizzato nei Power 5 di IBM. Ciò potrebbe voler indicare, se le indiscrezioni fossero confermate, che in queste nuove CPU saranno presenti molte più unità di esecuzione di quelle attuali.

dopo questa sparata, mi stupisco che tu abbia già un pc :rolleyes:


Beh cmq la citazione è corretta, più o meno :D

ma non si era detto che su cpu a pipeline corta l'HT è poco utile?
Ma non è detto che l'HT è utile solo con le pipe lunghe...
no, infatti :)
non è questione di pipeline lunga o corta, è questione di ILP raggiungibile internamente al processore nelle varie condizioni d' uso ... ed è questione di aumentare lo sfruttamento delle risorse interne al processore a livello di decodifica, scheduling ed esecuzione delle istruzioni, e minimizzarne l' idling

Ora, come noto, il problema per P4 era occupare gli slot di uno Scheduler e delle ALU (2 ALU a doppio ciclo, equivalenti a 4 alu intere a 32 bit, sul northwood per operazioni semplici, sul prescott sempre ) che sulla carta portavano a una capacità di calcolo superiore; in pratica capacità usata per compensare la perdita provocata dalla distanza tra la prima fase fasi scheduling e la fine della execute, nel caso il risultato di un' altra operazione in sospeso vanificasse quella appena calcolata (la pipeline non inficiava con tutti i 21 stadi gli stalli dovuti a branch misprediction, perchè la cache ETC si occupava della sequenziazione delle microops già decodificate e ordinate per flusso operativo - bypassando i jump, cioè - infatti la cache era direttamente connessa a una seconda unità di branch prediction)
Il problema era che tale cache ETC poteva produrre un massimo di 6 microops per ciclo, ma solo se a cache line piena, quindi nella quasi totalità dei casi ne emetteva la metà; inoltre, lo scheduler, a monte della ETC, che produceva le micro ops a partire dalle istruzioni X86, non era superscalare (quindi faceva da collo di bottiglia)
infine, prima dei prescott, le istruzioni X86 complesse erano eseguite da una singola alu dedicata, connessa direttamente al decoder che entrava in modalità "ROM sequence" (emissione di un comando per volta, letto dal microcodice)
Quindi le inefficienze di NetBurst erano svariate, alcune connesse ma non direttamente, al numero di stadi di pipeline ...
invece Core 2 ha sì una pipeline più corta, e praticamente, più "classica" ma quello che davvero conta è il modo in cui è implementato ogni stadio, a partire dal Decoder delle istruzioni X86 superscalare a 4 vie, (già al di là della media di istruzioni per ciclo medie consentite da un eseguibile x86 , che se non ricordo male si aggirava su 2,5) ...

EDIT: leoneazzurro mi ha preceduto ed è stato molto più chiaro di me :)

Humm... vedo con piacere che i discepoli prima o poi imparano :asd:

aspettiamo il successore di Windows Vista (Vienna) e le future versioni GNU/Linux che avranno architettura modulare,sfruttando la virtualizzazione,a quel punto si che i multicore si sfrutteranno a dovere.....anche se credo che dovrebbero fare qlksina prima...

Non necessariamente dovrà avere super-prestazioni.
E' una semplice mossa per contrastare nei benchmark dedicati il 4x4 di AMD, che nel futuro potrà avere un 4 core + 4 core.

Inoltre ricordo che se una cosa ha "poco" senso, non significa che non ne abbia.

Ma i problemi di surriscaldamento dei pentium IV non venivano proprio
dall'HT?

ragazzi non avete capita nulla, intel non si preoccupa se l HT funzionerà meglio o peggio del predecessore, ora pensa solo ad Amd
al 4x4 ed ai futuri K8L = 8 COre fisici.
Alla intel con questo strattaggemma hanno trovato un modo subdolo per stare dietro ad amd e per poter srivere negli spot pubblicitari , pure io ho 8 core, daltronde la storia si rispete, ha fatto più o meno la stessa cosa in epoca k8 Prescot.
Il prescott andava peggio della contra parte AMD e così giu con le frequenze e con 2 core ( mio cugino quandocomprò il suo P4, mi disse, guarda io ho 2 processori, mica come te, che vai in giro con 1)

Inoltre ricordo che se una cosa ha "poco" senso, non significa che non ne abbia.

Ok, ma se c'era una grande notizia dietro all'uscita dei core 2 duo era
che le cpu intel non avrebbero piu' scaldato come forni, riducendo il
TDP medio dagli oltre 100 Watt a 65W , quasi comparabile col TDP
massimo degli AMD (che e' 65W oppure 85W a seconda della cpu).

Se adesso "tornano indietro" nel cercare di riutilizzare quel tempo di
IDLE che invece si e' dimostrato fondamentale per tenere basse temperature
e consumi, non si stanno dando la zappa sui piedi da soli?

Ok, ma se c'era una grande notizia dietro all'uscita dei core 2 duo era
che le cpu intel non avrebbero piu' scaldato come forni, riducendo il
TDP medio dagli oltre 100 Watt a 65W , quasi comparabile col TDP
massimo degli AMD (che e' 65W oppure 85W a seconda della cpu).

Se adesso "tornano indietro" nel cercare di riutilizzare quel tempo di
IDLE che invece si e' dimostrato fondamentale per tenere basse temperature
e consumi, non si stanno dando la zappa sui piedi da soli?
Bisogna solo vedere quanto questa circuiteria dedicata, consumi; ai tempi del P4-C, pur essendo dotati di HyperThreading, questi rimanevano superiori come efficienza agli Athlon, poco distaccandosi dai predecessori non dotati di HT.
Non so comunque quanto questo tangerà la massa di persone, gli 8 core si rivolgeranno allo stesso mercato di nicchia che attualmente c'è per i 4 core, che dubito abbia grande interesse per queste problematiche.
E magari sarà solo una tecnologia di transizione verso gli 8 core reali, derivanti dal futuro utilizzo dei 45nm...
In ogni caso prima di denigrare o elogiare, dovremo aspettare vi sia un reale concorrente, 4x4 o K8L, per attuare dei confronti.
Altrimenti si tratta solo di una possibilità in più di scelta (come attualmente lo è il quad core, non disponibile con altri produttori).

Beh cmq la citazione è corretta, più o meno :D

si ma c'entra come i chupiti a colazione :asd:

Moore gli fa una s*ga :asd:

Affatto, HT era stato introdotto per sopperire alla scarsa efficienza architetturale delle CPU NetBurst, nelle CPU con la pipeline più corta l'approccio deve necessariamente essere differente. ;)
le cose son 2: o tu sei un genio e quelli dell'intel incompetenti o... :D

Bisogna solo vedere quanto questa circuiteria dedicata, consumi; ai tempi del P4-C, pur essendo dotati di HyperThreading, questi rimanevano superiori come efficienza agli Athlon, poco distaccandosi dai predecessori non dotati di HT.
Non so comunque quanto questo tangerà la massa di persone, gli 8 core si rivolgeranno allo stesso mercato di nicchia che attualmente c'è per i 4 core, che dubito abbia grande interesse per queste problematiche.
E magari sarà solo una tecnologia di transizione verso gli 8 core reali, derivanti dal futuro utilizzo dei 45nm...
In ogni caso prima di denigrare o elogiare, dovremo aspettare vi sia un reale concorrente, 4x4 o K8L, per attuare dei confronti.
Altrimenti si tratta solo di una possibilità in più di scelta (come attualmente lo è il quad core, non disponibile con altri produttori).

se non hanno cambiato recentemente, da news precedenti si apprendeva che già yorkfield sarà a 45nm (2007 "anno di shrink") così come i primi della famiglia "nehalem" (2008 "anno di nuova arch.") i quali avranno anche questo "erede" di ht... quindi se tu sai che già con i 45nm potrebbero arrivare gli 8 core fisici ... si rischiano i 16 core logici... :D
inoltre anch'io direi che per questo nuovo ht di aspettare a giudicarlo, non solo come feature di "immagine" vs i futuri k8l 4x4 o necessariamente una soluzione transitoria, magari ci sarà un implementazione con sostanziali differenze e risultati ripsetto al predecessore, magari più simile all'smt dei power ibm, più volta ad un effettivo incremento dell'efficenza nel calcolo e nel parallelismo...
:boh:

"Intel in ogni caso è stata chiara e ad ogni IDF, Intel Developer Forum, non manca mai di sottolineare come in futuro vedremo sistemi con cpu con centinaia di core, gestite dal sistema operativo al fine di massimizzare le prestazioni ed eliminare lag e ritardi di esecuzione."

... magari fra alcuni anni avremo cpu, almeno nell'organizzazione delle unità di calcolo, molto "gpu-like"... tipo con 128-256 "stream processor" o "<qualcosa> units" allocate dinamincamente e "foraggiate" da una complessa logica di controllo/decodifica comune... :sofico:

Ma i problemi di surriscaldamento dei pentium IV non venivano proprio
dall'HT?

Affatto era la tecnologia dei prescott ninete a che vedere con i core 2.

bhe sinceramente io non ho capito perche l'han tolto era una delle poche cose buone dei processori preCore.

MenageZero, tu ci scherzi... Ma credo che sarà proprio così per questa CPU. Hanno specificato che sarà in grado di eseguire 8 thread simultanei. Quindi avrà 8 set di registri e stati interni. Ma magari avrà n decoders (da dividersi tra gli 8 thread), una sola coda unica (con flag per dire a quale thread appartengono le microops), m unità intere, p untità FP/MMX/SSE e q unità di load/store. Cache L1 multi porta unificata e cache L2 multi porta e unificata.

>
Sia i sistemi operativi che i vari applicativi saranno in grado di ripartire il carico di lavoro sui core meno utilizzati, molto meglio di quanto è possibile osservare ora.
<

Beh. Spero proprio di no. Altrimenti se le app sono fatte con il sedere si rischia di tornare ad un sistema cooperativo.
Quello che importa e' l'OS o meglio lo SCHEDULER. Implemente bene questo e sei a cavallo. Alle applicazioni non dovrebbe essere permesso di far altro (come ora) di creare dei threads.
E' lo scheduler che, intelligentemente, deve schedulare i threads (come i tasks) su l'uno o l'altro processore, che non significa deve rimanere sempre lo stesso, ma puo' cambiare, anche in base ai carichi.

"Intel in ogni caso è stata chiara e ad ogni IDF, Intel Developer Forum, non manca mai di sottolineare come in futuro vedremo sistemi con cpu con centinaia di core, gestite dal sistema operativo al fine di massimizzare le prestazioni ed eliminare lag e ritardi di esecuzione."

... magari fra alcuni anni avremo cpu, almeno nell'organizzazione delle unità di calcolo, molto "gpu-like"... tipo con 128-256 "stream processor" o "<qualcosa> units" allocate dinamincamente e "foraggiate" da una complessa logica di controllo/decodifica comune... :sofico:Togli il magari: è proprio questo nei loro piani.
Per questo la vera sfida attualmente si è rivolta nel S/W, nello scrivere programmi capaci di aumentare prestazioni non tanto con l'aumentare della frequenza della CPU, ma del numero di unità elaborative (ecco anche l'azzardo del HT)

Nehalem e Bloomfield andranno a prendere il posto delle soluzioni quad core Yorkfield, che a loro volta andranno a sostituire le prime soluzioni quad core Kentsfield...
non ti danno neanche il tempo di pensare :rolleyes:
Adesso nasce un nuovo dilemma: prendo ora il conroe o aspetto lo Yorkfield su bearlake?


Esattamente il problema che mi pongo anche io...
Io dovrei aspettare il quad-core Yorkfield su chipset bearlake, ma fin da ora gia conosco i successori...
Cosi va a finire che una persona perda parecchio tempo prima di decidersi a cambiare CPU!! :muro:

ooooodddiooooooooooooooooooo 8 pinguini sul framebufferrrrrrr!!!!!!!

Scusate, qualcuno sa se, tra i modelli Core 2 Duo che usciranno nel 2007, ce ne saranno alcuni, oltre a quelli Extreme Edition, con l'hyperthreading abilitato in modo che il sistema operativo veda 4 core logici nonostante ci siano solo 2 core fisici?
Io penso che se l'HT funziona, avere un processore di questo tipo dovrebbe essere un buon surrogato dei processori a 4 core fisici, soprattutto per chi come me ha sempre tantissimi programmi aperti contemporaneamente e non gli interessano le prestazioni massime nei giochi...

ooooodddiooooooooooooooooooo 8 pinguini sul framebufferrrrrrr!!!!!!!

Sbagliato thread? Ti riferivi forse a quello su Linux e la PS3? :D

Scusate, qualcuno sa se, tra i modelli Core 2 Duo che usciranno nel 2007, ce ne saranno alcuni, oltre a quelli Extreme Edition, con l'hyperthreading abilitato in modo che il sistema operativo veda 4 core logici nonostante ci siano solo 2 core fisici?
Io penso che se l'HT funziona, avere un processore di questo tipo dovrebbe essere un buon surrogato dei processori a 4 core fisici, soprattutto per chi come me ha sempre tantissimi programmi aperti contemporaneamente e non gli interessano le prestazioni massime nei giochi...

Sembra ch ci sarà qualcosa ma non prima del prossimo anno.

Sbagliato thread? Ti riferivi forse a quello su Linux e la PS3? :D

non ho sbagliato thread! "godevo" pensando al fatto di avere 8 pinguini al bootup di un sistema con 4+4 processori... :p

la console di linux, per ragioni storiche e folcroristiche, nella fase di inizializzazione del sistema ha la possibilita' di visualizzare l'iconcina di un tux per ogni processore che il kernel ha riconosciuto, 8 tux sono davvero una gallata! :ciapet:

per esempio questo
http://www.gambit-automation.com/user_data/wago/framebuffer.jpg
ha un solo, misero, processore...

non ho sbagliato thread! "godevo" pensando al fatto di avere 8 pinguini al bootup di un sistema con 4+4 processori... :p

la console di linux, per ragioni storiche e folcroristiche, nella fase di inizializzazione del sistema ha la possibilita' di visualizzare l'iconcina di un tux per ogni processore che il kernel ha riconosciuto, 8 tux sono davvero una gallata! :ciapet:

per esempio questo
http://www.gambit-automation.com/user_data/wago/framebuffer.jpg
ha un solo, misero, processore...

Fico! :D Come si attiva?

Fico! :D Come si attiva?

se utilizzi un'immagine del kernel standard (a.k.a. non l'hai ricompilato) ti dovrebbe bastare aggiungere il parametro vga=XXX a boot...

dove XXX puo' assumere diversi valori a seconda della risoluzione desiderata. i piu' comuni:
788 = 800x600 16 bit
791 = 1024x768 16 bit
793 = 1280x1024 16 bit

se utilizzi un'immagine del kernel standard (a.k.a. non l'hai ricompilato) ti dovrebbe bastare aggiungere il parametro vga=XXX a boot...

dove XXX puo' assumere diversi valori a seconda della risoluzione desiderata. i piu' comuni:
788 = 800x600 16 bit
791 = 1024x768 16 bit
793 = 1280x1024 16 bit

Thanks... Ora che mi ricordo... La mandrake 7 partiva in modalità grafica in automatico e su un portatile monoprocessore usciva un pinguino... Non avrei mai immaginato che su macchine multiCPU uscisse un pinguino per CPU... :D

non ho sbagliato thread! "godevo" pensando al fatto di avere 8 pinguini al bootup di un sistema con 4+4 processori... :p

la console di linux, per ragioni storiche e folcroristiche, nella fase di inizializzazione del sistema ha la possibilita' di visualizzare l'iconcina di un tux per ogni processore che il kernel ha riconosciuto, 8 tux sono davvero una gallata! :ciapet:

per esempio questo
http://www.gambit-automation.com/user_data/wago/framebuffer.jpg
ha un solo, misero, processore...
aaaaaaaaaaaaaaa
ecco perchè a me con il celeron mi si vede solo mezzo pinguino :O

aaaaaaaaaaaaaaa
ecco perchè a me con il celeron mi si vede solo mezzo pinguino :Omezzo? :asd:

mmm.... e se io riesumo il p3-450 che ho in soffitta, ci metto linux e lo avvio con qule flag... che fa, mi visualizza solo il becco ? :D