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

[paolo.oliva2]

Originariamente inviato da bjt2

Ho messo il link a google groups apposta. Il tipo si da le arie da ex dipendente AMD che ha lavorato anche su bulldozer. Io non credo sia un mitomane perchè lo avrebbero sgamato. Da come parla sembra quantomeno competente...
A dire la verità dice anche che si perde un 5% di IPC per la microarchitettura. E poi ho capito dopo cosa intendeva: passando da 22 FO4 a 17 FO4 si è perso qualche forwarding path che accellerava qualcosina, ma lui dice che era così allo stadio a cui lui ha lasciato il progetto e che potrebbero aver risolto diversamente...

Comunque 20% in più di IPC, 30-40% di più in clock... Non oso pensare...

Corrisponderebbe ad un Thuban @6,710GHz ed esattamente 2,1 volte il Thuban def.
Cinebench sui 17

Un BD X16 anche a solo 3GHz sarebbe sovrumano...

[somethingstrangeinyourmind]

Ragazzi siete dei grafomani!
Vi lascio qualche ora e mi ritrovo 5 pagine di thread da leggere!
Scherzi a parte complimenti a tutti per gli spunti ed i ragionamenti.
Mi sembra però che ci si stia concentrando molto su BD e poco su Llano.

[XCRYSIS95]

Ma se Bulldozer userà un nuovo socket (AM3 +) i vecchi processori Am3 saranno compatibili con il nuovo socket ,che pensate ?

[Capozz]

Originariamente inviato da somethingstrangeinyourmind

Ragazzi siete dei grafomani!
Vi lascio qualche ora e mi ritrovo 5 pagine di thread da leggere!
Scherzi a parte complimenti a tutti per gli spunti ed i ragionamenti.
Mi sembra però che ci si stia concentrando molto su BD e poco su Llano.

Beh alla fine Llano è praticamente noto: conosciamo l'architettura, sappiamo le prestazioni della componente cpu e possiamo immaginare quelle della gpu, il momento migliore per parlarne sarà dopo l'uscita e verificare quanto la combinazione cpu+gpu possa dare dei risultati concreti.
Bulldozer invece è qualcosa di totalmente nuovo rispetto al passato, decisamente più intrigante

[Capozz]

Originariamente inviato da XCRYSIS95

Ma se Bulldozer userà un nuovo socket (AM3 +) i vecchi processori Am3 saranno compatibili con il nuovo socket ,che pensate ?

A quanto pare no.

[floydbarber]

Originariamente inviato da Capozz

A quanto pare no.

Veramente si diceva di si. E poi, altrimenti che senso avrebbe chiamarlo AM3+?

[Pihippo]

Originariamente inviato da bjt2

Ho messo il link a google groups apposta. Il tipo si da le arie da ex dipendente AMD che ha lavorato anche su bulldozer. Io non credo sia un mitomane perchè lo avrebbero sgamato. Da come parla sembra quantomeno competente...
A dire la verità dice anche che si perde un 5% di IPC per la microarchitettura. E poi ho capito dopo cosa intendeva: passando da 22 FO4 a 17 FO4 si è perso qualche forwarding path che accellerava qualcosina, ma lui dice che era così allo stadio a cui lui ha lasciato il progetto e che potrebbero aver risolto diversamente...

Comunque 20% in più di IPC, 30-40% di più in clock... Non oso pensare...

Ciao Bjt2. Sei un grande
Letta la discussione linkata, Posto cosa dice Mitchaslup


The issue was that the 3rd unit was used a lot, only to run into the
dual-only ported DataCache. This caused sequencing issues.

Inoltre un tizio gli chede: The third ALU is of more concern, Intel will standardize benchmarks to
make this look bad, even though I know it was used 1% on average

E lui risponde:
So what else is new?

C'è da ridere o da piangere? Ci potresti illuminare anche sulla parte della terza unità?

[paolo.oliva2]

STRAIN engineering has become one of the main con-
- [ Traduci questa pagina ]
16 ago 2010 - for 32-nm SOI CMOS technology with HKMG. Performance .... technology with enhanced stress, porous low-k BEOL and immersion lithography,” in IEDM Tech. ...
ieeexplore.ieee.org/iel5/16/5491381/05467180.pdf?tp=&arnumber...

