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

[capitan_crasy]

AMD rileva il nome ufficiale della sua unità floating point condivisa da due core presente in Bulldozer:

One of the most interesting features planned for our next generation core architecture, which features the new “Bulldozer” core, is something called the “Flex FP”, which delivers tremendous floating point capabilities for technical and financial applications.

For those of you not familiar with floating point math, this is the high level stuff, not 1+1 integer math that most applications use. Technical applications and financial applications that rely on heavy-duty use of floating point math could see huge increases in performance over our existing architectures, as well as far more flexibility.

The heart of this new feature is a flexible floating point unit called the Flex FP. This is a single floating point unit that is shared between two integer cores in a module (so a 16-core “Interlagos” would have 8 Flex FP units). Each Flex FP has its own scheduler; it does not rely on the integer scheduler to schedule FP commands, nor does it take integer resources to schedule 256-bit executions. This helps to ensure that the FP unit stays full as floating point commands occur. Our competitors’ architectures have had single scheduler for both integer and floating point, which means that both integer and floating point commands are issued by a single shared scheduler vs. having dedicated schedulers for both integer and floating point executions.

There will be some instruction set extensions that include SSSE3, SSE 4.1 and 4.2, AVX, AES, FMA4, XOP, PCLMULQDQ and others.

One of these new instruction set extensions, AVX, can handle 256-bit FP executions. Now, let’s be clear, there is no such thing as a 256-bit command. Single precision commands are 32-bit and double precision are 64-bit. With today’s standard 128-bit FPUs, you execute four single precision commands or two double precision commands in parallel per cycle. With AVX you can double that, executing eight 32-bit commands or four 64-bit commands per cycle – but only if your application supports AVX. If it doesn’t support AVX, then that flashy new 256-bit FPU only executes in 128-bit mode (half the throughput). That is, unless you have a Flex FP.

In today’s typical data center workloads, the bulk of the processing is integer and a smaller portion is floating point. So, in most cases you don’t want one massive 256-bit floating point unit per core consuming all of that die space and all of that power just to sit around watching the integer cores do all of the heavy lifting. By sharing one 256-bit floating point unit per every 2 cores, we can keep die size and power consumption down, helping hold down both the acquisition cost and long-term management costs.

The Flex FP unit is built on two 128-bit FMAC units. The FMAC building blocks are quite robust on their own. Each FMAC can do an FMAC, FADD or a FMUL per cycle. When you compare that competitive solutions that can only do an FADD on their single FADD pipe or an FMUL on their single FMUL pipe, you start to see the power of the Flex FP – whether 128-bit or 256-bit, there is flexibility for your technical applications. With FMAC, the multiplication or addition commands don’t start to stack up like a standard FMUL or FADD; there is flexibility to handle either math on either unit. Here are some additional benefits:

* Non-destructive DEST via FMA4 support (which helps reduce register pressure)
* Higher accuracy (via elimination of intermediate round step)
* Can accommodate FMUL OR FADD ops (if an app is FADD limited, then both FMACs can do FADDs, etc), which is a huge benefit

The new AES instructions allow hardware to accelerate the large base of applications that use this type of standard encryption (FIPS 197). The “Bulldozer” Flex FP is able to execute these instructions, which operate on 16 Bytes at a time, at a rate of 1 per cycle, which provides 2X more bandwidth than current offerings.

By having a shared Flex FP the power budget for the processor is held down. This allows us to add more integer cores into the same power budget. By sharing FP resources (that are often idle in any given cycle) we can add more integer execution resources (which are more often busy with commands waiting in line). In fact, the Flex FP is designed to reduce its active idle power consumption to a mere 2% of its peak power consumption.

The Flex FP gives you the best of both worlds: performance where you need it yet smart enough to save power when you don’t need it.

The beauty of the Flex FP is that it is a single 256-bit FPU that is shared by two integer cores. With each cycle, either core can operate on 256 bits of parallel data via two 128-bit instructions or one 256-bit instruction, OR each of the integer cores can execute 128-bit commands simultaneously. This is not something hard coded in the BIOS or in the application; it can change with each processor cycle to meet the needs at that moment. When you consider that most of the time servers are executing integer commands, this means that if a set of FP commands need to be dispatched, there is probably a high likelihood that only one core needs to do this, so it has all 256-bit to schedule.

