[Thread Ufficiale] Aspettando Bulldozer *leggere prima pagina con attenzione*

[paolo.oliva2]

Originariamente inviato da GT82

Dispiace che non sia stato colto lo spirito del mio post

sia chiaro che se c'è uno che vorrebbe vedere AMD dominare sui processori blu quello sono io

di 7 pc che ho in casa o da parenti assemblati da me o di cui ho assistito l'acquisto ebbene tutti montano AMD
mi sembra che mi sia stato risposto un po' ingenerosamente

Vedi... non è il discorso se uno è Intellista o meno, è solo che siamo di fronte sempre alla stessa minestra... cioé che se una cosa la fa Intel, è sopravvalutata, se la fa AMD, è sottovalutata.
Scusa, guarda l'aspettativa per gli i7 all'uscita. 50% in più di IPC, 100%, bla bla bla. e sul campo è inferiore a quelle previsioni. Parliamo del Thuban, il 20% in più di IPC al max, che sarebbe arrivato a malapena ad un i920.., TDP 140W per stare a 2,8GHz e poi ci ritroviamo a 95W, che l'OC sarebbe stato impossibile sopra ad un X4 C3, e poi invece?
Ti assicuro che se Buldozer fosse marcato Intel, qua la gente parlerebbe di 50% in più di IPC e clock sui 5GHz almeno e nessuno avrebbe alcun dubbio.

certo che non penso che alla AMD siano degli stupidi avendo assistito probabilmente anche un po' divertiti a dove era andata a infilarsi Intel con la Netburst
permetterete però che qualche ansia data dalle indiscrezioni sulla lunghezza delle pipeline di BD sia lecita dato che da 4 anni siamo sotto a Santa Clara come IPC
spiegato completamente dalla faccenda dei compilatori? siamo sicuri?
di solito aumentare gli stadi riduce l'IPC in caso di salti
di solito cercare prestazioni con la frequenza costa parecchio in termini di consumo
felicissimo, anzi direi, estasiato di essere smentito se BD dimostrerà al mondo il contrario
riguardo l'SMT comunque, allo stesso modo nemmeno quelli di Intel penso siano dei deficienti, quindi se l'hanno messo è evidente ed ormai assodato che il rapporto prestazioni/prezzo in termini di consumo addizionale è favorevole
qualunque applicazione che sfrutti il multithreading vede un boost prestazionale con punte di +50% come dimostrato
svantaggi?

Prova a pensare il perché la gente spendeva 1000€ per un i965 EE ed invece per l'i980X sono ben pochi quelli che lo acquistano. Il perché? Semplice, perché l'SMT nel desktop sono più i prb che i vantaggi, cosa che assolutamente non hai con dei core fisici, perché al più, vanno in "parcheggio".

probabilmente compensati dal fatto che Nehalem di suo, senza SMT, ha un IPC molto alto
quanto consuma un modulo BD con due core fisici? perchè il vantaggio dell'SMT è proprio lì, impattare molto poco sul consumo.....

Io sarei pronto a scommettere che i proci AMD avranno come cavallo di battaglia proprio il consumo a parità di prestazioni.
Sarò vecchia maniera e "duro", ma io ho sempre dato per scontato che il consumo genera X calore, e non riesco a capacitarmi di come sia possibile che con temp doppie Intel abbia consumi minori.
Comunque, guarda che Intel non alza il clock per problemi di TDP ed il 32nm HKMG avendo un leackage alto non riesce comunque a sfruttarne appieno le potenzialità. Se avesse ottenuto un TDP di 95W a 3,333GHz con l'i980X non credo che si sarebbe fermata lì con il clock (visto che è arrivata a commercializzare proci ad un determinato clock stock che poi si abbassa se si supera il TDP).
Quindi non capisco il perché se AMD riuscirà a commercializzare proci con TDP inferiore (125W sarà il max) e clock superiori, per forza di cose dovrebbero consumare di più di quelli Intel a parità di prestazioni...

[Pihippo]

Originariamente inviato da Ren

Ciao,
Un miglioramento ci sarà sicuramente(algoritmi, tabelle...), ma non penso abbiano allargato il numero di istruzioni fetchabili per clock/thread. (in riferimento alle prestazioni single thread migliorate, quando metà del cluster è inutilizzato)


