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

[paolo.oliva2]

Originariamente inviato da cionci

Ma sicuramente non fa il successo sul mercato di una intera famiglia di processori.
Intel non supera a 32 nm un AMD a 45 nm, vero, ma perché l'architettura è più efficiente. Ribadisco questo concetto.
Ecco perché secondo me i record di overclock stabiliti solo in frequenza, senza guardare le prestazioni sono assurdi.

Vero.
Però pensa un BD X8 che si occa più di un SB X4... le prestazioni ci sarebbero e alla grande.
Conta che buona parte del "successo" commerciale di AMD, è legato alla politica di vendita dei B.E., a tal punto, che ha obbligato la stessa Intel a immettere il molti libero, riservato precedentemente solo alla classe EE con i tipici prezzi da EE, anche alla serie K.
Il B.E. di sè per sè ha unito l'overclock, con il portafoglio, cioè offrire un procio sbloccato da poter overcloccare a piacere ottenendo prestazioni che altrimenti sarebbero state ben più costose.
Spero solo che AMD non reintroduca gli FX, perché se un BD X8 verrà commercializzato come B.E. e al prezzo di 400€, rappresenterebbe lo stato dell'arte in fatto prezzo/prestazioni.

[cionci]

Originariamente inviato da Pihippo

Ciao
Guarda che bd ha anche delle unità simd int non condivise.. che eseguono anche mmx e robette varie. http://www.realworldtech.com/include...ulldozer-5.png
Certo se poi si prendono in esempio solo codici fp, l'utilità della fp flex si va a farsi benedire, però anche nelle più grandi moltipiplicazioni di matrici, un buon 40% di istruzioni son di controllo, inoltre a parità di thread con sb, beh sempre la solita solfa cores vs fake cores.

I calcoli matriciali non vengono implementati tramite codice FP legacy, ma tramite istruzioni SIMD.
Edit: se i calcoli matriciali avvengono tramite una libreria ottimizzata con istruzioni SIMD, il codice di controllo può essere anche zero: visto che si fa loop unrolling e si traducono, ad esempio, le moltiplicazioni o le somme delle varie righe in una o più istruzioni SIMD

[capitan_crasy]

Originariamente inviato da bjt2

Ma devi considerare che, se vogliamo compararlo al K10, nel BD essendo le unità uguali, non c'è possibilità di conflitto. Invece nel K10 c'è una pipe che può fare solo ADD e una che può fare MUL e ADD. Lo scheduler assegna alla cieca una FADD una volta alla pipe FADD e una volta alla FMUL. Se al ciclo precedente aveva assegnato una FDIV alla pipe FMUL, che NON è pipelined, la FADD salta un ciclo anche se l'altra pipe è libera... E siccome la FDIV si protrae per svariati cicli, un ciclo si e uno no una FADD viene ritardata (oltre a congelarsi tutte le FMUL e FDIV in coda...) e per quel lasso di tempo il throughput dell'addizione si dimezza. Inoltre ogni programma, anche il più intensivo in FP, ha istruzioni intere, salti, confronti e comunque accesso alla memoria. L'accesso alla memoria, anche delle istruzioni FP, è gestito dal relativo core intero. Lo svantaggio che dici tu si potrebbe avere solo con codice FP con bassa densità di accessi alla memoria (calcoli complicati che richiedono molti passaggi per ogni dato, come ad esempio una serie di Taylor per exp, sin, cos ecc...)

EDIT: Ovviamente rispetto a SB, a parità di thread non c'è storia, e a parità di core, a causa delle porte condivise in SB, se la gioca... Quello che manca nel K10 non è la potenza di picco, che è superiore a INTEL, ma uno scheduler efficiente sia per l'INT (con le MOPS bloccate e appaiate) che per l'FP (lo scheduler scemo che ti ho descritto sopra, che assieme a quello INT fanno la coppia Scemo+Scemo vista al cinema... )... BD dovrebbe risolvere anche questi problemi...

[cionci]

Originariamente inviato da paolo.oliva2

Conta che buona parte del "successo" commerciale di AMD, è legato alla politica di vendita dei B.E., a tal punto, che ha obbligato la stessa Intel a immettere il molti libero, riservato precedentemente solo alla classe EE con i tipici prezzi da EE, anche alla serie K.