Porc zocc, ci vuole la password



Però li riporta pure low-k.
Se il 32nm HKMG AMD esce alla partenza con il low-k, sono caxxi... andrebbe a palla.

[cionci]

Originariamente inviato da paolo.oliva2

@Bjt2.

Domanda da nubbio.

La lunghezza delle pipeline è una costante o comunque dipendente dal silicio?
Tipo... procio X, pipeline 10 su 90nm, max 5GHz, se il silicio arriva a quella frequenza bene, altrimenti amen. Stesso procio, pipeline 10, ma silicio 45nm, l'architettura avrebbe lo stesso limite di 5GHz anche se il silicio potesse dare 6GHz? Oppure la pipeline risente comunque di latenze inferiori per la riduzione del silicio e quindi permettere di più?

Perché il PIV era fatto a 90nm o 120nm? Se Buldozer ha una pipeline simile ma 32nm è equiparabile o promette più velocità?

In un circuito digitale sincrono (con clock), il critical path è il percorso del circuito che provoca maggiori ritardi e di conseguenza limita la frequenza.
Solitamente c'è un registro sorgente, un circuito che elabora il contenuto del registro ed infine il registro di destinazione. Il circuito per poter funzionare ad una data frequenza deve essere in grado di presentare i risultati in modo stabile all'ingresso del registro qualche istante prima del nuovo fronte di clock (esattamente Tsetup + Thold dei flip-flop che compongono i registri).
Chiamando Tcp il tempo massimo di attraversamento del circuito, o meglio il T di attraversamento del critical path, abbiamo che:

Tsetup + Thold + Tcp < T

dove T è il periodo di clock, cioè 1 / F (F è la frequenza di clock).

Semplificando...la pipeline non è altro che una suddivisione in stadi (stage) dell'esecuzione di una istruzione. Ogni stadio esegue una piccola parte dell'istruzione fra un registro sorgente ed un registro di destinazione. Lo stage successivo, al clock successivo, prende il risultato e mette a sua volta il suo risultato in un altro registro entro la fine del ciclo di clock.
Di fatto nella pipeline abbiamo in esecuzione un massimo di una istruzione per stage della pipeline (le cose possono anche andare diversamente in caso di duplicazione delle unità di esecuzione, ma come dicevo: semplifichiamo).
Con la pipeline a regime abbiamo comunque la terminazione di una istruzione per ciclo di clock. Con la pipeline vuota dobbiamo attendere un numero di clicli di clock pari alla lunghezza della pipeline prima che l'esecuzione di una istruzione sia terminata.
Quindi possiamo applicare il discorso fatto prima: il critical path di una CPU è il critical path con ritardo più alto fra i critical path di ogni stage. Questo critical path servirà a determinare la frequenza massima raggiungibile dalla CPU con una determinata tecnologia litografica (potenza permettendo).

