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

[Ares17]

Originariamente inviato da cionci

Difficilmente potrà avere un IPC maggiore del 20% sugli int rispetto ad un dual core K10...

Mi sa che Paolo faccia confusione tra ipc ed istruzioni al secondo: un ipc del 20% inferiore unito ad un clock del 40% maggiore certamente ci da una capacità di calcolo maggiore.

[Pihippo]

Originariamente inviato da cionci

Difficilmente potrà avere un IPC maggiore del 20% sugli int rispetto ad un dual core K10...

Ciao
Scusami, ma perchè? Solo perchè sono sol 2 agu e 2 alu? Se fosse cosi si potrebbe gia dire che nel k10 ci potevano essere 40 agu e 320 alu ma alla fine se tutto andava bene ritirava tra alu-agu ed unità di fp 3 macro-op..

[cionci]

Originariamente inviato da Pihippo

Ciao
Scusami, ma perchè? Solo perchè sono sol 2 agu e 2 alu? Se fosse cosi si potrebbe gia dire che nel k10 ci potevano essere 40 agu e 320 alu ma alla fine se tutto andava bene ritirava tra alu-agu ed unità di fp 3 macro-op..

Stiamo parlando di un dual core K10. Quindi le istruzioni che ritira sono 6, non tre.

[cionci]

Ragionando su ALU e AGU, nel K10 non potevano essere occupate contemporaneamente 3 AGU e 3 ALU, perché ogni coppia di ALU e AGO condivideva parte della pipeline.
Quindi la possibilità di ritirare fino a 3 macro-ops per ciclo di clock è assolutamente ben dimensionata.

In BD, le unità AGU e ALU sono completamente distinte. Ci sono due ALU e due AGU per ogni unità di interi. In teoria per avere la possibilità di sfruttare tutte le unità di calco, dovrebbe poter ritirare ben 8 macro-ops per ciclo di clock. Ora bisogna vedere bene come sono organizzate le cose, perché questo significa che la Load/Store unit (sarà condvisa ? vedendo come è posizionata la L1 direi di no) dovrebbe essere capace di elaborare ben 8 istruzioni per ciclo di clock. Il che mi sembra un tantinello esagerato.

[Pihippo]

Originariamente inviato da cionci

Stiamo parlando di un dual core K10. Quindi le istruzioni che ritira sono 6, non tre.

Ciao
certo, sono 6, se ci riesce, contro le probabili 8 di un modulo di bd? Non penso che il retirement buffer sia condiviso da 2 core, perchè ciò vorrebbe dire che i 2 core stanno processando lo stesso thread......

[JDM70]

Secondo me il punto è nel capire se AMD intenderà un quad core con 2 Moduli o... 4 Moduli, io rimango dell'idea che userà 4 Moduli poi Imho!!!

[Pihippo]

Originariamente inviato da cionci

Ragionando su ALU e AGU, nel K10 non potevano essere occupate contemporaneamente 3 AGU e 3 ALU, perché ogni coppia di ALU e AGO condivideva parte della pipeline.
Quindi la possibilità di ritirare fino a 3 macro-ops per ciclo di clock è assolutamente ben dimensionata.

In BD, le unità AGU e ALU sono completamente distinte. Ci sono due ALU e due AGU per ogni unità di interi. In teoria per avere la possibilità di sfruttare tutte le unità di calco, dovrebbe poter ritirare ben 8 macro-ops per ciclo di clock. Ora bisogna vedere bene come sono organizzate le cose, perché questo significa che la Load/Store unit (sarà condvisa ? vedendo come è posizionata la L1 direi di no) dovrebbe essere capace di elaborare ben 8 istruzioni per ciclo di clock. Il che mi sembra un tantinello esagerato.

Ciao
Scusami ho visto ora il tuo ultimo post.
In effetti pare esagerato che un modulo bd possa ritirare 8 macro-op, però alla fine dei conti nehalem (ed il suo papà anche se con minor successo) riuscivano ad avvicinarsi a 4 mop ritirate per ciclo, in nehalem grazie a vari tweak e l'HT più che nei core 2. Per la L\S unit, perchè dovrebbe essere capace di elaborare 8 mop? Scusami la L\S unit si limita a caricare(load) o scrivere(store) dati\operandi sulla cache necessari per l'esecuzione di molte istruzioni. Almeno cosi è quello che ho capito.

[Lan_Di]

Originariamente inviato da cionci