Floating point operations typically have longer latencies so their utilization is typically much lower; two threads are able to easily interleave with minimal performance impact. So the idea of sharing doesn’t necessarily present a dramatic trade-off because of the types of operations being handled.

Here are the 4 likely scenarios for each cycle:



As you can see, the flexibility of the FPU really gives total flexibility to the system, designed to deliver optimized performance per core per cycle.

Also, each of our pipes can seamlessly handle SSE or AVX as well as FMUL, FADD, or FMAC providing the greatest flexibility for any given application. Existing apps will be able to take full advantage of our hardware with potential for improvement by leveraging the new ISAs.

Obviously, there are benefits of recompiled code that will support the new AVX instructions. But, if you think that you will have some older 128-bit FP code hanging around (and let’s face it, you will), then don’t you think having a flexible floating point solution is a more flexible choice for your applications? For applications to support the new 256-bit AVX capabilities they will need to be recompiled; this takes time and testing, so I wouldn’t expect to see rapid movement to AVX until well after platforms are available on the streets. That means in the meantime, as we all work through this transition, having flexibility is a good thing. Which is why we designed the Flex FP the way that we have.

If you have gotten this far, you are probably thinking that the technical discussion might be a bit beyond a guy with a degree in economics. I’d like to take a moment to thank Jay Fleischman and Kevin Hurd, two geniuses who really understand how all of these pieces fit together to make the Flex FP really unique in the industry.

"Flex FP è un'unità floating point condivisa tra i due core integer di un modulo (quindi un processore Interlagos a 16 core dovrebbe avere 8 unità Flex FP). Ogni unità Flex FP ha il proprio scheduler e non conta sull'interger scheduler per programmare i comandi in virgola mobile, né usa risorse integer per programmare esecuzioni a 256 bit. Questo aiuta ad assicurarci che l'unità FP rimanga sempre occupata quando vengono richiesti calcoli in virgola mobile. Le architetture del nostro avversario (Intel, Sandy Bridge) hanno un singolo scheduler sia per i calcoli integer che in virgola mobile. Tutto è gestito da un singolo scheduler condiviso.

Le istruzioni AVX possono amministrare calcoli in virgola mobile a 256 bit.
I comandi a singola precisione sono a 32 bit e, se in doppia precisione, a 64 bit. Con le unità FPU a 128 bit diffuse oggi potete eseguire quattro comandi a singola precisione o due comandi in doppia precisione in parallelo per ciclo. Con AXV potete raddoppiare tutto questo, eseguendo otto comandi a 32 bit o quattro comandi a 64 bit per ciclo - ma solo se l'applicazione supporta AVX. Se non lo supporta la nuova FPU a 256 bit lavorerà a 128 bit. Questo a meno che non abbiate Flex FP.

L'unità FlexFP è basata su due unità FMAC a 128 bit. Ogni FMAC può eseguire istruzioni FMAC, FADD o una FMUL per ciclo. Le soluzioni della concorrenza possono eseguire solo una FADD sulla loro singola pipeline FADD o una FMUL sulla loro singola pipeline FMUD. Potete capire la potenza di Flex FP che assicura sia a 128 che 256 bit flessibilità per le applicazioni tecniche. Con FMAC i comandi di moltiplicazione e addizione non iniziano ad accumularsi.

Con il carico di lavoro tipo dei data center odierni, la maggior parte del lavoro di calcolo è integer e solo una piccola porzione è in virgola mobile. Quindi in molti casi non c'è bisogno di avere una grande unità FP a 256 bit che occupi tutto lo spazio sul die e consumi molta energia. Condividendo una singola unità FP a 256 bit per ciascuno dei due core, possiamo contenere consumi e le dimensione del die, aiutando a mantenere bassi sia i costi di acquisizione che quelli di amministrazione a lungo termine

Ci sono ovviamente dei benefici nel ricompilare il codice per supportare le nuove istruzioni AVX. Se pensate però che avremo del vecchio codice 128-bit FP in giro per diverso tempo, non credete che avere un'unità in virgola mobile flessibile sia una scelta migliore per le applicazioni? Il supporto da parte del software alle funzionalità a 256-bit AVX richiederà una ricompilazione e cioè tempo e test. Non mi aspetto di vedere un rapido passaggio ad AVX"

Clicca qui...

[WarSide]

AMD datti una mossa a lanciare questo dannato BD