Aumentare il numero di stadi ha però delle contro-indicazioni: se la pipeline va in stallo (cioè deve essere svuotata) in caso di misprediction (fallimento della branch prediction, l'algoritmo che "prevede" dove andrà a finire un salto condizionale e quindi riempirà di conseguenza la pipeline) o per il cambio di contesto, prima di terminare una nuova istruzione passeranno ben 31 cicli di clock. E' chiaro che per ovviare a questi overhead bisogna avere un ottimo algoritmo di branch prediction e bisogna avere la possibilità di raggiungere frequenze nettamente maggiori dei concorrenti.

Il Prescott aveva una pipeline di 31 stadi per gli interi. Una cosa praticamente mai vista (normalmente sono intorno ai 10-12 stadi per gli interi, tranne le prime implementazioni). Aveva però gravi problemi di leakage (è uno degli elementi che vanno a determinare la potenza necessaria a far funzionare la CPU) che non gli permettevano di raggiungere le frequenze che gli ingegneri avrebbero voluto fargli raggiungere (pensate che Intel avrebbe voluto raggiungere gli 8-10 Ghz entro due generazioni litografiche). Questa fu la motivazione per cui il progetto Tejas, il successore di Prescott, non arrivò nemmeno sul mercato.

[paolo.oliva2]

Originariamente inviato da cionci

In un circuito digitale sincrono (con clock), il critical path è il percorso del circuito che provoca maggiori ritardi e di conseguenza limita la frequenza.
Solitamente c'è un registro sorgente, un circuito che elabora il contenuto del registro ed infine il registro di destinazione. Il circuito per poter funzionare ad una data frequenza deve essere in grado di presentare i risultati in modo stabile all'ingresso del registro qualche istante prima del nuovo fronte di clock (esattamente Tsetup + Thold dei flip-flop che compongono i registri).
Chiamando Tcp il tempo massimo di attraversamento del circuito, o meglio il T di attraversamento del critical path, abbiamo che:

Tsetup + Thold + Tcp < T

dove T è il periodo di clock, cioè 1 / F (F è la frequenza di clock).

Semplificando...la pipeline non è altro che una suddivisione in stadi (stage) dell'esecuzione di una istruzione. Ogni stadio esegue una piccola parte dell'istruzione fra un registro sorgente ed un registro di destinazione. Lo stage successivo, al clock successivo, prende il risultato e mette a sua volta il suo risultato in un altro registro entro la fine del ciclo di clock.
Di fatto nella pipeline abbiamo in esecuzione un massimo di una istruzione per stage della pipeline (le cose possono anche andare diversamente in caso di duplicazione delle unità di esecuzione, ma come dicevo: semplifichiamo).
Con la pipeline a regime abbiamo comunque la terminazione di una istruzione per ciclo di clock. Con la pipeline vuota dobbiamo attendere un numero di clicli di clock pari alla lunghezza della pipeline prima che l'esecuzione di una istruzione sia terminata.
Quindi possiamo applicare il discorso fatto prima: il critical path di una CPU è il critical path con ritardo più alto fra i critical path di ogni stage. Questo critical path servirà a determinare la frequenza massima raggiungibile dalla CPU con una determinata tecnologia litografica (potenza permettendo).

Aumentare il numero di stadi ha però delle contro-indicazioni: se la pipeline va in stallo (cioè deve essere svuotata) in caso di misprediction (fallimento della branch prediction, l'algoritmo che "prevede" dove andrà a finire un salto condizionale e quindi riempirà di conseguenza la pipeline) o per il cambio di contesto, prima di terminare una nuova istruzione passeranno ben 31 cicli di clock. E' chiaro che per ovviare a questi overhead bisogna avere un ottimo algoritmo di branch prediction e bisogna avere la possibilità di raggiungere frequenze nettamente maggiori dei concorrenti.

Il Prescott aveva una pipeline di 31 stadi per gli interi. Una cosa praticamente mai vista (normalmente sono intorno ai 10-12 stadi per gli interi, tranne le prime implementazioni). Aveva però gravi problemi di leakage (è uno degli elementi che vanno a determinare la potenza necessaria a far funzionare la CPU) che non gli permettevano di raggiungere le frequenze che gli ingegneri avrebbero voluto fargli raggiungere (pensate che Intel avrebbe voluto raggiungere gli 8-10 Ghz entro due generazioni litografiche). Questa fu la motivazione per cui il progetto Tejas, il successore di Prescott, non arrivò nemmeno sul mercato.

Praticamente il nesso sarebbe.... se aumenti di un tot la frequenza, quando l'algoritmo di branch prediction fa il suo lavoro, sei nettamente superiore, se invece l'algoritmo di branch prediction sbaglia, il tempo "morto" in cui la pipeline si deve svuotare e riempire, se quegli n cicli sono ad una frequenza alta, non sarebbe avvertibile lo stallo.

Ma io penso che la "filosofia" con cui un produttore di procio realizza l'architettura è anche in base al silicio, e, ove progetta l'architettura in un modo diverso, cerca di modificare il silicio. Con Tejas Intel ci aveva provato senza risultato, quindi l'architettura pompata di Intel è la risposta per aumentare la potenza, visto che per il leakage non sarebbe possibile aumentare la frequenza del silicio.
Beh, certamente non si può dire che l'idea di AMD sia sbagliata, in quanto Intel l'aveva già intrapresa e ci aveva rinunciato non perché l'idea fosse sbagliata, ma perché gli 8-10GHz erano irraggiungibili.

Però, mi viene il dubbio che questo modulo di BD possa forse ovviare in qualche modo lo stallo della pipeline. Cioè... oltre ad essere praticamente un raddoppio di core per un SMT hardware, non potrebbe anche avere qualche nesso anche con l'algoritmo di branch prediction?

Comunque secondo me AMD nasconde ancora qualche cosa, perché non può dire una volta che darebbe 2 core fisici al posto di 1 fisico e uno logico e annunciare che BD X8 sarebbe il max, perché d'accordo che potrebbe raddoppiare i core in un unico package, però... dovrebbe comunque portare l'insieme ad una frequenza superiore ai 3GHz.
Comunque anche questo punto mi sembra che induca a pensare in clock sui 4Ghz e più per un X8.
Magny-C a 12 core è un 2,4GHz mi sembra. Un singolo Thuban X6 ha in desktop una frequenza di 3,2GHz X6 e 3,6Ghz turbo, ma che potrebbe essere anche di più se tirato al max di TDP. Ora... se BD X16 fosse sui 3GHz per contrastare un SB 8+8 a 3GHz, mi sembra chiaro che un BD X8 singolo dovrebbe avere almeno un 50% di clock superiore all'X16, quindi 3GHz + 50%, arriviamo a 4,5GHz sicuri in turbo.

Insomma, tutto concorda sempre a portare ad un innalzamento delle frequenze rilevante, sia per il tipo di architettura, sia per la lunghezza della pipeline, sia per il leakage basso del silicio e sia per tutto quello che è trapelato sul silicio, che se avesse pure il low-k, sarebbe una bestia non da ridere. Io penso sempre più a 4GHz sicuri e verso i 5GHz con il turbo.

[cionci]

Attenzione, AMD non sta intraprendendo la stessa strada di Intel, non ha creato un'architettura a pipeline profonde O almeno non sembra da quanto attualmente fatto vedere.

Lo stallo della pipeline non si può ovviare, bisogna perfezionare gli algoritmi di branch prediction E' questa è una cosa che appunto è stata fatta in Bulldozer.

La cosa che ancora mi è più oscura è come le unità floating point verranno condivise fra i due thread allocati nel singolo modulo Bulldozer.
La FPU sarà ad uso esclusivo di un solo thread ? O la FPU avrà una specie SMT che permetterà di "mescolare" le istruzioni dei due thread in modo da poter sfruttare al minimo una unità FMAC per ogni thread ? bjt2: sai niente riguardo a questo punto ?

[papafoxtrot]

Originariamente inviato da bjt2

Non sono sicuro di aver capito la domanda. In ogni caso:
Il FO4 è una misura della complessità dello stadio della pipeline. Fissata la pipeline, la complessità è data. Poi si può implementarla a 130, 90, 65, 45, 32nm ecc... A seconda del processo, sarà maggiore la frequenza a cui potrà andare... Non esiste un limite intrinseco al clock dato un processo, o meglio, esiste un limite intrinseco dato un FO4 di una architettura. La combinazione di FO4 e processo da la velocità.

Per esempio. Il Power 7 ha un FO4 di 17 (mi pare) ed è stato implementato con il 45nm, mi pare con il Low-k. Ora quel processore ha una caterva di transisors. Il quadcore arriva a 4.14 GHz e l'octacore a 3.96 Ghz... Un ipotetico bulldozer X4 fatto a 45nm (il processo del Thuban) sarebbe arrivato a 4.2-4.3 stock, minimo, sia perchè il Power 7 ha molti più transistors e molte più unità attive (un quad core ha 16 thread, e ogni core ha mi pare 12 unità di esecuzione), sia perchè il Power 7 è una CPU server e tradizionalmente queste hanno qualche centinaia di MHz in meno delle controparti desktop...

EDIT: in ogni caso, nel caso peggiore, un buldozer X4 a 4.1 Ghz e un Bulldozer X8 a 3.9 Ghz è fattibile visto il Power 7, anche con questo 45nm Low-k. Ricordiamo che IBM usa lo stesso processo di GF/AMD...

EDIT: Su wikipedia dice che esiste una versione quadcore da 4.25 Ghz. Il Power6 che aveva un FO4 di 13 arrivava a 5GHz e IBM aveva in laboratorio un prototipo funzionante a 6GHz...

EDIT: sto leggendo su google gruppi che tra Thuban e Buldozer, c'è un progetto cancellato che aveva un FO4 di 13... Sarebbe arrivato a 5GHz con il 45nm! Dice anche che BD dovrebbe avere un IPC (A PARITA' DI FREQUENZA) del 20-25% in più. Il tizio sembra essere un ex dipendente AMD che ha lavorato al progetto... Il gruppo in guestione è http://groups.google.de/group/comp.a...14f6049?hl=de# e il tipo si chiama Mitch_qualcosa...

Dunque F04 mi par di capire che voglia dire una pipeline con latenze molto basse, giusto? Il che comporterebbe frequenze alte?
La pipeline del P4 aveva F04=13.
Posso dire che se aumentano gli stadi l'Fo4 diminuisce, o le due cose sono solo blandamente collegate?
Un F04 di 13, com'era quello del Power 6 e di questo fumoso progetto AMD poi abbandonato, può significare pipeline molto lunghe? Direi di si, a vedere dalle frequenze a cui lavorava il power6...
Ma come sappiamo se la pipeline si allunga è difficile che l'IPC si mantenga così alto, considerato anche che si deve togliere un 20% per via del modulo (che rende l'80% di un dual core vero).