Ragionando su ALU e AGU, nel K10 non potevano essere occupate contemporaneamente 3 AGU e 3 ALU, perché ogni coppia di ALU e AGO condivideva parte della pipeline.
Quindi la possibilità di ritirare fino a 3 macro-ops per ciclo di clock è assolutamente ben dimensionata.

In BD, le unità AGU e ALU sono completamente distinte. Ci sono due ALU e due AGU per ogni unità di interi. In teoria per avere la possibilità di sfruttare tutte le unità di calco, dovrebbe poter ritirare ben 8 macro-ops per ciclo di clock. Ora bisogna vedere bene come sono organizzate le cose, perché questo significa che la Load/Store unit (sarà condvisa ? vedendo come è posizionata la L1 direi di no) dovrebbe essere capace di elaborare ben 8 istruzioni per ciclo di clock. Il che mi sembra un tantinello esagerato.

Ti chiedo 2 cose per chiarirmi le idee.
1)Quando ti riferisci al K10, le macro ops son intese per core?
2)Per BD, le 8 sono riferite per modulo? cioè 4+4 se si ragiona dal punto di vista dei core, giusto?
Danke.

[paolo.oliva2]

Originariamente inviato da Ares17

Mi sa che Paolo faccia confusione tra ipc ed istruzioni al secondo: un ipc del 20% inferiore unito ad un clock del 40% maggiore certamente ci da una capacità di calcolo maggiore.

Magari nella foga potrò anche sbagliare, ma io per IPC intendo istruzioni per clock, per potenza IPC x clock (inteso come frequenza)

[cionci]

Ogni macro-op è una istruzione ALU/AGU/FPU + una LOAD/STORE, quindi per poter completare 8 macro-ops bisogna essere in grado di completare 8 L/S per ciclo di clock.

[cionci]

Originariamente inviato da Lan_Di

Ti chiedo 2 cose per chiarirmi le idee.
1)Quando ti riferisci al K10, le macro ops son intese per core?
2)Per BD, le 8 sono riferite per modulo? cioè 4+4 se si ragiona dal punto di vista dei core, giusto?
Danke.

1) sì
2) sì

[paolo.oliva2]

Originariamente inviato da cionci

Come il 20% più veloce ? Se perdesse il 20% non può essere contemporaneamente il 20% più veloce.