[affiu]

Originariamente inviato da WarSide

AMD datti una mossa a lanciare questo dannato BD

perchè tutto cosi veloce?per il momento si attende fusion bobcat che farà vedere di che pasta è fatta apu ,e magari pure con dissipatore passivo!di quello appositamente studiato ,appunto per chi vuole un portatile che sembra spento con zero rumori/zero ventole/tutta potenza

cmq 75 giorni al debutto

[jok3r87]

Originariamente inviato da capitan_crasy

AMD rileva il nome ufficiale della sua unità floating point condivisa da due core presente in Bulldozer:



Clicca qui...

Ma tra due core intesi come quattro moduli (quattro int) o due core intesi come un modulo (due int) ?

[paolo.oliva2]

...which delivers tremendous floating point capabilities for technical and financial applications...
...floating point math could see huge increases in performance over our existing architectures, as well as far more flexibility...

C'è una cosa che non ho capito...
...Se si considera che il più delle volte nei server sono in esecuzione i comandi interi, questo significa che se una serie di comandi FP devono essere spediti, probabilmente vi è un'alta probabilità che un solo core ha bisogno di fare questo, quindi ha tutti a 256-bit il calendario previsto...
Viene considerato all'interno del modulo... oppure c'è uno scambio da L3 a modulo/core libero? Forse ho detto una cavolata...

Beh, comunque tutti i discorsi se un modulo possa gestire al meglio un TH... leggendo come viene schedulata la FP, a me sembra che sia stato centrato in pieno con quei discorsi.

Secondo me l'IPC di BD è stato NETTAMENTE sottovalutato fino ad ora... sto procio ostia se pompa... immaginatevi che procetto sarebbe un X8 a 4GHz def.... la scimmia è già ai massimi livelli... mi vesto da Diabolik e faccio un'incursione a Dresda...

[paolo.oliva2]

Originariamente inviato da jok3r87

Ma tra due core intesi come quattro moduli (quattro int) o due core intesi come un modulo (due int) ?

Che io sappia, a 1 INT corrisponde un core, quindi un modulo = 2 INT

[cionci]

Originariamente inviato da paolo.oliva2

Ma la differenza più consistente verrà con i proci in OC.

Devi capire che l'OC non interessa a "nessuno". Definisco "nessuno" come il 90% del mercato di questi processori.

[Pihippo]

Originariamente inviato da capitan_crasy

AMD rileva il nome ufficiale della sua unità floating point condivisa da due core presente in Bulldozer:



Clicca qui...

Ciao
Ottimo
L'unica cosa che limita sta fp mostruosa è dunque la load bw, che comunque porvenendo da 2 L\S unit(dei core int) dovrebbe essere piu alta di sb.
Mi sa che in bd il vero incremento non srà tanto in int, quanto in fp, deduco quindi che è essenzialmente un chip per server, e la a mia modesta opinione farà molto bene, speriamo lo faccia anche in ambiente client.

[cionci]

Giusto per fare chiarezza: nella descrizione dell'unità FP vista sopra per FMAC si intendono queste istruzioni, che eseguono sì una moltiplicazione ed una somma contemporaneamente, ma il processore non può accorpate FADD e FMUL in una FMAC.
Per avere il supporto ad FMA3 e FMA4 c'è bisogno di una ricompilazione.

paolo.oliva2: i comandi non vengono spediti, le operazioni FP si trovano mescolate con quelli intere. Semplicemente, quando una istruzione FP viene decodificata, le istruzioni vengono portate avanti sulla pipeline FP invece che su quella intera.

[Pihippo]

Originariamente inviato da cionci

Giusto per fare chiarezza: nella descrizione dell'unità FP vista sopra per FMAC si intendono queste istruzioni, che eseguono sì una moltiplicazione ed una somma contemporaneamente, ma il processore non può accorpate FADD e FMUL in una FMAC.
Per avere il supporto ad FMA3 e FMA4 c'è bisogno di una ricompilazione.

paolo.oliva2: i comandi non vengono spediti, le operazioni FP si trovano mescolate con quelli intere. Semplicemente, quando una istruzione FP viene decodificata, le istruzioni vengono portate avanti sulla pipeline FP invece che su quella intera.

