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

[capitan_crasy]

Originariamente inviato da AceGranger

con BD X8 si intendono 8 "moduli" giusto ?

poi sarebbe anche interessante vedere quale bench sia stato usato.

X8 ha 4 moduli, X16 invece ha 8 moduli...

[capitan_crasy]

Originariamente inviato da paolo.oliva2

Forse è una burla... a giudicare dal disegno...



An AMD employee released some info on the upcoming Bulldozer CPU. Preliminary benchmarks on an 8 core Bulldozer desktop processor have it trouncing the mighty Intel i7 980X by a whopping 192% in 3D rendering benchmarks. The Orochi design is the company’s next-generation processor for high-end desktop. Rumors have the 8 core chip debuting at 3.4-4.0 GHz. AMD will launch their desktops chips first in an effort to regain market share from Intel.

In teoria... alla buona, considerando BD X8 a 4GHz e l'i980X X6 a 3,333GHz, per arrivare al risultato del 192% migliore nel bench, dovrebbe avere un IPC del 20% superiore all'i7 980X. Alla faccia dell'IPC di poco superiore al Phenom II (sempre che il post non sia una burla). Comunque bisogna notare che l'i980X non ha una gran scalabilità nell'aumento dei core, e invece AMD da sempre è stato più che ottimo. Può darsi che il risultato sia sproporzionato per questo.

qui

...AMD prevede inoltre di far rivivere l'appassionato di piattaforma multi-processore con una nuova configurazione dual socket AMD FX sportivo CPU con CPU 4,6 e 8 core. lol, 16 core per desktop... Certo che 2 BD X8 a 4GHz... Porca zoccola... se è vero... sto giro mi tocca spendere una cifra... va beh, è uno sforzo che farei volentieri, giusto per la libidine di confrontarmi con SB e IB, tanto sarei certo che spenderò molto meno a chi preferirà Intel, e sarei appagato nel vedere le differenze dei risultati...

...Più tardi nel 2011 AMD lancerà la loro fusione piattaforma di esecuzione che unisce processore generale, nonché la lavorazione 3D della geometria e le altre funzioni delle GPU moderne in un unico pacchetto. approccio di AMD al computing per uso generico su unità di elaborazione grafica o GPGPU eliminerà il 90% della programmazione carico di lavoro richiesto per i programmatori per fare uso del potere di elaborazione della GPU. NVIDIA CUDA è stata finora un fallimento ma con Fusion la CPU e GPU saranno sullo stesso processore, l'implementazione di AMD di OpenCL attraverso un API permette ai programmatori di scaricare facilmente intensivo compito computazionale per la GPU, mentre liberare la potenza della CPU. Finora i principali pacchetti 3D quali Maya, 3DSMax, Cinema 4D e non sono stati in grado di utilizzare l'elaborazione GPGPU per rendere le scene, ma con AMD Fusion rendering di ambienti ad alta intensità di Ray-tracing sarà ridotto di un fattore di 20 a circa il 5% di CPU originale basato tempi di rendering....

Come al solito cè chi prende i rumors con cautela e chi li pubblica senza ritegno...
Inoltre quel 192% mi sa tanto di peperoncino nel latte...

[cionci]

Originariamente inviato da capitan_crasy

Come al solito cè chi prende i rumors con cautela e chi li pubblica senza ritegno...
Inoltre quel 192% mi sa tanto di peperoncino nel latte...

Più che altro ci fosse un link ai risultati del test...

[Athlon 64 3000+]

Originariamente inviato da bjt2

Per esserlo a quelle frequenze dovrebbe avere almeno un 25% in più di IPC... Ne dubito. Però siccome il turbocore nuovo dovrebbe essere più efficace e il clock base degli X4 dovrebbe abbondantemente superare i 4 GHz, un modello da 4-4.2GHz base dovrebbe farcela. Ovviamente si spera che un tale modello non sia il TOP e quindi costi poco...

Te lo chiedevo perchè Llano uscendo non prima di luglio e per il fatto che ora ho un Thuban sono rimasto completamente spiazzato e a questo punto l'unica cpu che potrei prendere è un Buldozer e non so se voglio passare a Buldozer mi conviene prendere un x4 o addirittura prendere un x6.

[AceGranger]