Processo produttivo: IBM sforna i power7 a 3,9GHz 8 coree. Si deve però considerare che il TDP di queste CPU è parecchio superiore a quello delle CPU desktop a cui siamo abituati. Credo che l'8 core faccia 576mm^2 e 200W di TDP. E a quanto ne so IBM usa un processo SOI più avanzato, che però potrebbe essere adottato da GF nei 32nm.
A questi dobbiamo certo togliere i vari 32nm e HKMG. Ad ogni modo le due architetture non saranno mai comparabili.

Originariamente inviato da paolo.oliva2

Allora... anche in caso di IPC non "spettacolare", con un aumento del 30-35% del clock rispetto ad adesso, anche un Thuban andrebbe come un X6 i7 i980X (SB penso di no).

Il mio portafoglio comincia a tremare... col cavolo che un BD X8 costerà 300€

Sto giro rimaniamo fregati tutti....

Altro che tutti fregati. Rimaniamo tutti fregati se BD va poco e AMD lo svend, perché al giro dopo va a ramengo.
Se BD sarà prezzato a 200 euro suonerà come una campana da morto.

DIN

DIN

DIN

Voglio un Bulldozer a 1000 eurooooooo!!

Originariamente inviato da paolo.oliva2

STRAIN engineering has become one of the main con-
- [ Traduci questa pagina ]
16 ago 2010 - for 32-nm SOI CMOS technology with HKMG. Performance .... technology with enhanced stress, porous low-k BEOL and immersion lithography,” in IEDM Tech. ...
ieeexplore.ieee.org/iel5/16/5491381/05467180.pdf?tp=&arnumber...