Ciao
Appunto, ed è anche meglio di quello che sb può fare
Ovvero una unità fp di sb può eseguire sia una Fadd che una fmul, ma le porte sono condivise anche per gli int.. Dunque in codice legacy (sse ecc ecc) il peak thorughput di bd è maggiore. Tento di chiarire il pastrocchio che ho scritto prima:
Se abbiamo un thread in fp, ogni modulo è capace di eseguire per unità fp (2 pipe fmac) FADD più fmul contemporaneamente, se vi sono due thread fp, ognua può eseguire o fadd o fmul. Lo stesso caso di un core ht di sb. Ma in sb sia in core con ht on che ht off, in caso di codice mixed (ovvero anche in HPC ci sono istruzioni int, per chiarirci) condivide le porte di esecuzione fp con quelle int per eseguire le simd, quindi incontra un overhead maggiore in quanto non tutte le porte sono completamente disponibili, come la 3 alu del k10, presente ma difficile da usare in parallelo con le altre 2 (overhead e banking conflicts, vi sono solo 2 porte)
Sperando di non aver scritto cazzate

[cionci]

Originariamente inviato da Pihippo

Mi sa che in bd il vero incremento non srà tanto in int, quanto in fp, deduco quindi che è essenzialmente un chip per server, e la a mia modesta opinione farà molto bene, speriamo lo faccia anche in ambiente client.

Prima ogni singolo thread aveva una unità FP dedicata che faceva una FMUL ed una FADD a 128 bit contemporaneamente (si parla sempre di istruzioni SIMD).
Ora su singolo thread sicuramente si possono eseguire contemporaneamente due FMUL a 128 bit o due FADD a 128 bit e questo è un grosso vantaggio. Lo posso quantificare in circa un 20%, forse anche più.
Ma su due thread ? L'unità FP si trova a dover mescolare le istruzioni dei vari thread con il risultato che ogni singolo thread mediamente otterrà solo una singola istruzione a 128 bit in esecuzione contro le massimo due di prima. Credo quindi che l'IPC in questo caso ne risenta, forse di un 10%.
E' chiaro che avere due unità FMAC invece che due unità specializzate sia stata una necessità per far in modo che un thread non venisse bloccato in attesa che l'unità specializzata si liberasse.
Quindi, in sostanza, le prestazioni dipenderanno molto dal tipo di carico: se entrambi i thread eseguono istruzioni SIMD contemporaneamente le prestazioni caleranno, con un thread in FP e l'altro in INT le prestazioni aumenteranno.

[WarSide]

Originariamente inviato da affiu

perchè tutto cosi veloce?per il momento si attende fusion bobcat che farà vedere di che pasta è fatta apu ,e magari pure con dissipatore passivo!di quello appositamente studiato ,appunto per chi vuole un portatile che sembra spento con zero rumori/zero ventole/tutta potenza

cmq 75 giorni al debutto

Quello che a me interessa è llano, per un portatile portabile da 13,3" nella fascia dei 500€ che abbia un bel pò di autonomia, e BD per il futuro cambio delle mie workstation (vedrò poi se prenderne una sola mobo dual socket Opteron-BD o 2 monosocket BD)

[cionci]

Originariamente inviato da Pihippo

Sperando di non aver scritto cazzate

Non le hai scritte, ma io mi riferivo alla discussione secondo cui ogni unità FMAC potesse eseguire una FADD e una FMUL contemporaneamente

[Pihippo]

Originariamente inviato da cionci

Non le hai scritte, ma io mi riferivo alla discussione secondo cui ogni unità FMAC potesse eseguire una FADD e una FMUL contemporaneamente

Ciao
Hai ragione su questo, per il discorso di prima sul fatto che la fp sia condivisa, io non penso che le prestazioni calino anche in conseguenza di 2 thread fp, questo se ovviamente consideriamo un core sb ht, ma anche 2 core k10, poichè ricordiamoci che si il peak throughput può diminuire in questo caso, ma grazie allo scheduler dedicato per le fp ed alle porte non condivise (a differenza di sb) in media dovrebbero essere più alte, non più basse, a meno che il programma non spari 8 thread con elevato tasso di istruzini shuffle. Inoltre in ambito client, con un numero di thread pari a 4 è possibile che (dipende che combina microsoft) ogni thread venga eseguito su un solo modulo di bd (in questo caso bd x8 ovvero 4 moduli) in campo server ve ne saranno 8 di moduli e 16 unità fp contro le 10 di un ipotetico sb 10 core 20 thread.