Originariamente inviato da bjt2

Credo 4 moduli... Si parla della versione desktop... L'X16 dovrebbe tritare qualunque CPU INTEL, visto che già l'X12 battaglia...

Originariamente inviato da capitan_crasy

X8 ha 4 moduli, X16 invece ha 8 moduli...

mi sembra un po strano che dia quei risultati...

[capitan_crasy]

Originariamente inviato da cionci

Più che altro ci fosse un link ai risultati del test...

Siamo quasi ai livelli di FUDZILLA...

Originariamente inviato da AceGranger

mi sembra un po strano che dia quei risultati...

Secondo me non bisogna prendere troppo sul serio certi rumors senza capo ne coda...
Chiunque può aprire un sito e scrivere quello che vuole...

[checo]

Originariamente inviato da capitan_crasy

Siamo quasi ai livelli di FUDZILLA...




Secondo me non bisogna prendere troppo sul serio certi rumors senza capo ne coda...
Chiunque può aprire un sito e scrivere quello che vuole...

ma manco occorre aprirlo il sito, basta scrivere sul forum spacciano per vere le cose e qualcuno abbocca sempre.

[Pihippo]

Originariamente inviato da bjt2

Considerando che per compensare le scarse prestazioni del moltiplicatore intero delle CPU INTEL, il compilatore ICC ottimizza il più possibile le moltiplicazioni con LEA, ADD e company, ipotizzo che AMD abbia fatto le AGU indipendenti dalle ALU proprio per processare fino a 4 LEA per clock (due nelle AGU e due nelle ALU) e magari anche 4 ADD, in modo da essere avvantaggiati anche con codice ottimizzato INTEL...

Ciao
Eh si, dico di più per non incasinarsi con i carry flag esistono 2 versioni di LEA, una complex (Flag) eseguita dalle alu ed una simple (niente flag) eseguita dalle agu (questo anche nel k10 ma li o op alu o op agu per i motivi che dicevi prima)

Originariamente inviato da cionci

Ottima osservazione questa.
Non credo che possa effettuare 4 ADD o 4 LEA contemporaneamente, ma la possibilità di fare 2 LEA e 2 ADD contemporaneamente è già abbastanza remunerativa.
Il problema comunque continuano a rimanere i code path alternativi in base al CPUID

Ciao
Molto buona oserei dire se lo scheduler è efficace
L'unico problema casoma sarebbe la bw di operandi verso le unità, ma penso che anche li abbiano fatto passi avanti .

[Pihippo]

Originariamente inviato da cionci

Sì, chiaramente. A meno che tu non abbia SIMD su interi

Ciao.
Pero se utilizzi op simd (vettori intendo non sse scalari) te ne importa poco della località dei dati in quanro hanno il pregio di essere salvati eseguiti e poi flushati per far posto ad una nuova istr (meno località degli scalari), dunque in teoria, sperando di non aver detto minchiate, le op di memoria dovrebbero diminuire. (come lea dunque)

[cionci]

Originariamente inviato da Pihippo

Ciao.
Pero se utilizzi op simd (vettori intendo non sse scalari) te ne importa poco della località dei dati in quanro hanno il pregio di essere salvati eseguiti e poi flushati per far posto ad una nuova istr (meno località degli scalari), dunque in teoria, sperando di non aver detto minchiate, le op di memoria dovrebbero diminuire. (come lea dunque)

Sì, ma io mi riferivo ai code path I code path nei compilatori Intel vengono determinati in base al CPUID. bjt2 diceva che influiscono nel caso di prestazioni FP, ma in realtà anche in presenza di istruzioni SIMD intere può essere scelto un code path meno ottimizzato in base al CPUID.

[von Clausewitz]

Originariamente inviato da cionci

Sì, ma io mi riferivo ai code path I code path nei compilatori Intel vengono determinati in base al CPUID. bjt2 diceva che influiscono nel caso di prestazioni FP, ma in realtà anche in presenza di istruzioni SIMD intere può essere scelto un code path meno ottimizzato in base al CPUID.