Io intenderei questo: (oh, io ipotizzo, non ho la tua competenza e comunque cerco di capire come AMD in 5 anni stia agendo per creare un'architettura superiore al K10)

Allora... il modulo BD ha parti in condivisione, il che = -20%

Il modulo BD ha un INT in più, negli INT incrementerebbe (che poi era il punto debole verso l'i7, in quanto in FP non aveva nulla da invidiare, quindi, a livello teorico, mi sembra un passo avanti per uguagliare l'IPC nel senso totale con l'i7)

Ora, la perdita del 20% per la condivisione, non bisogna trattarla fine a sè stessa, perchè comunque comporta una diminuzione di TDP e quindi quel -20% bisogna anche proporzionarlo al clock risultante, cioé... se si perdono 20% di IPC, potrebbe pure essere che si guadagnano, a parità di silicio, forse anche il 10% di clock, quindi bisogna comunque ridimensionarla al 10%.

-------------------------

Quindi secondo me, a tutto questo, bisogna anche considerare se BD faccia ancora 3 mops a ciclo o passi a 4, bisogna vedere le latenze per ogni istruzione. Questo era il quadro precedente:



Come si cambiano le latenze io non ne ho la minima idea, ma credo che dagli schemi visti sino ad ora, nessuno può dire se siano le stesse. Comunque una L2 di 2MB condivisa nel modulo, di per sé sarebbe un bel magazzino dati, se poi fosse addirittura più aggressiva.
Poi mi viene il dubbio... con una L2 così grossa, il core è così piccolo? cacchio, comunque da 512KB+512KB di 2 core K10...

---------------------------------------------

Alla fine della minestra, entra in funzione la frequenza. Ormai dovunque attribuiscono a BD notevoli incrementi di clock.

Anche considerando un IPC inferiore nel totale, se prendiamo un Thuban 3,2Ghz stock e pensiamo ad un BD a 4GHz, saremmo sull'ordine del + 30% solo nel clock, aggiungiamoci un 33% nel numero dei core, arriveremmo a +72%. Vogliamo toglierci un 10% per minor IPC? saremmo ad un +65% ma con un procio più bilanciato nel discorso INT verso Intel e più potente di prima nell'FP.

Nel discorso monocore le cose sarebbero MOLTO migliori.
Perché il modulo di BD avrebbe l'SMT HARDWARE, quindi DOVREBBE incrementare l'IPC e non di poco rispetto al singolo core K10.
Uniscici clock sicuramente superiori di almeno 500MHz rispetto a quelli di SB... e lo scenario è fatto.

P.S.
Io non mi intendo di SMT, però vedo nel TH di Cinebench, che i proci senza SMT hanno risultati inferiore a parità di frequenza con gli i7 con SMT pure nel monocore, quindi ho teorizzato che possa aiutare pure nel monocore... e poi comunque bisogna vedere se nel modulo BD possa comunque esserci qualche miglioria.

[checo]

Originariamente inviato da JDM70

Secondo me il punto è nel capire se AMD intenderà un quad core con 2 Moduli o... 4 Moduli, io rimango dell'idea che userà 4 Moduli poi Imho!!!

guarda che amd ha detto chiaramente che intende come core l'unità int quindi quad core 2 moduli.

alla fine son solo nomi

[Pihippo]

Originariamente inviato da cionci

Ogni macro-op è una istruzione ALU/AGU/FPU + una LOAD/STORE, quindi per poter completare 8 macro-ops bisogna essere in grado di completare 8 L/S per ciclo di clock.

Ciao
Non per forza, le macrop vengono nel k10 splittate nelle microop corrispettive(ad es macro op 1= add r.r1+store) nelle primitive micro ops (in questo caso add + load eseguite in 2 pipe diverse in modo OoO). Il retirement buffer ritira le micro ops. Scusami erroneamente ho scritto nel post precedente macro ops, negli issue slot delle alu\agu esse vengono splittate nelle micro ops, ho causato un pò di confusione
Quindi sempre prendendo per buono le minchiate che ho scritto si tretterebbe, visto che ancora dei dettagli importanti non se ne sa nulla di 4 microops ritirate per core in bd vs le 3 (magari) del k10

[bjt2]

Originariamente inviato da Pihippo

Ciao
Sono contento che concordi, vuol dire che non ho psarato una minchiata.
BJt2 vorrei porti all'attenzione una cosa fondamentale sul discorso 3alu+3agu vs 2alu+2agu per quanto riguarda l'ipc k10vsBulldozer:
Fonte : http://www.agner.org/optimize/microarchitecture.pdf
Pag. 140:
The execution units have a much larger capacity than it is possible to utilize. It is alleged
that the nine execution units can execute nine micro-operations simultaneously, but it is
virtually impossible to verify this claim experimentally since the retirement is limited to three
macro-operations per clock cycle
Ovvero sebbene il core k10 possa fare 3 op aritmetico logiche+3op di memoria, il retirement buffer è limitato a solo 3 op per ciclo( in qualsiasi combinazione), quindi vorrebbe dire che se il retirement buffer di bd consentisse il ritiro di 4 op, bd avrebbe un vantaggio teorico del 33% sul k10.
Che ne pensi?

Esatto. E poi le 3+3 operazioni del K10 sono sempre accoppiate, ossia se una istruzione non ha l'accesso in memoria (è reg-reg) quella AGU non è utilizzata. Invece in Buldozer non esistono più macro ops e si torna alle micro ops, dove se una istruzione è reg-reg non consuma comunque una AGU. Inoltre ne K10 era possibile fare o una moltiplicazione o una divisione. Invece qui le due pipeline intere consentono di farle contemporaneamente. Questo vuol dire che una divisione (che può durare anche 40 cicli, anche se si spera che qui si sia usato un divisore migliore) non blocca le successive moltiplicazioni indipendenti...

[cionci]

Originariamente inviato da paolo.oliva2

Anche considerando un IPC inferiore nel totale, se prendiamo un Thuban 3,2Ghz stock e pensiamo ad un BD a 4GHz, saremmo sull'ordine del + 30% solo nel clock, aggiungiamoci un 33% nel numero dei core, arriveremmo a +72%. Vogliamo toglierci un 10% per minor IPC? saremmo ad un +65% ma con un procio più bilanciato nel discorso INT verso Intel e più potente di prima nell'FP.

Non ho capito il passaggio evidenziato. Intendi ad un 33% dovuto al fatto di avere 4 moduli BD con 8 core logici contro i 6 core fisici del Thuban ?
Devi considerare anche il cambio di processo produttivo. Un Thuban a 32 nm girerebbe sicuramente almeno 400 Mhz più veloce con il semplice die-shrink.
Il discorso può andare bene dal punto di vista degli interi, ma sulla FPU non vedo possibile un aumento così marcato. Soprattutto se si considerano situazioni in cui i due thread dello stesso modulo eseguono entrambi istruzioni FP.

[bjt2]

Originariamente inviato da cionci

Non ho capito il passaggio evidenziato. Intendi ad un 33% dovuto al fatto di avere 4 moduli BD con 8 core logici contro i 6 core fisici del Thuban ?
Devi considerare anche il cambio di processo produttivo. Un Thuban a 32 nm girerebbe sicuramente almeno 400 Mhz più veloce con il semplice die-shrink.
Il discorso può andare bene dal punto di vista degli interi, ma sulla FPU non vedo possibile un aumento così marcato. Soprattutto se si considerano situazioni in cui i due thread dello stesso modulo eseguono entrambi istruzioni FP.

Se la FPU del Bulldozer può spezzare l'FMAC in 1 MUL + 1 ADD indipendenti per ciclo, la potenza è doppia, ma condivisa tra due thread, rispetto a quella del K10. Anzi, più che doppia, visto che le unità chiamate MMX si occupano dei calcoli legacy x87 e che le operazioni di memoria sono state appioppate all'unità intera.

I motivi di questa "speranza" sono molteplici: esistenza di un brevetto AMD che descrive la possibile scissione di una FMAC per fare ADD e MUL in parallelo, la inutilità di una FMAC, considerando che INTEL non ce l'ha, il codice compilato con compilatore INTEL e il codice legacy non avrà FMAC e che le XOP (che sfruttano le FMAC) non credo saranno supportate estensivamente e comunque non subito.

[Pihippo]

Originariamente inviato da bjt2

Esatto. E poi le 3+3 operazioni del K10 sono sempre accoppiate, ossia se una istruzione non ha l'accesso in memoria (è reg-reg) quella AGU non è utilizzata. Invece in Buldozer non esistono più macro ops e si torna alle micro ops, dove se una istruzione è reg-reg non consuma comunque una AGU. Inoltre ne K10 era possibile fare o una moltiplicazione o una divisione. Invece qui le due pipeline intere consentono di farle contemporaneamente. Questo vuol dire che una divisione (che può durare anche 40 cicli, anche se si spera che qui si sia usato un divisore migliore) non blocca le successive moltiplicazioni indipendenti...

Ciao bjt2
Grazie per l'intervento, in pratica bd pur con un numero minore di ex unit sarebbe più efficiente del k10 nell'esecuzione di calcoli. Un altre cosa, anche intel splitta le macro op in micro op cosi da avere più flessibilità ed efficienza?

[Ren]

Se la FPU del Bulldozer possa spezzare l'FMAC in 1 MUL + 1 ADD indipendenti per ciclo, la potenza è doppia, ma condivisa tra due thread, rispetto a quella del K10. Anzi, più che doppia, visto che le unità chiamate MMX si occupano dei calcoli legacy x87 e che le operazioni di memoria sono state appioppate all'unità intera.

I motivi di questa "speranza" sono molteplici: esistenza di un brevetto AMD che descrive la possibile scissione di una FMAC per fare ADD e MUL in parallelo, la inutilità di una FMAC, considerando che INTEL non ce l'ha, il codice compilato con compilatore INTEL e il codice legacy non avrà FMAC e che le XOP (che sfruttano le FMAC) non credo saranno supportate estensivamente e comunque non subito.

Quindi secondo te fonderanno le istruzioni di due thread per occupare al massimo una singola FMA, riducendo così anche la pressione sulla operazioni di memoria.

Mi viene spontaneo chiedere se i due thread basteranno ad occupare le due FMAC...

Secondo te le legacy si occuperanno dei calcoli fp non vettoriali (x87) o si limiteranno alle istruzioni intere previste dalle estensioni medesime ?

[paolo.oliva2]

Originariamente inviato da cionci

Non ho capito il passaggio evidenziato. Intendi ad un 33% dovuto al fatto di avere 4 moduli BD con 8 core logici contro i 6 core fisici del Thuban ?

Perché logici? BD ha 4 moduli con 2 core ciascuno... con delle parti in comune, ma sono sempre fisici.