Dubito davvero. Tant'è che SB sarà overclockabile solo tramite moltiplicatore (esclusa la versione TOP). Allora prima l'overclock è importante e dopo no ? Sarebbe una contraddizione.

[bjt2]

Originariamente inviato da cionci

Chiaro che mi riferisco solo a calcoli FP intensivi. Non sono nemmeno troppo rari, ad esempio qualsiasi calcolo in forma matriciale necessita di molteplici istruzioni SIMD sugli stessi dati.

Edit: è proprio nel calcolo matriciale che si fa uso del multithreading per distribuire i calcoli fra più thread. Ed è quindi proprio il caso in cui molti thread si troverebbero ad eseguire contemporaneamente istruzioni SIMD.

Matlab non parallelizza su più thread per calcoli Memory bound come moltiplicazioni o addizioni tra elementi. Solo con calcoli CPU bound come exp(matrice) ecc...

Fare il prodotto scalare ad esempio è memory bound...

[bjt2]

Originariamente inviato da cionci

Ma sicuramente non fa il successo sul mercato di una intera famiglia di processori.
Intel non supera a 32 nm un AMD a 45 nm, vero, ma perché l'architettura è più efficiente. Ribadisco questo concetto.
Ecco perché secondo me i record di overclock stabiliti solo in frequenza, senza guardare le prestazioni sono assurdi.

Veramente il FO4 AMD è 22-23 e il FO4 INTEL è 17-18... Il problema di INTEL è il processo produttivo, non perchè l'architettura è più efficiente... IBM, con lo STESSO processo AMD a 45nm e una architettura a FO4 17 (il Power 7) e quindi paragonabile al Nehalem (anzi, c'è pure una L3 da 32MB, contro gli 8, 12 uops massime per ciclo, contro le 6 e un SMT a 4 thread per core, contro HT che ne ha 2 thread per core, quindi un quad core a 16 thread...), arriva a 4.25 GHz stock...

[cionci]

Originariamente inviato da bjt2

Matlab non parallelizza su più thread per calcoli Memory bound come moltiplicazioni o addizioni tra elementi. Solo con calcoli CPU bound come exp(matrice) ecc...

Non ho parlato infatti di Matlab, che di fatto è lentissimo rispetto ad altre librerie, come le Intel MKL o Bullet SDK. In ogni caso la parallelizzazione può essere fatta anche tramite le librerie OpenMP.

[bjt2]

Originariamente inviato da Pihippo

Ciao
Guarda che bd ha anche delle unità simd int non condivise.. che eseguono anche mmx e robette varie. http://www.realworldtech.com/include...ulldozer-5.png
Certo se poi si prendono in esempio solo codici fp, l'utilità della fp flex si va a farsi benedire, però anche nelle più grandi moltipiplicazioni di matrici, un buon 40% di istruzioni son di controllo, inoltre a parità di thread con sb, beh sempre la solita solfa cores vs fake cores.

Questo è un altro aspetto... INTEL può fare 3 operazioni SIMD/MMX/FP in competizione con gli interi e memoria. BD può fare 2 INT, 2 memoria, 2 FP/SIMD e 2 SIMD/MMX per ciclo...

[bjt2]

Originariamente inviato da capitan_crasy

Mi è venuta naturale la battuta...

[cionci]

Originariamente inviato da bjt2

Veramente il FO4 AMD è 22-23 e il FO4 INTEL è 17-18...