quindi quale sarebbe la tua conclusione?
che i compilatori Intel favoriscono in base al CPUID alcuni processori piuttosto che altri nella compilazione e quindi nelle prestazioni sia FP che come interi come hai or ora adombrato?
cioè questo modo di funzionare del compilatore ha valenze meramente simboliche oppure ha effetti pratici di una certa rilevanza?
gusto per mettere una pietra miliare in un argomento così denso di leggende metropolitane, se lo dici tu mi fido

[bjt2]

Originariamente inviato da cionci

Sì, ma io mi riferivo ai code path I code path nei compilatori Intel vengono determinati in base al CPUID. bjt2 diceva che influiscono nel caso di prestazioni FP, ma in realtà anche in presenza di istruzioni SIMD intere può essere scelto un code path meno ottimizzato in base al CPUID.

A questo non ci avevo pensato...
A questo punto il codice prodotto da altri compilatori (penso a GCC) potrebbe girare meglio... Penso ai kernel linux che non sono certo compilati per usare le SSE, ma qualche moltiplicazione intera con uno dei due operandi costanti è sicuramente tradotto con LEA e ADD...

[von Clausewitz]

Originariamente inviato da cionci

Più che altro ci fosse un link ai risultati del test...

se è a livello di mera "confidenza" è difficile riprodurlo
ma potrebbe anche essere, prendendo per esempio un X16-8 moduli è chiaro che ne avrebbe di che sopravvanzare un i7 financo il 980
c'è da presumere però che sarà il top di gamma e sarà da raffrontare con un i7 SB su socket 2011 con 8 core-16 threads e 20 mb di cache L3, se non erro

[paolo.oliva2]

Originariamente inviato da von Clausewitz

quindi quale sarebbe la tua conclusione?
che i compilatori Intel favoriscono in base al CPUID alcuni processori piuttosto che altri nella compilazione e quindi nelle prestazioni sia FP che come interi come hai or ora adombrato?
cioè questo modo di funzionare del compilatore ha valenze meramente simboliche oppure ha effetti pratici di una certa rilevanza?
gusto per mettere una pietra miliare in un argomento così denso di leggende metropolitane, se lo dici tu mi fido

Ti spiego io, sta pur sicuro che nessuno sta creando leggende metropolitane.

In pratica, ogni set di istruzioni, tipo SS2, SS3 SS4, e così via, introduce ottimizzazioni atte a risolvere gli stessi calcoli più velocemente.
Quello che fa il compilatore Intel, è che se riconosce il procio come "genuine Intel", applica tutte le ottimizzazioni possibili, se non è "genuine Intel", non le applica. Mi sembra chiaro che in caso di set d'istruzioni SSE4 che vengono trasformate in SS2, oltre che perdere le varie ottimizzazioni, si ha un tempo superiore perché queste vengano ricodificate come set d'istruzioni inferiori, a tutto scapito della velocità.

La scusa ufficiale di Intel è stata che questo azzoppamento è stato introdotto per assicurare la compatibilità con tutti i proci di tutte le marche, ma la smentita a ciò è stato che facendo passare un procio AMD come "genuine Intel", problemi di incompatibilità non si sono presentati e chiaramente le performances sono aumentate.
Questo modo partigiano dei compilatori Intel era già stato supposto perché in ambito Linux i proci AMD risultavano ben più performanti che in ambito Windows.
Chiaramente nessuno può obbligare Intel a rendere il suo compilatore ottimizzato anche per AMD, ma lo scorretto è che Intel confronti i suoi proci con quelli AMD facendoli risultare più potenti tralasciando che buona parte delle differenze derivano dal fatto che i suoi compilatori fanno lavorare i proci non "genuine Intel" in modo castrato.
Quello che in pratica si chiederebbe, non è di ottimizzare il codice per AMD, ma solo di non utilizzare la procedura "if not genuine Intel then", il che mi sembra non dovrebbe essere una cosa complessa da fare.

QUI

A grandi linee...

[cionci]

Originariamente inviato da von Clausewitz

quindi quale sarebbe la tua conclusione?
che i compilatori Intel favoriscono in base al CPUID alcuni processori piuttosto che altri nella compilazione e quindi nelle prestazioni sia FP che come interi come hai or ora adombrato?
cioè questo modo di funzionare del compilatore ha valenze meramente simboliche oppure ha effetti pratici di una certa rilevanza?
gusto per mettere una pietra miliare in un argomento così denso di leggende metropolitane, se lo dici tu mi fido

