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

[Revelator]

Originariamente inviato da fastleo63

Da quanto ne so, se avessi preso una 970 la connessione PCIe x16 della VGA sarebbe stata ridotta ad x8 perchè nel sistema ho anche una controller SAS PCIe x8. Non che vi sia una gran differenza, penso che la NVIDIA GTS 450 non ci avrebbe rimesso più di tanto, ma tant'è...
E poi la sezione alimentazione della Sabertooth 990FX è notevole, il calore prodotto è irrisorio.
La mainboard gode inoltre di una garanzia di 5 anni.

beh allora si nel mio caso monterò solo una x-fi e una ati 5870 usando i canali sata 3 per i dischi non credo di avere problemi col 970

[The3DProgrammer]

Originariamente inviato da paolo.oliva2

Ho editato il tuo post per chiederti questo e se il mio ragionamento è valido:

Quello in verde diciamo che BD e Thuban si equivalgono quindi ci sarebbe un pareggio di IPC, quindi BD con clock più alto = potenza maggiore.

Quelle in rosso sarebbe la nota dolente (dove c'è un minimo ed un massimo ho preso un valore medio per semplicità) e poi ho confrontato per un funzionamento a 4,2GHz teorizzando che sia la massima frequenza su tutti i core e non su 4, di un 8150p (lasciando perdere l'8170p).

FSUB 5 5 = pareggio se BD con clock 3,3GHz (+27%)
FMUL 5 5 = pareggio se BD con clock 3,3GHz (+27%)
FLD 4 4 = pareggio se BD con clock 3,3GHz (+27%)
FDIV 21 42 = pareggio se BD con clock 6,6GHz (-37%)
FSIN 93 148 = pareggio se BD con clock 5,25GHz (-20%)
FCOS 93 151 = pareggio se BD con clock 5,35GHz (-22%)
FPATAN 109 240 = pareggio se BD con clock 7,26GHz (-43%)
FPTAN 151 433 = pareggio se BD con clock 9,46GHz (-66%)
FSQRT 27 52 = pareggio se BD con clock 6,35GHz (-34%)

Non ho le basi per distinguere quali istruzioni verrebbero eseguite in percentuale maggiore (anche perché varierebbe in base al programma), quindi ho fatto una media dei valori e risulterebbe che un BD X6 a 4,2GHz risulterebbe mediamente del 15,66% sotto ad un Thuban X6.

Però ci sarebbero 2 cose...

Se prendiamo gli ultimi bench, sarebbero tutti fake perché ipotizzare che BD a 4,2GHz dove nella condizione migliore risultasse del 27% migliore al Thuban, di certo non arriverebbe comunque nemmeno vicino ad un i5.

Poi non ho idea dell'MT, perché comunque un BD X8 avrebbe il vantaggio dei 2 core in più sul Thuban quindi è difficile che se sommiamo la perdita del CMT con la media del -15,66% di IPC inferiore (non so Cinebench che istruzioni sfrutta), praticamente BD non dovrebbe arrivare nemmeno vicino al risultato di un Thuban.

Quindi credo che comunque ci siano altri fattori che migliorino la media... ma il punto è un altro, ed arrivo alla mia domanda:

Così impostato, con l'IPC di BD inferiore di media del -15,66% rispetto ad un Thuban, praticamente un BD X6 dovrebbe avere un clock maggiore di 3,8GHz solamente per pareggiare il Thuban e l'i7 e SB?
Ora... non penso che AMD abbia ipotizzato frequenze di 6GHz def per BD, quindi c'è qualche cosa che non funzia.
Può il silicio, oltre ad influenzare le massime frequenze raggiungibili, penalizzare anche le latenze?

Allora in quello che hai scritto hai trascurato alcuni punti:

Le istruzioni che hai evidenziato possono essere eseguite da BD 2 alla volta (k10 puo' eseguirne 1 alla volta o cmq con meno parallelismo rispetto a bd) quindi per quelle particolari istruzioni effettivamente BD e' quasi o il doppio + veloce di k10. Inoltre BD e' molto + orientato all'ILP (Instruction Level Parallelism) di K10, che significa in soldoni che + istruzioni riesce a ricevere in parallelo, + la latenza finale totale "percepita" e' inferiore. Inoltre come detto da bjt branch prediction decoding e prefetching sono state migliorate, il che dovrebbe contribuire a nascondere le latenze dell'engine di esecuzione. Quindi fin qui tutto bene.

Il problema grosso sono proprio le istruzioni che hai evidenziato in rosso (ce ne sono anche altre, se ho tempo nel we faccio una comparativa + approfondita includendo anche le sse). Perche' qui si perde gran parte del parallelismo in quanto istruzioni molto complesse (parlo di fsin fcos fatan etc, fdiv e fsqrt non sono a microcode) , in + queste istruzioni sono usatissime in un sacco di domini applicativi, tra cui(guarda un po) rendering e giochi 3d. In questi casi bd arriva ad essere quasi 4 volte + lento di un k10, quindi non mi stupirei proprio se quei spi che abbiamo visto fossero veri. In caso di uso intenso di queste istruzioni potrebbe essere anche + lento di un athlon64, perche' non credo onestamente che un prefetcher migliorato e una bp + efficiente sianp sufficienti a mascherare latenze di esecuzione talmente elevate, considerando anche il fatto che il sottositema cache di bd nn mi pare esattamente brillante.
Detto questo, ricordo che x87 e' deprecato e che anche se ci sono app che ancora le usano, spariranno in futuro. Quindi non c'e' bisogno di fasciarsi la testa o allarmarsi + di tanto

[Mparlav]

Possibile rinvio a novembre per Interlagos

Fonte

"Meanwhile, AMD's server processor codenamed Interlagos will also have difficulty shipping on schedule and is expected to be delayed to November."

[-Maxx-]

Originariamente inviato da Mparlav

Possibile rinvio a novembre per Interlagos

Fonte

"Meanwhile, AMD's server processor codenamed Interlagos will also have difficulty shipping on schedule and is expected to be delayed to November."

Ma che combinano?

[Tenebra]

Originariamente inviato da The3DProgrammer

Detto questo, ricordo che x87 e' deprecato e che anche se ci sono app che ancora le usano, spariranno in futuro. Quindi non c'e' bisogno di fasciarsi la testa o allarmarsi + di tanto

E' forse utile far notare che nel campo videoludico l'approccio alle innovazioni è quantomeno conservativo: basti pensare che sono passate 3 generazioni di schede video, siamo alle DX11 e ancora il 90% dei giochi viene programmato in DX9, per poi aggiungere solo qualche effettino dei path superiori.
Idem se non peggio per tutto il resto: c'è una questione di compatibilità e facili conversioni multipiattaforma da mantenere, quindi i vg sono nella quasi totalità dei casi programmati con le tecniche più "base" che ci siano. E sono proprio quelle che BD ha scartato e in cui fa una fatica boia...

Quindi il calcolo che hai appena postato, in cui BD arranca anche in confronto ad un Thuban, semmai fa ancora più paura per chi vorrebbe prendersi un BD per giocare

Edit: teniamo conto del fatto che se mi prendo una cpu per giocare voglio farlo coi titoli di oggi, non con quelli di domani o più probabile, che usciranno fra due anni, altrimenti mi tengo il processore attuale... in questo ambito dire "le app che lo usano spariranno in futuro" è come dire "prenditi qualcos'altro perchè quando sarà competitivo, sarà già ora di cambiarlo o comunque costerà la metà"

[marchigiano]

raga ho fatto un bel contatore per bulldozer in java superscript assembler transformers

[bjt2]

Originariamente inviato da The3DProgrammer

Allora in quello che hai scritto hai trascurato alcuni punti:

Le istruzioni che hai evidenziato possono essere eseguite da BD 2 alla volta (k10 puo' eseguirne 1 alla volta o cmq con meno parallelismo rispetto a bd) quindi per quelle particolari istruzioni effettivamente BD e' quasi o il doppio + veloce di k10. Inoltre BD e' molto + orientato all'ILP (Instruction Level Parallelism) di K10, che significa in soldoni che + istruzioni riesce a ricevere in parallelo, + la latenza finale totale "percepita" e' inferiore. Inoltre come detto da bjt branch prediction decoding e prefetching sono state migliorate, il che dovrebbe contribuire a nascondere le latenze dell'engine di esecuzione. Quindi fin qui tutto bene.

Il problema grosso sono proprio le istruzioni che hai evidenziato in rosso (ce ne sono anche altre, se ho tempo nel we faccio una comparativa + approfondita includendo anche le sse). Perche' qui si perde gran parte del parallelismo in quanto istruzioni molto complesse (parlo di fsin fcos fatan etc, fdiv e fsqrt non sono a microcode) , in + queste istruzioni sono usatissime in un sacco di domini applicativi, tra cui(guarda un po) rendering e giochi 3d. In questi casi bd arriva ad essere quasi 4 volte + lento di un k10, quindi non mi stupirei proprio se quei spi che abbiamo visto fossero veri. In caso di uso intenso di queste istruzioni potrebbe essere anche + lento di un athlon64, perche' non credo onestamente che un prefetcher migliorato e una bp + efficiente sianp sufficienti a mascherare latenze di esecuzione talmente elevate, considerando anche il fatto che il sottositema cache di bd nn mi pare esattamente brillante.
Detto questo, ricordo che x87 e' deprecato e che anche se ci sono app che ancora le usano, spariranno in futuro. Quindi non c'e' bisogno di fasciarsi la testa o allarmarsi + di tanto

In applicazioni sensibili alle prestazioni, per seno coseno ecc, sono usate lookup table con eventuale interpolazione...

[The3DProgrammer]

Originariamente inviato da bjt2

In applicazioni sensibili alle prestazioni, per seno coseno ecc, sono usate lookup table con eventuale interpolazione...

sicuramente, ma figurati se nvidia nel physx sdk ha usato le lookup (per fare un esempio)

EDIT: cmq e' vero, un punto importante che avevo trascurato e' che spesso queste istruzioni cmq non vengono utilizzate ma al loro posto vengono usate delle tabelle di dimensioni variabili inizializzate con dei valori significativi e i restanti valori vengono calcolati tramite interpolazione (lineare il 99% delle volte). Quindi tenebra, un motivo in + per non fasciarsi la testa

[Heimdallr]

Originariamente inviato da marchigiano

raga ho fatto un bel contatore per bulldozer in java superscript assembler transformers

lol
misa che per BD bisognerà chiedere a lui:

[Trokji]

ho avuto la stessa idea..

[nitro89]

Old (2giorni) ma interessante

Shipments Delays of Bulldozer CPUs.

http://www.xbitlabs.com/news/cpu/dis...ozer_CPUs.html

[maurilio968]

Scusate se ribadisco:
se quelle slide sono vere siamo messi male.

Il problema non sarebbe nemmeno la bassa frequenza a default ma proprio l'architettura sballata in certi ambiti di utilizzo dsktop.

Infatti un bd8150p a 4.8ghz al cinebench 11.5 applicazione a 64bit usata come misura delle prestazioni in ambito rendering nel 2011, non un gioco del 2003 o uno di oggi programmato male!, farebbe lo stesso punteggio di un thuban 1100t@4,4ghz.

Quindi scalerebbe con la frequenza meno di quanto fa un thuban.

Se il 12 ottobre Bd 8150p uscisse con frequenza def di 4.8ghz facendo un punteggio di 7.8 al cinebench (come indicano quelle slide) sarebbe grave.
Deve fare tipo 10 a 3.6ghz.

altro che non fasciarsi la testa, soprattutto (ripeto) se riportiamo il discorso anche al 6100 e 4100.

[Tenebra]

Originariamente inviato da maurilio968

Scusate se ribadisco:
se quelle slide sono vere siamo messi male.

Il problema non sarebbe nemmeno la bassa frequenza a default ma proprio l'architettura sballata in certi ambiti di utilizzo dsktop.

Infatti un bd8150p a 4.8ghz al cinebench 11.5 applicazione a 64bit usata come misura delle prestazioni in ambito rendering nel 2011, non un gioco del 2003 o uno di oggi programmato male!, farebbe lo stesso punteggio di un thuban 1100t@4,4ghz.

Quindi scalerebbe con la frequenza meno di quanto fa un thuban.

Se il 12 ottobre Bd 8150p uscisse con frequenza def di 4.8ghz facendo un punteggio di 7.8 al cinebench (come indicano quelle slide) sarebbe grave.
Deve fare tipo 10 a 3.6ghz.

altro che non fasciarsi la testa, soprattutto (ripeto) se riportiamo il discorso anche al 6100 e 4100.

Pur con tutta la negatività del mondo, fatico a credere che possa essere un fail di tale portata. Non credo nemmeno l'avrebbero presentato se avesse queste prestazioni, li massacrerebbe ogni singola recensione, non glieli comprerebbero nemmeno i fanboy.
Tra l'altro, l'8150 NON HA una frequenza default di 4.8...

[astroimager]

Originariamente inviato da marchigiano

raga ho fatto un bel contatore per bulldozer in java superscript assembler transformers

Questo counter è perfetto per il Bulldozer che credevamo dovesse arrivare!

Scherzi a parte... la mia impressione è che quella di BD sia un'architettura concepita principalmente per recuperare il gap prestazionale in ambito server.
Ma anche in questo campo ho qualche dubbio che potrà competere ad armi pari con la nuova generazione di Xeon a 32nm... ovviamente considerando solo l'aspetto prestazionale!

Ad ogni modo, grazie alla possibilità di salire maggiormente in frequenza rispetto al K10, per un uso desktop tipico BD risulta interessante, anche se il vero potenziale - per una serie di motivazioni che presto o tardi conosceremo - ancora deve esprimerlo.

Rimango più perplesso sull'implementazione in ambito mobile, dove avere il miglior rapporto performance/TDP è fondamentale.
Elevare le prestazioni affidandosi unicamente alla frequenza è potenzialmente "pericoloso", specie sulla base di questi 32 nani, per ora un po' farlocchi. D'altra parte, Trinity sembra già in fase molto avanzata di sviluppo, e questo è qualcosa di più rispetto a una banale speranza...

Dove AMD imho deve premere l'acceleratore è sull'aspetto più "concreto" del progetto Fusion, ovvero realizzare un hw APU che sia un grado di macinare più efficacemente possibile i macigni sw che sempre più spesso deve ingoiare un PC moderno.

Aggiungo, ma questa è un'utopia: non sarebbe male, anche per la produzione di CPU su base SOI o analogo, affidarsi ad altre fonderie.

[Anachronox]

Proviamo a lasciare da parte un attimo il Cinebench.
Nelle altre applicazioni MT l'8150 sarebbe in grado di vedersela col 2500k/2600k, un risultato direi apprezzabile.

Per quanto riguarda i giochi, sicuramente questi soffriranno delle debolezze che ha attualmente l'architettura (cosa ancor più grave se consideriamo i modelli minori). Per cui sì, in ambito game rischiamo il fail. Negli altri però spero BD riesca a dire la sua, contando che è concepito per server workload.

(Magari dopo tutte queste voci negative AMD fa il colpaccio e manda a casa il 990x: sarebbe da )

[Trokji]

Magari dopo tutte queste voci negative gli amd fx bulldozzerano letteralmente sandy bridge ed ivy bridge a default. Speriamo

[astroimager]

Originariamente inviato da liberato87

quando l ho letto mi sembrava proprio una beffa perciò ho voluto condividere con voi questa cosa

è la stessa cosa che ho pensato.
come giustamente hai sottolineato tu c'è scritto sotto al grafico

"estimates and projections subject to change "

però un "change" del 100% non è un "change" ma è oggettivamente un fail.
e sapete tutti quanto io sono per amd e quanto ho cercato di vedere più o meno positivamente tutto, dai ritardi ai bench fasulli e non.

Sono giorni che lo dico, avevo modificato anche il grafico per come sarebbe dovuto essere secondo le aspettative AMD (contando che la slide di dicembre 2010 fosse basata su un 4.0 GHz):
http://www.hwupgrade.it/forum/showpo...ostcount=24635

Come può essere, dunque?

- potenza FPU troppo scarsa (4 unità solo un po' più potenti delle 6 in Thuban)
- errori in altri punti critici dell'architettura (L1, caching in generale, pipeline, BP,...)
- bug prestazionale pesante, non risolvibile con gli step Bx

Comunque confermo altre impressioni di post addietro: quando ci sono pesanti ritardi, l'NDA ferreo, mancano secche smentite, cadono teste, allora con AMD c'è poco da stare allegri!
Poi anche lo step... B2, sembra una maledizione!

[astroimager]

Originariamente inviato da Trokji

Magari dopo tutte queste voci negative gli amd fx bulldozzerano letteralmente sandy bridge ed ivy bridge a default. Speriamo

Resterebbero comunque degli st30#2i per non aver smentito in maniera ufficiale e cristallina la veridicità di quelle slide.

Che poi il settore marketing dimostra di non sapere una cippa di quando l'azienda poteva vantare davvero gli FX!
Erano il TOP a livello di performance, ma non di overclockabilità!
Qui invece abbiamo probabilmente il TOP di overclockabilità, ma non di performance!

Io oggettivamente li avrei chiamati in maniera diversa, e in un secondo momento magari avrei lanciato minimo un x4 da 5.0 GHz, x6 da 4.8 e x8 da 4.6 con il brand FX!

[Trokji]

potevano metterli a 350 euro e mettere un sistema a liquido stock integrato facendoli partire in stock da 5 ghz senza turbo, perché penso si sarebbero sforati i 200 W . Magari gli entusiasti sarebbero accorsi..
Ma cmq si fa per parlare, io aspetterei qualcosa di ufficiale e definitivo o quasi prima di tirare le somme.
Spero comunque che non siano dei processori dove si punta solo sulla frequenza, altrimenti sarebbero i pentium D del 2012 e non sarebbe una buona cosa

[cacoci]

per me sono slide fasulle o taroccate quelle originali, perchè se fossero vere è una catastrofe universale per me e per loro dovrebbero nasconersi per l'eternità, nono non è vero è un'illusione tutto himo naturalmente