Porc zocc, ci vuole la password



Però li riporta pure low-k.
Se il 32nm HKMG AMD esce alla partenza con il low-k, sono caxxi... andrebbe a palla.

Magari ci fosse! E' vero che se lo hanno adottato sul 45nm difficilmente lo elimineranno dal nodo successivo. E forse gli costa meno sviluppare solo il 32 con low-k che un 32 con ed uno senza, per cui è probabile che tutti i processori a 32nm abbiano low-k.

[papafoxtrot]

Originariamente inviato da bjt2

Ho messo il link a google groups apposta. Il tipo si da le arie da ex dipendente AMD che ha lavorato anche su bulldozer. Io non credo sia un mitomane perchè lo avrebbero sgamato. Da come parla sembra quantomeno competente...
A dire la verità dice anche che si perde un 5% di IPC per la microarchitettura. E poi ho capito dopo cosa intendeva: passando da 22 FO4 a 17 FO4 si è perso qualche forwarding path che accellerava qualcosina, ma lui dice che era così allo stadio a cui lui ha lasciato il progetto e che potrebbero aver risolto diversamente...

Comunque 20% in più di IPC, 30-40% di più in clock... Non oso pensare...

Ma se questo ha lasciato AMD prim che avessero un sample, e ancora prima che avessero finito l'architettura, come diavolo può parlare di IPC +20%?

