Future cpu Quad Core di intel, Hyper Threading?

[Redazione di Hardware Upg]

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.

[sbaffo]

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

[ultimate_sayan]

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...

[stgww]

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?

[v10_star]

Originariamente inviato da stgww

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

[Fx]

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
Adesso nasce un nuovo dilemma: prendo ora il conroe o aspetto lo Yorkfield su bearlake?

[stgww]

Originariamente inviato da v10_star

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. . .

Originariamente inviato da sbaffo

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

ti confondi con qualcos'altro
no

[sirus]

Originariamente inviato da Fx

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'è.

[sirus]

Originariamente inviato da kuru

ti confondi con qualcos'altro

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.

Originariamente inviato da sirus

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

[v10_star]

Originariamente inviato da stgww

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

[stgww]

Originariamente inviato da v10_star

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

Pure Io

[leoneazzurro]

Originariamente inviato da kuru

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.

[AndreaG.]

Originariamente inviato da v10_star

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

Beh cmq la citazione è corretta, più o meno

[jappilas]

Originariamente inviato da sbaffo

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

Originariamente inviato da kuru

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

[Dreadnought]

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

[waccos]

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...

[MiKeLezZ]

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.