Ha effetti pratici, i test erano stati fatti già molto tempo fa ed ora la cosa è rispuntata fuori.

http://www.agner.org/optimize/blog/read.php?i=49

[paolo.oliva2]

Originariamente inviato da von Clausewitz

se è a livello di mera "confidenza" è difficile riprodurlo
ma potrebbe anche essere, prendendo per esempio un X16-8 moduli è chiaro che ne avrebbe di che sopravvanzare un i7 financo il 980
c'è da presumere però che sarà il top di gamma e sarà da raffrontare con un i7 SB su socket 2011 con 8 core-16 threads e 20 mb di cache L3, se non erro

Il problema è che nel confronto tra un SB ed un BD non contano solo i core e l'IPC.
Dobbiamo tenere presenti tanti altri fattori:

Superficie die (immagina che padella sarebbe un procio con 20MB di cache L3 confrontato a BD con L3 di 8MB, con tanto di percentuale superiore di proci fallati se non altro per l'avere già 3 volte in più di integrati solo nella L3) ed il tutto si riflette indubbiamente sul costo.

Inoltre, stai pure tranquillo che i 16TH logici che si poggiano su 8 core fisici avrebbero un potenziale nettamente inferiore a 16TH fisici ma che si poggiano su 16 core, anche valutando differenze di IPC anche del 50% a core (anche se attualmente BD è max X8, i 95W TDP farebbero tranquillamente supporre che sia unicamente una questione di dire si o no da parte di AMD l'aumento di core a procio)

Poi bisogna pur sempre valutare che la potenza di un procio è data dall'IPC X frequenza lavorativa, in cui sicuramente l'architettura di Intel degli i7/SB non ha caratteristiche già di base per poter pensare a clock alti.

Poi scusami... non è un discorso di parte:
Se un SB X4 avrebbe già 95W a 3,4GHz... lo stesso X8, con L3 più grande, farebbe supporre (tralasciando il leackage) a 190W per un SB X8 solamente a 3,4GHz... BD X8 alla stessa frequenza avrebbe un TDP del 50% inferiore, quindi, per quanto possiamo bendarci gli occhi, Intel non riuscirebbe ad avere un IPC del 50% superiore a BD tale da portare un pareggio tra TDP/potenza.

Su questa base, anche senza test, bench e quant'altro, mi pare chiaro che sperare in un SB X8 con frequenze maggiori di 3GHz dentro i 130W TDP si sarebbe nell'ottimismo puro, il quale si dovrebbe scontrare con un BD X8 che già avrebbe dalla sua un 33% di clock in più a minor TDP. Uniscici che a parità di costi un BD X8 potrebbe costare la metà di un SB X8 appunto per l'enorme differenza del die, mi sembra plausibile che AMD avrebbe un prodotto che nel peggiore dei casi sarebbe di uguale potenza ma con un costo applicabile a dir poco del 50% rispetto ad SB X8.

Finché vogliamo teorizzare potenze pure e quant'altro possiamo teorizzare quello che vogliamo, ma quando si tratta comunque di comprare, vorrei vedere chi acquisterebbe un SB X8 a 1000€ contro un BD X8 a 500€ (valutando come differenza unicamente la quantità di proci a wafer che con AMD sarebbe almeno superiore del doppio). E' anche per questo che io deduco che AMD a parità di potenza può tranquillamente applicare un prezzo di molto inferiore a quello Intel conservando comunque più guadagno di Intel... Dallo stesso wafer di 300mm AMD produrrebbe un numero di proci almeno doppio rispetto a quello Intel. Possiamo avere il dubbio che la quantità di proci scartati possa essere verso AMD (ma comunque difficile, visto che un SB X8 avrebbe almeno 3 volte in più dei transistor di un BD X8), possiamo supporre in un costo inferiore di produzione (ma parliamo pur sempre di 32nm HKMG low-k per entrambi... quindi se ci fossero differenze, di quanto potremmo parlare? 10%?). A fronte che Intel potrà richiedere un prezzo basso, ma per quanto sia basso, concederà SEMPRE un margine di guadagno notevolmente superiore, quindi è facile dedurre che dove potrà arrivare Intel, ancor meglio potrà arrivarci AMD.

Le cose potranno cambiare quando Intel passerà sul 22nm, perché il discorso di costi produzione lo si dovrà rivedere, però io non darei assolutamente per scontato che Intel riuscirà ad ottenere con il 22nm un TDP/potenza simile a quello AMD, la quale, in tutti i casi, a distanza di poco meno di 1 anno, avrà pure lei il 22nm.

[marchigiano]

Originariamente inviato da unnilennium

la differenza sostanziale tra gli fx e i be è il prezzo...

no... sono le prestazioni rispetto alla concorrenza

Originariamente inviato da paolo.oliva2

Intel non potrà MAI arrivare ad abbassare i prezzi in rapporto ad un BD X4 e X8 per i prezzi che ha AMD, perché produrre un procio costa in base alla superficie del die (dando per scontato che il costo produzione sia uguale o almeno simile), ma il prezzo di mercato l'ha in base alla potenza.

ma GF è una associazione umanitaria o una società con scopo di lucro? perchè nel secondo caso dovrà caricarci qualcosa sul silicio a amd quindi a pari superficie di die le cpu costeranno più ad amd che intel

Originariamente inviato da pierluigi86

a volte la gente si dimentica che intel ha un utile netto di 3 mld, roba impressionante per chiunque, ora volete venirmi che intel nn ha un prodotto in grado di rispondere ad amd? ma vi rendete conto che amd esiste solo perchè non conviene ad intel farla chiudere?

I bulldozer saranno delle buone cpu, almeno lo spero, ma non iniziate a fare troppi sogni di gloria. Inoltre voglio fare 2 considerazioni
1) Bulldozer uscirà nella seconda metà dell' anno e se avete fatto casa Amd ha posticipato e mai anticipato. Ergo vedremo qualcosa dopo l' estate.
2) se le prestazioni fossero molto buone già avremmo visto i primi bench almeno quelli generici.