Io tendo a credere più al +12,5% di JF-AMD sinceramente.


Che comunque combinato con l'aumento di frequenza e con i due core in più da un risultato molto elevato, anche se meno sensazionalistico.

Un +15% di frequenza rispetto a thuban porterebbe a prestazioni del 70% superiori, che vuol dire probabilmente centrare l'obiettivo di superare i SB X6.

[capitan_crasy]

Per bjt2 e cionci:

Siete due grandissimi!!!

Vi sparo subito in prima pagina!!!

Originariamente inviato da papafoxtrot

Ma se questo ha lasciato AMD prim che avessero un sample, e ancora prima che avessero finito l'architettura, come diavolo può parlare di IPC +20%?

Io tendo a credere più al +12,5% di JF-AMD sinceramente.


Che comunque combinato con l'aumento di frequenza e con i due core in più da un risultato molto elevato, anche se meno sensazionalistico.

Un +15% di frequenza rispetto a thuban porterebbe a prestazioni del 70% superiori, che vuol dire probabilmente centrare l'obiettivo di superare i SB X6.

JF dice che il 12% di IPC in più è una valutazione sbagliata!

[cionci]

Originariamente inviato da papafoxtrot

Dunque F04 mi par di capire che voglia dire una pipeline con latenze molto basse, giusto? Il che comporterebbe frequenze alte?
La pipeline del P4 aveva F04=13.
Posso dire che se aumentano gli stadi l'Fo4 diminuisce, o le due cose sono solo blandamente collegate?

Sì, sono legati. Diciamo che si allunga la pipeline con l'obiettivo di ottenere un critical path più corto e quindi un FO4 più basso.
FO4=13 per il P4 Willamette o Prescott ? Willamette aveva la pipline degli interi a 20 stadi, mentre Prescott l'aveva a 31 stadi.

[capitan_crasy]

Donald Newell (Vice Presidente e Chief Technology Officer (CTO) divisione server AMD) dichiara che AMD sta valutando l'ipotesi di proporre Server con architettura X86 Bobcat la quale sarà la base delle prossime APU della serie Ontario destinate al mercato Netbook.

"We are definitely in the process of examining this as a design point. It would be foolish not to.

There's only a few papers and there's a lot more data to collect. It really depends on a number of factors to whether or not that's a good design point.

There's a certain amount of computation to be done, and a certain amount of time for it to be done. The large cores will get more work done in a single amount of time and get you a better answer."

Bobcat è del 10% inferiore, come prestazioni globali, dell'architettura K10, tuttavia il suo consumo massimo è estremamente basso con valori che possono raggiungere 1 Watt con alcune specifiche versioni.

Clicca qui...

[calabar]

Originariamente inviato da cionci

La cosa che ancora mi è più oscura è come le unità floating point verranno condivise fra i due thread allocati nel singolo modulo Bulldozer.
La FPU sarà ad uso esclusivo di un solo thread ? O la FPU avrà una specie SMT che permetterà di "mescolare" le istruzioni dei due thread in modo da poter sfruttare al minimo una unità FMAC per ogni thread ? bjt2: sai niente riguardo a questo punto ?

Che io ricordi, e da quanto avevo capito, era stato confermato che la FPU poteva lavorare su thread indipendenti se le istruzioni erano a 128 bit (2 contemporanee) o 64 bit (4 contemporanee).
Quindi il thread è uno solo esclusivamente nel caso di istruzioni AVX, negli altri casi, ossia in tutte le situazioni viste fino ad oggi, dovrebbero lavorare come due motori FP.
Qualcosa di molto differente da SMT comunque, la pipeline viene "divisa", non "condivisa".
Qualcuno conferma/smentisce?