[bjt2]

Originariamente inviato da cionci

Prima ogni singolo thread aveva una unità FP dedicata che faceva una FMUL ed una FADD a 128 bit contemporaneamente (si parla sempre di istruzioni SIMD).
Ora su singolo thread sicuramente si possono eseguire contemporaneamente due FMUL a 128 bit o due FADD a 128 bit e questo è un grosso vantaggio. Lo posso quantificare in circa un 20%, forse anche più.
Ma su due thread ? L'unità FP si trova a dover mescolare le istruzioni dei vari thread con il risultato che ogni singolo thread mediamente otterrà solo una singola istruzione a 128 bit in esecuzione contro le massimo due di prima. Credo quindi che l'IPC in questo caso ne risenta, forse di un 10%.
E' chiaro che avere due unità FMAC invece che due unità specializzate sia stata una necessità per far in modo che un thread non venisse bloccato in attesa che l'unità specializzata si liberasse.
Quindi, in sostanza, le prestazioni dipenderanno molto dal tipo di carico: se entrambi i thread eseguono istruzioni SIMD contemporaneamente le prestazioni caleranno, con un thread in FP e l'altro in INT le prestazioni aumenteranno.

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 bjt2

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

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.

[paolo.oliva2]

Originariamente inviato da cionci

Prima ogni singolo thread aveva una unità FP dedicata che faceva una FMUL ed una FADD a 128 bit contemporaneamente (si parla sempre di istruzioni SIMD).
Ora su singolo thread sicuramente si possono eseguire contemporaneamente due FMUL a 128 bit o due FADD a 128 bit e questo è un grosso vantaggio. Lo posso quantificare in circa un 20%, forse anche più.
Ma su due thread ? L'unità FP si trova a dover mescolare le istruzioni dei vari thread con il risultato che ogni singolo thread mediamente otterrà solo una singola istruzione a 128 bit in esecuzione contro le massimo due di prima. Credo quindi che l'IPC in questo caso ne risenta, forse di un 10%.
E' chiaro che avere due unità FMAC invece che due unità specializzate sia stata una necessità per far in modo che un thread non venisse bloccato in attesa che l'unità specializzata si liberasse.
Quindi, in sostanza, le prestazioni dipenderanno molto dal tipo di carico: se entrambi i thread eseguono istruzioni SIMD contemporaneamente le prestazioni caleranno, con un thread in FP e l'altro in INT le prestazioni aumenteranno.

Eh eh.
Sarò malizioso... ma secondo me quando ci saranno confronti tra BD e SB, ci sarà un gran lavoro.
Si farà vedere dove SB e SMT lavorano al meglio, e si cercherà di vedere dove BD andrà peggio...
Probabile che cambieranno anche i software di bench... magari il tanto decantato superpippo, che è tutto tranne un software di test potenza, probabilmente sparirà dalla scena

[paolo.oliva2]

Originariamente inviato da cionci

Devi capire che l'OC non interessa a "nessuno". Definisco "nessuno" come il 90% del mercato di questi processori.

Concordo, ma siccome noi qui come presupposto stabiliremmo il procio più potente, sotto tutti gli aspetti, al 90% in questo TH l'OC interessa eccome.
Figurati a me
In fin dei conti, penso probabile che AMD continui nel pubblicizzare i suoi World Record Overclock, come del resto, chi vuole fare numeri, acquista il procio che può raggiungere prestazioni più elevate.
Potrebbe essere tranquillamente fattibile vedere un BD sui 9GHz e forse anche 10GHz sotto azoto.
Se pensi che Intel con il 32nm HKMG non è ancora in grado di superare sotto azoto un 45nm liscio di AMD, pensa la differenza dopo BD...
Io già mi intrippo a pensare di portare un BD X8 solamente a 5GHz per vedere che risultati può dare, pensa già solamente la differenza tra un Thuban a 4,5GHz e un BD X8 a 6GHz... non oso pensare alle varie classifiche mondiali sui risultati dei bench....

[cionci]

Originariamente inviato da paolo.oliva2

Concordo, ma siccome noi qui come presupposto stabiliremmo il procio più potente, sotto tutti gli aspetti, al 90% in questo TH l'OC interessa eccome.
Figurati a me

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.

[Pihippo]

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.

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.