quoto

Originariamente inviato da capitan_crasy

AMD esiste perchè ha quasi il 20% del mercato delle CPU X86; Intel non può far chiudere nessuno, almeno restando nella legalità...

gli bastava vendere i core2 a metà prezzo fino a oggi e amd sarebbe sparita

Originariamente inviato da paolo.oliva2

La scusa ufficiale di Intel è stata che questo azzoppamento è stato introdotto per assicurare la compatibilità con tutti i proci di tutte le marche, ma la smentita a ciò è stato che facendo passare un procio AMD come "genuine Intel", problemi di incompatibilità non si sono presentati e chiaramente le performances sono aumentate.
Questo modo partigiano dei compilatori Intel era già stato supposto perché in ambito Linux i proci AMD risultavano ben più performanti che in ambito Windows.

lo stesso JD ha scritto che ottimizzare e diffondere il compilatore amd costerebbe 10 milioni di $.... quindi se intel spende sti 10M non lo fa certo per avvantaggiare la concorrenza...

[capitan_crasy]

Originariamente inviato da marchigiano

gli bastava vendere i core2 a metà prezzo fino a oggi e amd sarebbe sparita

.

Certo che Intel ha proprio un buon cuore...

[checo]

Originariamente inviato da cionci

Ha effetti pratici, i test erano stati fatti già molto tempo fa ed ora la cosa è rispuntata fuori.

http://www.agner.org/optimize/blog/read.php?i=49

c'è da dire che influenza quasi esclusivamente le operazioni della fpu, che sono in minoranza nell'uso generale.

non è che con un compilatore imparziale un phenom2 raggiunga in prestazione un i7.

[checo]

Originariamente inviato da marchigiano

gli bastava vendere i core2 a metà prezzo fino a oggi e amd sarebbe sparita

al massimo falliva, fare sparire AMD è al momento impossibile.

mettiamo che intel avesse venduto i core2 a prezzi stracciati, anche sottocosto e mad da parte sua non poteva farci nulla, avendo cpu meno performati e più costose da produrre.

alla fine ovvio che amd avrebbe ceduto dato che abbiamo intel con una buona riserva di cassa e amd con una buona riserva di debiti.

a quel punto o probabilmente prima qualcuno si sarebbe comperato amd per due spicci.

se amd scoprarisse, scomparirebbe pure intel come la conosciamo oggi.
esempio at@t