Non è FO4 (che è un metrica del critical path) l'unico parametro che non permette di salire più di una certa frequenza. Conta anche la dimensione del circuito, la disposizione e la temperatura raggiunta negli hot-spot. Inoltre conta anche il critical path degli altri elementi che ci sono intorno alla CPU...ad esempio il memory controller.
Una CPU può avere anche FO4 23 e salire meno in frequenza di un Nehalem. Magari io studio il memory controller in modo da avere un'alta efficienza, ma una possibilità limitata di salire in frequenza. Limitata, ma sempre superiori alle frequenze di default che la mia CPU dovrebbe raggiungere.
Inoltre ci possono essere altre limitazioni esterne, come ad esempio limiti dovuti al generatore di clock o alle specifiche di alimentazione imposte dal produttore della CPU.
Usare FO4 come solo parametro (che tra l'altro non è un parametro di efficienza) è molto riduttivo.

[bjt2]

Originariamente inviato da cionci

Non è FO4 (che è un metrica del critical path) l'unico parametro che non permette di salire più di una certa frequenza. Conta anche la dimensione del circuito, la disposizione e la temperatura raggiunta negli hot-spot. Inoltre conta anche il critical path degli altri elementi che ci sono intorno alla CPU...ad esempio il memory controller.
Una CPU può avere anche FO4 23 e salire meno in frequenza di un Nehalem. Magari io studio il memory controller in modo da avere un'alta efficienza, ma una possibilità limitata di salire in frequenza. Limitata, ma sempre superiori alle frequenze di default che la mia CPU dovrebbe raggiungere.
Inoltre ci possono essere altre limitazioni esterne, come ad esempio limiti dovuti al generatore di clock o alle specifiche di alimentazione imposte dal produttore della CPU.
Usare FO4 come solo parametro (che tra l'altro non è un parametro di efficienza) è molto riduttivo.

Forse intendevi una CPU con FO4 17... Che una CPU con FO4 23 salga meno del Nehalem lo avevo affermato anche io...
E comunque il MC nelle architetture moderne sta su un clock separato dal core, quindi non vedo il problema...

Ovviamente sono daccordo che il FO4 non dice tutta la storia...

Nel caso del Power 7, però, converrai con me che è più efficiente del Nehalem, almeno in multithreading, eppure arriva a 4.25 GHz con il 45nm AMD...

[Pihippo]

Originariamente inviato da cionci

I calcoli matriciali non vengono implementati tramite codice FP legacy, ma tramite istruzioni SIMD.
Edit: se i calcoli matriciali avvengono tramite una libreria ottimizzata con istruzioni SIMD, il codice di controllo può essere anche zero: visto che si fa loop unrolling e si traducono, ad esempio, le moltiplicazioni o le somme delle varie righe in una o più istruzioni SIMD

Ciao
Precisiamo però una cosa, anche se utilizzi una libreria particolare come blas, lapack ecc ecc
il codice intero vi sarà "sempre" anche in minima parte, con codice intero non intendo solo operazioni logico\aritmetiche, ma anche operazioni di memoria come lea (ad esempio se hai costanti immediate te le carichi e te le salvi sui registri, xor per il clear dei registri, ma anche nella manipolazione delle matrici, come ad esempio contare le colonne delle delle matrici...

[paolo.oliva2]

Originariamente inviato da bjt2

Veramente il FO4 AMD è 22-23 e il FO4 INTEL è 17-18... Il problema di INTEL è il processo produttivo, non perchè l'architettura è più efficiente... IBM, con lo STESSO processo AMD a 45nm e una architettura a FO4 17 (il Power 7) e quindi paragonabile al Nehalem (anzi, c'è pure una L3 da 32MB, contro gli 8, 12 uops massime per ciclo, contro le 6 e un SMT a 4 thread per core, contro HT che ne ha 2 thread per core, quindi un quad core a 16 thread...), arriva a 4.25 GHz stock...

Quoto.
Il ragionamento sarebbe reale se, ipoteticamente, tralasciando le caratteristiche dell'architettura, si raggiungesse un TDP/Potenza simile.
Nel senso... esempio: SB +5% di IPC/-5% di clock = BD -5% di IPC/+ 5% di clock = stesso TDP = stessa potenza.
Ma valutando BD per -5% di IPC e + 30% di clock, il discorso non è più valido perché la potenza risultante sarebbe superiore allo stesso TDP.
Questo di per sé esplicita più che evidentemente che a parità di silicio e di trattamenti, sicuramente il Bulk Intel non sia tra i migliori.

Poi SB... risolverà il problema degli i7 in cui oltre i 4GHz l'IPC cala?

[Ren]

Veramente il FO4 AMD è 22-23 e il FO4 INTEL è 17-18... Il problema di INTEL è il processo produttivo, non perchè l'architettura è più efficiente... IBM, con lo STESSO processo AMD a 45nm e una architettura a FO4 17 (il Power 7) e quindi paragonabile al Nehalem (anzi, c'è pure una L3 da 32MB, contro gli 8, 12 uops massime per ciclo, contro le 6 e un SMT a 4 thread per core, contro HT che ne ha 2 thread per core, quindi un quad core a 16 thread...), arriva a 4.25 GHz stock...

Il problema è che non conosciamo il TDP dei Power7, quindi non sappiamo se una frequenza così elevata sia efficientemente domata dal processo produttivo...

[Pihippo]

Originariamente inviato da Ren

Il problema è che non conosciamo il TDP dei Power7, quindi non sappiamo se una frequenza così elevata sia efficientemente domata dal processo produttivo...

Ciao
Vero, di solito te lo vendono con mb predisposta per il raffred a liquido, quindi penso che abbia un tdp >150w perr cpu.

[Ren]

Questo di per sé esplicita più che evidentemente che a parità di silicio e di trattamenti, sicuramente il Bulk Intel non sia tra i migliori.

Poi SB... risolverà il problema degli i7 in cui oltre i 4GHz l'IPC cala?

L'IPC cala perchè non prevedono di oltrepassare quella soglia di frequenza per una questione di efficienza dei consumi.

Il processo di intel non è un bulk, ma uno strained-silicon con low-k CDO.

[cionci]

Originariamente inviato da bjt2

Forse intendevi una CPU con FO4 17... Che una CPU con FO4 23 salga meno del Nehalem lo avevo affermato anche io...

Sì, sorry.

Originariamente inviato da bjt2

E comunque il MC nelle architetture moderne sta su un clock separato dal core, quindi non vedo il problema...

Vero, per il K10, ma sei sicuro che lo sia anche per Nehalem ?

Originariamente inviato da bjt2

Nel caso del Power 7, però, converrai con me che è più efficiente del Nehalem, almeno in multithreading, eppure arriva a 4.25 GHz con il 45nm AMD...

Anche qui parliamo di cose completamente diverse. Consideriamo che sia Intel che AMD si portano dietro il pesante fardello del decoding delle istruzioni x86 a lunghezza variaibile, con le fasi di fetch e decode che occupano anche un terzo dell'area occupata dalla CPU stessa (L2 e L3 escluse).
Certo anche l'istruction set Power è cresciuto enormemente, ma la differenza principale è che se per x86 il parco software usato è talmente ampio da rendere necessarie ottime prestazioni con moltissime istruzioni, per Power sono i progettisti stessi a dare le guideline sulle istruzioni da utilizzare e sulla realizzazione dei compilatori. Al contrario su x86 è il parco software a guidare i progettisti nelle scelte architetturali.
In sostanza nelle CPU Power, volta volta, si possono fare scelte molto meno conservative rispetto a quelle che si possono fare su x86 perché di fatto il 95% del parco software verrà ricompilato o creato appositamente per quella versione di Power.

[cionci]

Originariamente inviato da Pihippo

Ciao
Precisiamo però una cosa, anche se utilizzi una libreria particolare come blas, lapack ecc ecc
il codice intero vi sarà "sempre" anche in minima parte, con codice intero non intendo solo operazioni logico\aritmetiche, ma anche operazioni di memoria come lea (ad esempio se hai costanti immediate te le carichi e te le salvi sui registri, xor per il clear dei registri, ma anche nella manipolazione delle matrici, come ad esempio contare le colonne delle delle matrici...

Certo, ma solitamente il codice è eseguito prima della parallelizzazione Con questo non dico che non ci possa essere, ma con il loop unrolling già grandissima parte del codice intero in un calcolo matriciale sarà tolto, ma non solo, l'avanzamento dei thread sarà anche quasi speculare, quindi con molta probabilità si troveranno ad operare contemporaneamente sulla FPU.

Originariamente inviato da paolo.oliva2

Nel senso... esempio: SB +5% di IPC/-5% di clock = BD -5% di IPC/+ 5% di clock = stesso TDP = stessa potenza.

????

Originariamente inviato da paolo.oliva2

Questo di per sé esplicita più che evidentemente che a parità di silicio e di trattamenti, sicuramente il Bulk Intel non sia tra i migliori.

Assolutamente no, non abbiamo assolutamente i mezzi tecnici per fare un confronto di questo tipo.

[cionci]

Originariamente inviato da Ren

Il processo di intel non è un bulk, ma uno strained-silicon con low-k CDO.

In effetti lo strained silicon lo usano dai 90 nm, mentre il low-k CDO ho letto che lo usano dai 45 nm.

[bjt2]

Originariamente inviato da Ren

Il problema è che non conosciamo il TDP dei Power7, quindi non sappiamo se una frequenza così elevata sia efficientemente domata dal processo produttivo...

Hai ragione... il TDP è 200W... Però è un chip a 16 thread a 4.25 GHz con 32 MB di L3... Non mi sembra male...