Originariamente inviato da papafoxtrot

Io tendo a credere più al +12,5% di JF-AMD sinceramente.

Concordo, anche a me pare plausibile per quanto emerso finora una percentuale intorno al 10%.
Anche se poi bisogna vedere in quali ambiti, ricordiamo che il 12,5% era riferito all'incremento tra un 12 e un 16 core in ambito server.

[paolo.oliva2]

Originariamente inviato da cionci

Sì, sono legati. Diciamo che si allunga la pipeline con l'obiettivo di ottenere un critical path più corto e quindi un FO4 più basso.
FO4=13 per il P4 Willamette o Prescott ? Willamette aveva la pipline degli interi a 20 stadi, mentre Prescott l'aveva a 31 stadi.

Se sarà confermato che BD ha una pipeline 17 FO4, deve avere per forza un clock sopra il PIV Willamette (20) e Prescott (31).

Non si può realizzare un'architettura che va solo se il clock è alto e poi avere un clock del 10% superiore a Thuban.
Indi se il PIV ha sfiorato i 4GHz (mi sembra) ma non oltre per prb di leakage, questo prb AMD non l'ha, quindi contando la pipeline ancora più propensa a clock maggiori, ci si dovrebbe aspettare al 101% clock sopra ai 4GHz in condizione non turbo.
Sbaglio?

[dark.halo]

Originariamente inviato da capitan_crasy

Per bjt2 e cionci:

Siete due grandissimi!!!

Vi sparo subito in prima pagina!!!

JF dice che il 12% di IPC in più è una valutazione sbagliata!

Infatti JF non si è mai sbilanciato così ha detto solo che con il 33% di core aggiuntivi si ha il 50% si troughput.
Analizziamo nel dettaglio 33% di core in più, ok ma noi sappiamo che lo scaling non è perfetto; facciamo che ogni core in più scala dello 0.80%,

33%* 0.80 = 26.4 %
quindi aumentando i core del 33% otteniamo il 26,4 % di prestazioni in più all'incirca come Thuban ( paolo chiedo conferma a te che hai più esperienza sul campo).
Quindi in totale l'ipc dovrebbe essere compreso in un valore di 20/23% in più.

[paolo.oliva2]

Originariamente inviato da calabar

Che io ricordi, e da quanto avevo capito, era stato confermato che la FPU poteva lavorare su thread indipendenti se le istruzioni erano a 128 bit (2 contemporanee) o 64 bit (4 contemporanee).
Quindi il thread è uno solo esclusivamente nel caso di istruzioni AVX, negli altri casi, ossia in tutte le situazioni viste fino ad oggi, dovrebbero lavorare come due motori FP.
Qualcosa di molto differente da SMT comunque, la pipeline viene "divisa", non "condivisa".
Qualcuno conferma/smentisce?

Anche a me sembra così.

Concordo, anche a me pare plausibile per quanto emerso finora una percentuale intorno al 10%.
Anche se poi bisogna vedere in quali ambiti, ricordiamo che il 12,5% era riferito all'incremento tra un 12 e un 16 core in ambito server.

Però non riesco a capire una cosa.
Il Phenom II andava piano nei calcoli interi e in FP praticamente non riusciva a sfruttare tutta la potenza perché era sovrabbondante rispetto alla realtà.
Ora, in BD praticamente l'INT è stato aumentato del 50% (c'è un INT in più ogni 2 core), lasciamo stare l'FP.

Non riesco a trovare una correlazione sul fatto che se anche per la condivisione di parti comuni fra i core porterebbe ad una diminuzione dell'IPC, dall'altra, il potenziamento dell'INT e dell'FP dovrebbero comunque portare vantaggi. Sarebbe teoricamente stupido aumentare l'INT del 50% per poi castare i proci per farlo diminuire del 40%, a meno che questa diminuzione non comporti come vantaggio un notevole risparmio di TDP e quindi clock alti anche con parecchi moduli.

Sbaglio?