ps.Il loop detector scatta solo per alcuni tipi di istruzione prevedibili/ricorrenti per spegnere i decoder quando non servono.

Ciao
Guarda, il k10 preleva gia da ora 32byte dalla L1 I, e se consideri che i i7 e compagnia bella ne fetchano solo 16 non mi pare ci sia sto bottleneck. Forse intendi dire che a causa di branch e robette varie, questi 32byte li puòi fetchare ogni 3 cicli di clock. Qui magari un attimino di siviluppo ci dovrebbe essere stato (almeno coso ho capito sul blog di dresdenboy sull'accelerate mode) .
Per il loop detector. beh è una sorta di trace cache alla fine dei conti.

Loop Stream Detector detected small loops in the program code and saved them in a special buffer. As a result, the CPU didn’t have to fetch them from the cache over and over again and predict branching within these loops. Nehalem processors have an even more efficient Loop Stream Detector block, which has been moved past the instructions decoding stage. In other words, Loop Stream Detector now saves decoded loops, which makes it a little similar to Trace Cache of Pentium 4 processors. However, Loop Stream Detector of Nehalem CPUs is a specific cache. First, it is very small, only 28 micro-ops. And second, it saves only loops. Fonte http://www.xbitlabs.com/articles/cpu...e_3.html#sect0

[capitan_crasy]

Originariamente inviato da GT82

Dispiace che non sia stato colto lo spirito del mio post

sia chiaro che se c'è uno che vorrebbe vedere AMD dominare sui processori blu quello sono io

di 7 pc che ho in casa o da parenti assemblati da me o di cui ho assistito l'acquisto ebbene tutti montano AMD
mi sembra che mi sia stato risposto un po' ingenerosamente

Non fraintendermi, non ti ho risposto in quel modo (se ti sono sembrato troppo brusco ti chiedo scusa ) pensando che tu fossi un fanboy, ma per il motivo Netburst...

certo che non penso che alla AMD siano degli stupidi avendo assistito probabilmente anche un po' divertiti a dove era andata a infilarsi Intel con la Netburst

permetterete però che qualche ansia data dalle indiscrezioni sulla lunghezza delle pipeline di BD sia lecita dato che da 4 anni siamo sotto a Santa Clara come IPC
spiegato completamente dalla faccenda dei compilatori? siamo sicuri?

di solito aumentare gli stadi riduce l'IPC in caso di salti
di solito cercare prestazioni con la frequenza costa parecchio in termini di consumo

felicissimo, anzi direi, estasiato di essere smentito se BD dimostrerà al mondo il contrario

Si però si cita il discorso a metà tralasciando tutto il resto.
Il P4 a 130nm era una signora CPU, il problema è stato il processo produttivo a 90nm a rendere un fallimento il progetto Netbust.
AMD non ha puntato sulle frequenze perchè all'epoca non riusciva a stare dietro ad Intel, così si è messa all'opera sull'efficienza.
Oggi la situazione è ben diversa, se AMD sta puntando sulle frequenze è perchè dovrebbe (il condizionale è d'obbligo) riuscire ad ottenere un clustered-core con frequenze alte mantenendo bassi i consumi massimi.
Questo non significa ottenere un netbust ma una CPU totalmente diversa dal suo predecessore.
Fermo restando che AMD stessa abbia veramente intenzione di alzare gli stadi per ottenere frequenze molto alte, la verità è che senza conferme ufficiali l'aumento degli stadi potrebbe essere in percentuale molto ridotta...

riguardo l'SMT comunque, allo stesso modo nemmeno quelli di Intel penso siano dei deficienti, quindi se l'hanno messo è evidente ed ormai assodato che il rapporto prestazioni/prezzo in termini di consumo addizionale è favorevole

Ma allora perchè l'ATOM fa così schifo con o senza SMT?
Troppo facile glorificare HTT con un architettura come quella del Nehalem...

qualunque applicazione che sfrutti il multithreading vede un boost prestazionale con punte di +50% come dimostrato

STM non da un vantaggio del 50% su tutti i programmi, anzi su molti come quelli dei giochi è solo un fastidio...

svantaggi? probabilmente compensati dal fatto che Nehalem di suo, senza SMT, ha un IPC molto alto

Uno degli svantaggi del SMT è che in campo server alcuni programmi non digeriscono tale tecnologia a tal punto che lo devi disattivare.
Inoltre se hai (esempio) 2 nehalem X6 in campo server non importa se 12 di quei thread siano solo logici e non fisici, le licenze si pagano per numero di core e dato che ufficialmente sono 24 thread li paghi tutti; e tanti saluti al rapporto prezzo/prestazioni e numero di transistor utilizzati...
Purtroppo il buon ratatost non cè più nel forum () ma se guardi indietro in questo thread abbiamo già analizzato questi difetti...

quanto consuma un modulo BD con due core fisici? perchè il vantaggio dell'SMT è proprio lì, impattare molto poco sul consumo.....

E che ne so...
E' ancora troppo presto ma mi sembra che non hai molta fiducia sui 32nm SOI; ti consiglio di leggere gli ultimi post del magnifico bjt2...

[-El-]

Originariamente inviato da GT82

...cut...

Scusami se ti ho tagliato il post, ma era troppo lungo da citare, considerando la non scarsa lunghezza del mio.

Amd, quando ha scelto la via dei moduli, ha optato per una via parallela a quella di intel, piu costosa dal punto di vista dell'area ma anche piu efficiente. Una via non nega l'atra, ma implementarle contemporaneamente è probabilmente troppo esoso per le attuali nanometrie.
Potremmo paragonare la scelta di Amd nel campo cpu a quella già fatta nel campo grafico: tanti e piccoli cores che lavorano come un esercito di cinesi. La mentalità Intel è invece simele a quella Nvidia: cores piu grandi e potenti, e SMT è uno dei modi per "pomparli". Questa differenze di prospettive fa sì che nello stesso spazio di un core sb ci stia un modulo Bulldozer, cioè due core.

Riguardo alle frequenze, vorrei ricordare che negli ultimi anni non si ha avuto una crescita di clock neanche paragonabile a quella precedente al periodo NetBurst: è da troppo che siamo fermi alla soglia dei 4 GHz senza riuscire a superarli. Credo che i tempi siano ormai maturi per una nuova crescita in tale ambito.

Riguardo l'Ipc per core, a parità di clock sarà sicuramente superiore, ma non mi aspetto una rivoluzione in tale ambito: senza dubbio grandi vantaggi verranno dall'uso di una cache a 8T, molto più veloce e vero punto di forza di Intel sino ad ora; e il punto di debolezza saranno dati dal raro caso in cui l'uso di istruzioni Avx mandi installo l'altro core del modulo che necessita l'uso della Fpu.

[Ren]

Ciao
Guarda, il k10 preleva gia da ora 32byte dalla L1 I, e se consideri che i i7 e compagnia bella ne fetchano solo 16 non mi pare ci sia sto bottleneck. Forse intendi dire che a causa di branch e robette varie, questi 32byte li puòi fetchare ogni 3 cicli di clock. Qui magari un attimino di siviluppo ci dovrebbe essere stato (almeno coso ho capito sul blog di dresdenboy sull'accelerate mode) .
Per il loop detector. beh è una sorta di trace cache alla fine dei conti.

Volevo dire che il branch condiviso non crea grandi aumenti prestazionali quando un core è inutilizzato, perchè credo abbiano mantenuto la stessa ampiezza, ma implementando il doppio thread. (semplificando il concetto)

I soli stadi che mi vengono in mente che potrebbero aumentare le performance mono-thread del cluster sono i decoder ed il dispatch(se tutte le sue porte sono connesse ad ogni core).

[Ren]

Uno degli svantaggi del SMT è che in campo server alcuni programmi non digeriscono tale tecnologia a tal punto che lo devi disattivare.
Inoltre se hai (esempio) 2 nehalem X6 in campo server non importa se 12 di quei thread siano solo logici e non fisici, le licenze si pagano per numero di core e dato che ufficialmente sono 24 thread li paghi tutti; e tanti saluti al rapporto prezzo/prestazioni e numero di transistor utilizzati...
Purtroppo il buon ratatost non cè più nel forum () ma se guardi indietro in questo thread abbiamo già analizzato questi difetti...

SMT è un fastidio quando il programma non scala bene i core, quindi non è un problema imputabile al hardware, ma solo al software che pecca nel multi-core. (un controsenso in una macchina server)

Ma allora perchè l'ATOM fa così schifo con o senza SMT?
Troppo facile glorificare HTT con un architettura come quella del Nehalem...

Ho già risposto prima, ma ripetere non mi disturba.

Atom nasce sulla base del pentium 1, quindi esegue le istruzioni direttamente, senza un meccanismo che massimizza il parallelismo del codice, inoltre possiede meno alu degli altri competitor.

SMT un aumento lo porta anche nel atom ed eccoti alcuni esempi che già conosci :




bye

[capitan_crasy]

Originariamente inviato da Ren

SMT è un fastidio quando il programma non scala bene i core, quindi non è un problema imputabile al hardware, ma solo al software che pecca nel multi-core. (un controsenso in una macchina server)

Eppure esistono casi dove consigliano espressamente di disattivare SMT; ecco alcuni esempi:
Clicca qui e clicca qui...

Ho già risposto prima, ma ripetere non mi disturba.

Atom nasce sulla base del pentium 1, quindi esegue le istruzioni direttamente, senza un meccanismo che massimizza il parallelismo del codice, inoltre possiede meno alu degli altri competitor.

SMT un aumento lo porta anche nel atom ed eccoti alcuni esempi che già conosci :

Ma infatti non metto in dubbio la validità del SMT su una architettura come il Nehalem, le cose cambiano quando essa non è affatto performante, vedi appunto Atom e il P4...
SMT non è la soluzione definitiva e infatti AMD ha preferito seguire strade diverse...

[Ren]

Ma infatti non metto in dubbio la validità del SMT su una architettura come il Nehalem, le cose cambiano quando essa non è affatto performante, vedi appunto Atom e il P4...
SMT non è la soluzione definitiva e infatti AMD ha preferito seguire strade diverse...

Il punto è che rimane una valida opzione(usatissima) per aumentare le performance su qualunque architettura moderna esistente. Le GPU sono l'esempio lampante della sua efficacia per mascherare latenze su porzioni di codice altamente parallelo.

AMD ha percorso una strada rischiosa totalmente nuova, considerando che Sun prima di lei ha abbandonato un progetto simile(rock).
Vedremo solo tra diversi mesi se ne nascerà una bestia perfromance/mm2...

[bjt2]

Per quanto riguarda le pipeline supposte di bulldozer.
Il clock dipende da quanto uno stadio della pipeline è piccolo (a parità di processo produttivo). Più è piccolo, più stadi ci vogliono. Per misurare quanto uno stadio di una pipeline è lento (ma più è lento, più "potente" è, più cose può fare e meno stadi ci vogliono) c'è una unità di misura: il ritardo in termini di FO (mi pare sia Fan-Out, ma io conosco un altro significato per questo termine). Uno stadio di pipeline con FO n, vuol dire che è composto da n porte logiche in cascata, ossia che un segnale in ingresso allo stadio deve percorrere al più n porte logiche prima di giungere all'uscita. Il tempo di propagazione di una porta logica si misura in picosecondi. Così uno stadio con FO n avrà un ritardo di propagazione di poche centinaia di picosecondi.
Più è alto il FO, più è complicata l'operazione che può fare uno stadio, potenzialmente ci vogliono meno stadi, ma il clock è dato dallo stadio più lento, per cui il clock è più basso.

Le CPU della serie K7-8-10 fino ad adesso sono state accreditate di stadi con FO 24 (circa: non si conosce il valore esatto, ma lo si stima dal clock riferito al processo produttivo), che è un valore molto alto: clock non molto alto, ma ogni stadio ha sufficente potenza elaborativa da permettere pochi stadi (12 la pipeline intera del K10, mi pare).

Le CPU della serie Core 2/Nehalem sono accreditate di qualche FO in meno (21-22), per cui possono avere un clock più elevato a parità di processo produttivo (infatti il clock è limitato principalmente dal TDP, ossia dal leakage: se correttamente raffreddate le CPU INTEL sfiorano i 5GHz) anche se comunque i transistors INTEL sono un po' più veloci di quelli AMD, quindi avrebbero avuto un clock massimo superiore anche con lo stesso FO (ma maggiore leakage perchè manca il SOI)...
FO minore richiede qualche stadio in più e infatti mi pare sia così (se non lo è, un plauso va agli ingegneri INTEL oppure le unità RISC sono più semplici)

Poi viene l'architettura POWER, accreditata di 16-18 FO. E infatti arriva a 4.14 GHz stock con il processo a 45nm SOI...

Poi viente il Pentium 4. E' accreditato di un FO di 16 per le parti non dual pumped e di un FO 8 per l'ALU dual pumped.

Come si vede è possibile fare una architettura efficiente anche con un FO vicino al P4 (vedi la CPU Power) e comunque Buldozer potrebbe avere un FO leggermente inferiore al K10 (ma probabilmente si dovrebbero fare tutte le librerie daccapo), senza per questo rischiare di essere il nuovo Pentium 4.


Questo per dire che c'è margine per fare pipeline più lunghe senza per questo fare un nuovo P4...

[calabar]

Sono un po' OT, ma che io ricordi, SMT risulta molto incisivo nell'Atom proprio perchè questo è un processore in order, e quindi la possibilità di avere subito a disposizione un altro thread permette un ottimo guadagno prestazionale.
Ho idea che proprio con Atom SMT dia un contributo proporzionalmente maggiore rispetto ad architetture più efficienti.

Tornando a BD, bisogna vedere anche se le due filosofie sono compatibili, o per lo meno se lo sono e danno risultati utili.

A questo punto tiro fuori una domanda da niubbone primo della classe, perchè c'è un punto che non mi è molto chiaro e vorrei capire meglio.

Si parla del core int del K10 che ha 3 pipeline, mentre quella intel (core due e immagino anche nehalem) e quella di bulldozer dovrebbero averne 4, tanto che si ottiene un ipc maggiore.
Dal momento quindi che anche un singolo core è composto da sottounità, non sarebbe possibile anche per i core int all'interno di un modulo bulldozer unire le pipeline di ognuno per ottenere un super-core con 8 pipeline int e con ipc più elevato, così da colmare il gap a livello di singolo core?
Insomma... forse quello che la gente si aspettava da un "reverse hypertreading" hardware.

[Ren]

Si parla del core int del K10 che ha 3 pipeline, mentre quella intel (core due e immagino anche nehalem) e quella di bulldozer dovrebbero averne 4, tanto che si ottiene un ipc maggiore.
Dal momento quindi che anche un singolo core è composto da sottounità, non sarebbe possibile anche per i core int all'interno di un modulo bulldozer unire le pipeline di ognuno per ottenere un super-core con 8 pipeline int e con ipc più elevato, così da colmare il gap a livello di singolo core?
Insomma... forse quello che la gente si aspettava da un "reverse hypertreading" hardware.

No, perchè la logica che riordina il codice (estrae il parallelismo) di un singolo thread, perde efficienza (in media) già dalla terza ALU da servire, quindi si avrebbe un aumento relativo delle performance, ma con un aumento altissimo della complessità. (in breve, non conviene...)

[paolo.oliva2]

Io sono in overflow da tempo con tutti sti dati...

Però quello che non riesco a capire... (il nubbione 1° della classe sono io, Calabar )... Non sarebbe stato più semplice rimanere nell'architettura K10 raddoppiando i registri esistenti ed al limite aggiungerne altri, adeguando comunque il tutto a monte per far si che il tutto funzionasse a più istruzioni elaborate per clock? (chiaramente con tutte le istruzioni nuove...).

Cioè... non sono certo un tecnico di proci all'interno, ma vedere lo schema di un K10 e quello di un Buldozer... c'è da prendere paura... raddoppia quasi ovunque.

Però... non ricordo che AMD abbia fatto un flop architetturalmente su un procio... il Phenom I, la colpa era del 65nm perché sul 45nm se avesse avuto il low-k o l'HKMG o ambedue da subito... la cosa sarebbe stata diversa.

Ma anche l'atmosfera che c'è è molto diversa... alla presentazione del Phenom I praticamente hanno mandato i portaborse... ora praticamente si danno quasi i cazzotti a se stessi perché non possono parlare...

[affiu]

Originariamente inviato da paolo.oliva2

Io sono in overflow da tempo con tutti sti dati...

Però quello che non riesco a capire... (il nubbione 1° della classe sono io, Calabar )... Non sarebbe stato più semplice rimanere nell'architettura K10 raddoppiando i registri esistenti ed al limite aggiungerne altri, adeguando comunque il tutto a monte per far si che il tutto funzionasse a più istruzioni elaborate per clock? (chiaramente con tutte le istruzioni nuove...).

Cioè... non sono certo un tecnico di proci all'interno, ma vedere lo schema di un K10 e quello di un Buldozer... c'è da prendere paura... raddoppia quasi ovunque.

Però... non ricordo che AMD abbia fatto un flop architetturalmente su un procio... il Phenom I, la colpa era del 65nm perché sul 45nm se avesse avuto il low-k o l'HKMG o ambedue da subito... la cosa sarebbe stata diversa.

Ma anche l'atmosfera che c'è è molto diversa... alla presentazione del Phenom I praticamente hanno mandato i portaborse... ora praticamente si danno quasi i cazzotti a se stessi perché non possono parlare...

premesso che orapiu manca poco alla conferenza..e dopo di che verrano valanghe di opinioni,commenti,critiche ecc

secondo me ,l'archiettura bulldozer non è completa al 100 %, perche da un lato è una architettura nuova(è dunque sarà soggetta di miglioramenti) sia perchè è una strada intrapresa per avere piu potenza

dopotutto non si vive di sola frequenza ma anche di altro(?) ,di qualcosa di nuovo di diverso

poi per il mio immaginario sarei molto curioso di vedere come vanno i giochi , bulldozer vs apu

bulldozer fara fare piu frame rispetto a apu , ma secondo me apu cmq anche se lo fa girare con risoluzioni un po minori di bulldozer

è tutto su un unico pezzo hardaware invece che di un processore e scheda video a parte

meno watt, meno calore ,meno corrente ...tutto il resto deve solo avverarsi a questo punto

cioe voglio vedere se si potra constatare la differenza fra un k10 vs bulldozer,pero il k10 ha una apu.....è questo il punto?

perchè se apu farà girare i giochi in maniera ''naturale'' ,allora la strada ''è'' quella giusta ,secondo me

poi per quanto si possa filosofare sulla fantasia, il muro di frequenze odierne su cui bramiamo sempre di piu ,addirittura sempre invadere (forse) le future gpu integrate.....

il tutto genera confusione ,allarme ,ma questo tutto è solamente una grande massa di nebbia ,da cui si potra scorgere bulldozer che esce da pozzo magico ....ma verrà seguito da apu

è soltanto la frammentazione di un progetto molto piu grande ,il fatto di vedere molte novita messe assieme(per il momento daranno i loro frutti da separati)

ma presto queste novita convergeranno ,perchè in futuro ci sarà bisogno di elaborare flussi di dati molto elevati (ad esempio un sata 12)...e onestamente mi scoccerebbe ritrovarmi con un 24 0 36 core da raffreddare con l'elio liquido

aspettiamo....

[Pihippo]

Originariamente inviato da Ren

Volevo dire che il branch condiviso non crea grandi aumenti prestazionali quando un core è inutilizzato, perchè credo abbiano mantenuto la stessa ampiezza, ma implementando il doppio thread. (semplificando il concetto)

I soli stadi che mi vengono in mente che potrebbero aumentare le performance mono-thread del cluster sono i decoder ed il dispatch(se tutte le sue porte sono connesse ad ogni core).

Ciao
Scusami, non avevo inteso bene il concetto.

[Ren]

Però quello che non riesco a capire... (il nubbione 1° della classe sono io, Calabar )... Non sarebbe stato più semplice rimanere nell'architettura K10 raddoppiando i registri esistenti ed al limite aggiungerne altri, adeguando comunque il tutto a monte per far si che il tutto funzionasse a più istruzioni elaborate per clock? (chiaramente con tutte le istruzioni nuove...).

Se parli di raddoppiare registri (sotto, sotto) stai proponendo SMT anche per AMD...

Cioè... non sono certo un tecnico di proci all'interno, ma vedere lo schema di un K10 e quello di un Buldozer... c'è da prendere paura... raddoppia quasi ovunque.

Raddoppia tutto, ma in realtà sono due core (fusi) in uno, grazie ad alcuni elementi in comune.

[capitan_crasy]

Tenete duro, il 24 agosto al Hot chip 22 sapremo () le caratteristiche di Bulldozer...

[dark.halo]

Originariamente inviato da capitan_crasy

Tenete duro, domani comincia Hot chip 22 e finalmente sapremo () le caratteristiche di Bulldozer...

vuoi dire che già da domani si comincerà a sapere qualcosa, non era il 24

EDIT:ho visto adesso sul sito e si il 24 si parla di bulldozer e bobcat (alle 5.45 e 6.30 ora locale), ci sarà anche intel con westmere-ex 10 core/20 thread

[capitan_crasy]

Originariamente inviato da dark.halo

vuoi dire che già da domani si comincerà a sapere qualcosa, non era il 24

EDIT:ho visto adesso sul sito e si il 24 si parla di bulldozer e bobcat (alle 5.45 e 6.30 ora locale), ci sarà anche intel con westmere-ex 10 core/20 thread

Hai ragione...
Corretto il post precedente...

[navarre63]

Originariamente inviato da bjt2

Per quanto riguarda le pipeline supposte di bulldozer.
Il clock dipende da quanto uno stadio della pipeline è piccolo (a parità di processo produttivo). Più è piccolo, più stadi ci vogliono. Per misurare quanto uno stadio di una pipeline è lento (ma più è lento, più "potente" è, più cose può fare e meno stadi ci vogliono) c'è una unità di misura: il ritardo in termini di FO (mi pare sia Fan-Out, ma io conosco un altro significato per questo termine). Uno stadio di pipeline con FO n, vuol dire che è composto da n porte logiche in cascata, ossia che un segnale in ingresso allo stadio deve percorrere al più n porte logiche prima di giungere all'uscita. Il tempo di propagazione di una porta logica si misura in picosecondi. Così uno stadio con FO n avrà un ritardo di propagazione di poche centinaia di picosecondi.
Più è alto il FO, più è complicata l'operazione che può fare uno stadio, potenzialmente ci vogliono meno stadi, ma il clock è dato dallo stadio più lento, per cui il clock è più basso.

Le CPU della serie K7-8-10 fino ad adesso sono state accreditate di stadi con FO 24 (circa: non si conosce il valore esatto, ma lo si stima dal clock riferito al processo produttivo), che è un valore molto alto: clock non molto alto, ma ogni stadio ha sufficente potenza elaborativa da permettere pochi stadi (12 la pipeline intera del K10, mi pare).

Le CPU della serie Core 2/Nehalem sono accreditate di qualche FO in meno (21-22), per cui possono avere un clock più elevato a parità di processo produttivo (infatti il clock è limitato principalmente dal TDP, ossia dal leakage: se correttamente raffreddate le CPU INTEL sfiorano i 5GHz) anche se comunque i transistors INTEL sono un po' più veloci di quelli AMD, quindi avrebbero avuto un clock massimo superiore anche con lo stesso FO (ma maggiore leakage perchè manca il SOI)...
FO minore richiede qualche stadio in più e infatti mi pare sia così (se non lo è, un plauso va agli ingegneri INTEL oppure le unità RISC sono più semplici)

Poi viene l'architettura POWER, accreditata di 16-18 FO. E infatti arriva a 4.14 GHz stock con il processo a 45nm SOI...

Poi viente il Pentium 4. E' accreditato di un FO di 16 per le parti non dual pumped e di un FO 8 per l'ALU dual pumped.

Come si vede è possibile fare una architettura efficiente anche con un FO vicino al P4 (vedi la CPU Power) e comunque Buldozer potrebbe avere un FO leggermente inferiore al K10 (ma probabilmente si dovrebbero fare tutte le librerie daccapo), senza per questo rischiare di essere il nuovo Pentium 4.


Questo per dire che c'è margine per fare pipeline più lunghe senza per questo fare un nuovo P4...

ma che aspetta la NASA a chiamarti?

[Korn]

a quelli gli basta un 8088