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

[calabar]

Originariamente inviato da blackshard

Io spero che bulldozer offra un IPC decisamente superiore in ambito single-threaded, ma temo che sotto questo aspetto rimarrò deluso. Temo di vedere di nuovo benchmark in multithreading pesante dove AMD compete e benchmark in single threading (giochi compresi) dove AMD è due generazioni indietro.

Ne ha decisamente bisogno, ma secondo me ci sono le premesse perchè possa dire la sua in ambito single thread.
Al di la delle migliorie generali, il nuovo turbo in questo senso dovrebbe dare ottimi risultati, così come ha fatto con la generazione nehalem per intel.
Per di più, se in un modulo BD la logica condivisa fa calare le prestazioni in multithread rispetto a due core completi (il famoso 80% dichiarato da amd), in single thread il solo core servito avrà una logica e un throughput sovrabbondante rispetto ad un core completo, tanto che potrebbe dargli una spintina in più, superando le prestazioni del core completo.

Originariamente inviato da paolo.oliva2

Il punto è... perché Intel non ha commercializzato SB come EE ed a prezzi da EE ma come K a prezzi di gran lunga più bassi? Perché Intel più volte ha detto che BD non va confrontato con gli i7 (X4 e X6) ma con SB?

La risposta a queste domande è semplice.
SB EE semplicemente non è ancora uscito, gli attuali SB sono quelli di fascia mainstream , gli SB "pesanti" usciranno tra qualche mese e si chiameranno SB-E.
Vista l'attuale situazione, Intel si è potuta permettere di far uscire prima la fascia mainstream, che vende di più, e lasciare in fascia alta la vecchia generazione, che comunque la concorrenza non era in grado di raggiungere, mantenendo quindi il podio.
BD va confrontato con SB semplicemente perchè fanno parte della stessa "generazione". Del resto nehalem ha ormai tre anni, non pochi in ambito informatico.
Tutto qui.

[digieffe]

Originariamente inviato da paolo.oliva2

...cut

Ti faccio un esempio MOLTO pratico, addirittura dando per BD un IPC UGUALE al Phenom II:
Il Thuban a def raggiunge i 3,7GHz. BD dovrebbe raggiungere i 4,2-4,5GHz sempre a def.

Ora... un 20% di potenza in più la si avrebbe già con BD operativo a 4,440GHz, IPC o non IPC e questo in ambito ST.
Aggiungici il fatto che questo riguarderebbe unicamente l'ST, in quanto nell'MT in programmi tipo Cinebench il guadagno di un procio AMD è perfettamente lineare rispetto all'incremento dei core, e passare a X8 rispetto ad un X6 significherebbe +33% a parità di frequenza.

...cut

per stare al tuo esempio preciso alcuni dettagli:

Phenom II 1100T in ST 3,7 ... Fx 8150 ST 4,2 (+13%) ... Fx 8170 ST 4,5 (+21%)
Phenom II 1100T in MT 3,3 ... Fx 8150 MT no turbo* 3,6 (+9%) ... Fx 8170 MT no turbo* 3,9 (+18%) -> solo differenza di freq.

*non conosco la freq. di turbo1 di questi processori.

il resto dipende dall'ipc e dal throughput.

Ps:
data la struttura a cluster di BD, ipotizando un ipc uguale in ST con il Thuban, non credo affatto che l'8 core dia +33% rispetto al Thuban, in quanto ogni cluster avrà un throughput inferiore a 2 core Thuban (alla condizione specificata -> uguale ipc)
es: ipotizzando che non ci siano perdite di scalabilità tra l'ipc ed il throughput (alla stessa condizione di prima) abbiamo
Thuban ipc x 6, BD ipc x 8 x efficienza cluster -> (ponendo ipc=1) Thuban 6, BD 8 x 90% = 7,2 (+20%) e non 8 (+33%).

EDIT: il 90% è solo a titolo indicativo qualora fosse più basso...

[Matalf]

Originariamente inviato da paolo.oliva2

Io suggerirei anche di riflettere su un altro punto, cioè sul fatto del brand FX AMD e di EE per Intel. Vediamo un po':

AMD Phenom I - Intel Core2 EE
AMD Phenom II X4 - Intel I7 X4 EE i7X6 EE
AMD Phenom II X6 - Intel i7 X6 EE

(premetto che Intel ancora commercializza i Core2 EE, ma ciò non vuole dire che l'offerta sia allettante per la clientela).

Il punto è... perché Intel non ha commercializzato SB come EE ed a prezzi da EE ma come K a prezzi di gran lunga più bassi? Perché Intel più volte ha detto che BD non va confrontato con gli i7 (X4 e X6) ma con SB?

Io non voglio con questo non voglio dire che BD sarà superiore a SB, ma di certo non trovo giustificato un così forte abbassamento prezzi (ed incassi) per il quale Intel non possa proporre un 2600K a 500€ e SB-e come EE.

In poche parole... in questa politica di prezzi di Intel, perlomeno a me sembra di vedere che sia la stessa Intel a prevedere potenze di BD tali da non giustificare prezzi da EE per versioni di SB.
Per spiegarmi meglio, un SB X6 tra IPC superiore e clock inferiore rispetto ad un i990X potrà proporre una potenza superiore si, ma abbastanza risicata. Mi sembra chiaro che se un BD X8 top di gamma potesse arrivare a potenze simili ad un i7 X6, nessuno sarebbe disposto per un 10% in più di potenza di SB rispetto ad un i7 X6 a spendere 3 volte di più...

Io la politica del listino Intel me la sono spiegata così... Se Intel stessa avesse la certezza che un BD X8 non arrivasse nemmeno ad un 2600K, non vedo il perché, visto la politica attuata da Intel negli ultimi anni, che lei sputi sopra a profitti ben ben più alti.

P.S.
Non ho l'intenzione, con questo post, né di confrontare prezzi tra le 2 case e tantomeno le potenze. L'ho scritto unicamente per portare una riflessione in più tra ottimismo-pessimismo, visto che comunque su Intel ne sappiamo molto di più di quanto trapela da AMD.

A me sembra fantascenza questa riflessione....

avessimo anche un incremento netto del 50% di prestazioni dal 1090T un ipotetico BDx8 a pari frequenza andrebbe comunque a rivaleggiare con il 2600k, la mancanza della sigla EE ed da interpretare solo come posizionamento di mercato, anche sul 1056 manca la nomenclatura EE ma nessuno se ne fa un dramma visto che non è un socket fascia alta, men che meno pensato per i server...

[digieffe]

Originariamente inviato da OEidolon

LOL ma copiate i commenti che ci sono su SA?! (sto scherzando, eh! non state a prendervela, che non ho alcun intento polemico )

battute a parte...mi spiegate dove sta il problema di questi (immensi) 315mm^2?

partendo dal considerare che un thuban è su 346mm^2, facendo poi dei conti spanning (cioè a spanne, senza alcuna pretesa scientifica, eh...), facendo finta di fare un thuban a 8c su sti benedetti 32nm:
thuban 6c 45nm 346mm^2 -> 8c 45nm 346x8/6=461mm^2
45nm -> 32nm 461x32/45=328mm^2
per confronto gulftown 6c 32nm è su 240mm^2 (8c diventerebbero 320mm^2, quindi siamo lì...)

tutto sommato, non mi pare che 315mm^2 siano chissà che eresia...il punto sta nel fatto che prestazionalmente ed economicamente siano competitivi, ma per vedere questo basta avere ancora un po' di pazienza...

Originariamente inviato da Veradun

I conti mi sembrano tutti giusti ma:
...cut

anche se arrivo un pò tardi i conti sono sbagliati (c'è un passaggio errato):
45nm -> 32nm 461x32/45=328mm^2
45nm -> 32nm 461x(32^2)/(45^2)=230mm^2
quindi BD sarebbe circa 1,37 volte un thuban 8 core (spannometricamente)
è da tener conto che BD avrebbe 4MB di cache l2 in più rispetto a Thuban, non so quanto possa occupare...

[blackshard]

Originariamente inviato da paolo.oliva2

Vedi... che BD debba avere una potenza superiore rispetto al Phenom è indubbio, ma la potenza di un procio non è data unicamente dall'IPC.

Ti faccio un esempio MOLTO pratico, addirittura dando per BD un IPC UGUALE al Phenom II:
Il Thuban a def raggiunge i 3,7GHz. BD dovrebbe raggiungere i 4,2-4,5GHz sempre a def.

Ora... un 20% di potenza in più la si avrebbe già con BD operativo a 4,440GHz, IPC o non IPC e questo in ambito ST.
Aggiungici il fatto che questo riguarderebbe unicamente l'ST, in quanto nell'MT in programmi tipo Cinebench il guadagno di un procio AMD è perfettamente lineare rispetto all'incremento dei core, e passare a X8 rispetto ad un X6 significherebbe +33% a parità di frequenza.

Quello che ti voglio dire, è che non è strettamente importante che BD arrivi all'IPC di un SB, perché comunque da parte sua avrebbe una frequenza maggiore oltre ad avere anche 2 core in più se non 4 con Komodo.
Il gioco al più rimarrebbe aperto quando Intel produrrà SB sul 22nm, in quanto probabilmente Intel potrà proporre frequenze superiori a quelle di SB sul 32nm.

Vedi... io sono molto più contento di avere informazioni (non ufficiali) di un BD X8 sui 300$ ed incognite sulla potenza piuttosto che sapere di un BD X8 FX a prezzi da FX (800-1000$) senza sapere nulla sulla potenza, perché comunque a quella cifra non lo acquisterei nemmeno se andasse il doppio di un SB-e X6, non so se mi capisci. Io al momento preferisco comunque aspettarmi incrementi anche solo del 20% di IPC accompagnati da 2 core in più e da frequenze più alte che comunque mi garantirebbero un prezzo/prestazioni più che soddisfacente.... Io mi tengo abbastanza certo che non sia di meno... se poi sarà di più... ben venga.

Allora, togliendo il discorso prezzo di mercato che non lo voglio fare, l'IPC serve e subito.
Il turbo è un bello specchietto per le allodole, ma NON è una soluzione definitiva perchè con lo scheduler di windows che fa saltare i processi da un core all'altro ne vanifica in gran parte l'efficacia.
Al contrario, IPC migliore sono prestazioni pure migliori.

Cosa succede nella realtà: due core della concorrenza + hyperthreading hanno performance paragonabili a tre/quattro core degli attuali K10. Ma ciò non va bene, perchè 4 core di AMD consumano un buon 50% in più di due core + hyperthreading.

Ripeto che, se si confrontano i consumi delle APU, questi sono davvero impietosi e sono un monito d'allarme per i 32nm di AMD. Una cosa che fa ben sperare sono gli interessanti margini in downvolt che si possono ottenere, ma attualmente la situazione sul mercato è che i nuovi chip AMD hanno TDP da 100 watt e performance per core di due generazioni indietro.

Questo grafico a me non va' proprio giù:



e se la differenza fra i3-2100 e a8-3850 non sembra essere troppa, bisogna anche considerare che l'i3 è decisamente più performante in diversi task.

Originariamente inviato da calabar

Ne ha decisamente bisogno, ma secondo me ci sono le premesse perchè possa dire la sua in ambito single thread.
Al di la delle migliorie generali, il nuovo turbo in questo senso dovrebbe dare ottimi risultati, così come ha fatto con la generazione nehalem per intel.
Per di più, se in un modulo BD la logica condivisa fa calare le prestazioni in multithread rispetto a due core completi (il famoso 80% dichiarato da amd), in single thread il solo core servito avrà una logica e un throughput sovrabbondante rispetto ad un core completo, tanto che potrebbe dargli una spintina in più, superando le prestazioni del core completo.

Guarda io vedo solo che il turbo su thuban non ha reso quello che doveva rendere. Quindi o il collo di bottiglia è altrove (tipo cache non sufficientemente veloci per stare dietro ad un core a 3.7 ghz) oppure semplicemente il turbo core non funziona a dovere, vuoi per una implementazione posticcia, vuoi per lo scheduler di windows, vuoi per altri motivi.

Sono proprio curioso di vedere come si comporterà il turbo core 2.0, però ripeto che non serve a niente avere un core a 5 ghz se poi non lo riesci a rifornire adeguatamente.

Molto interessante è questa prova di overclock/downvolt recensita qui:

http://www.zimbio.com/Laptop+Reviews...ed+Undervolted

In particolare nel caso del downvolt si riduce il consumo del sistema di ben 70 watt alla presa, che netti dell'efficienza dell'alimentatore e del VRM credo siano un buon 50 watt tolti al solo processore. Questo mi fa ben sperare.

[digieffe]

dalla immagine di semiaccurate ho ricavato le seguenti misure:

dimensioni del die: largh 20mm, alt. 15.76, area 315.24
dimensioni del modulo: largh 5.04, alt. 4.27, area 21.55
dimensioni del cache L2: largh 3.29, alt. 3.54, area 11.65

calcolerò anche la cache l3....

riuscite a confrontare questi valori con deneb/thuban/sb?

Ps:chiaro che ci possono essere degli errori trascurabili per via della misurazione in pixel

[Wawacco]

Originariamente inviato da AceGranger

con ivy non cambierai socket, il 2011, essendo quello professionale, dovrebbe farsi tranquillamente tick e tock; IB-E avra socket 2011, (non si è mai vista una piattaforma professionale non farsi almeno tick e tock, la 1366 è durata 3 anni) e concorrera con BD 2.

Mi sembra ovvio che parlando di ivy comparato al BD2 su FM2 intendevo su socket 2011

[gi0v3]

non so se er agià stato postato, xt review conferma i clock per fx-8120 e fx-8150



http://xtreview.com/addcomment-id-18...epping-B2.html

quindi
8120->3,1/4,0 ghz
8150->3,6/4,2 ghz

si è poi capito se il secondo clock è quello che ci dice il massimo clock raggiungibile su tutti i core o il massimo turbo su 4 core soli?

[FroZen]

Originariamente inviato da blackshard

Ripeto che, se si confrontano i consumi delle APU, questi sono davvero impietosi e sono un monito d'allarme per i 32nm di AMD. Una cosa che fa ben sperare sono gli interessanti margini in downvolt che si possono ottenere, ma attualmente la situazione sul mercato è che i nuovi chip AMD hanno TDP da 100 watt e performance per core di due generazioni indietro.

Questo grafico a me non va' proprio giù:



e se la differenza fra i3-2100 e a8-3850 non sembra essere troppa, bisogna anche considerare che l'i3 è decisamente più performante in diversi task.



Guarda io vedo solo che il turbo su thuban non ha reso quello che doveva rendere. Quindi o il collo di bottiglia è altrove (tipo cache non sufficientemente veloci per stare dietro ad un core a 3.7 ghz) oppure semplicemente il turbo core non funziona a dovere, vuoi per una implementazione posticcia, vuoi per lo scheduler di windows, vuoi per altri motivi.

Sono proprio curioso di vedere come si comporterà il turbo core 2.0, però ripeto che non serve a niente avere un core a 5 ghz se poi non lo riesci a rifornire adeguatamente.

Molto interessante è questa prova di overclock/downvolt recensita qui:

http://www.zimbio.com/Laptop+Reviews...ed+Undervolted

In particolare nel caso del downvolt si riduce il consumo del sistema di ben 70 watt alla presa, che netti dell'efficienza dell'alimentatore e del VRM credo siano un buon 50 watt tolti al solo processore. Questo mi fa ben sperare.

Stavo per scriverti che c'è gente qui che fa andare il 3850@def a 1,15V dai 1,4V originali e hai una vera APU, l'i3 arrossisce.......al di là del HT che mah non mi convince molto......sono anche io per il "real men uses real cores"

Certo è incredibile come si possa passare da 1,4 a 1,15V con tanta scioltezza.....o che in AMD abbiano avuto poco tempo per consolidare gli stress test e abbiano pompato voltaggi che alla luce di quanto sopra sono realmente TROPPO alti per avere margini di sicurezza decenti, avendo comunque un consumo buono per una APU....speriamo che con FX li facciano uscire con voltaggi più attinenti, ma non ci sarà alcun problema a downvoltare pure loro......certo che se arrivano a 4,2 sui 4 core gli servirà corrente....

[The3DProgrammer]

Originariamente inviato da calabar

Ne ha decisamente bisogno, ma secondo me ci sono le premesse perchè possa dire la sua in ambito single thread.
Al di la delle migliorie generali, il nuovo turbo in questo senso dovrebbe dare ottimi risultati, così come ha fatto con la generazione nehalem per intel.
Per di più, se in un modulo BD la logica condivisa fa calare le prestazioni in multithread rispetto a due core completi (il famoso 80% dichiarato da amd), in single thread il solo core servito avrà una logica e un throughput sovrabbondante rispetto ad un core completo, tanto che potrebbe dargli una spintina in più, superando le prestazioni del core completo.

In realta' non è cosi' e non puo' esserlo, purtroppo. Che sia single thread o multithread, ogni cluster int ha 2 ALU e 2 AGU e lo scheduler int (che non è condiviso) puo' schedulare massimo 4 op per ciclo di clock (una a pipeline). Di conseguenza, in single thread il throughtput massimo di BD è di 2 istruzioni per ciclo di clock, e non puo' essere maggiore di questa soglia. In MT, presumibilmente il throughput medio si abbassa a causa della logica condivisa che di fatto, limita le performance dei cluster int.

La risposta a queste domande è semplice.
SB EE semplicemente non è ancora uscito, gli attuali SB sono quelli di fascia mainstream , gli SB "pesanti" usciranno tra qualche mese e si chiameranno SB-E.
Vista l'attuale situazione, Intel si è potuta permettere di far uscire prima la fascia mainstream, che vende di più, e lasciare in fascia alta la vecchia generazione, che comunque la concorrenza non era in grado di raggiungere, mantenendo quindi il podio.
BD va confrontato con SB semplicemente perchè fanno parte della stessa "generazione". Del resto nehalem ha ormai tre anni, non pochi in ambito informatico.
Tutto qui.

secondo me la situazione ruota tutta intorno alle performance di BD in ST. Se in questa situazione BD sara' in grado, a parita' di clock, di mantenersi ai livelli di SB (diciamo in un range di + o - 5%) allora AMD potra' giocarsela, magari non subito ma sicuramente molto presto, con le soluzioni intel top di gamma. Se la differenza in ST dovesse essere + marcata (diciamo 15/20% a favore di SB) AMD potrebbe ancora essere competitiva puntando tutto sulle frequenze di clock, ma gia' questa non sarebbe una bella situazione perchè significherebbe dover tirare il collo a BD, con tutti gli svantaggi in termini di potenza dissipata conseguenti. Se la differenza dovesse essere ancora maggiore (ma onestamente dubito che possa essere cosi') allora sarebbe un fail e bisognerebbe attendere BD2 per avere qualcosa di veramente competitivo.

[Ares17]

Originariamente inviato da The3DProgrammer

In realta' non è cosi' e non puo' esserlo, purtroppo. Che sia single thread o multithread, ogni cluster int ha 2 ALU e 2 AGU e lo scheduler int (che non è condiviso) puo' schedulare massimo 4 op per ciclo di clock (una a pipeline). Di conseguenza, in single thread il throughtput massimo di BD è di 2 istruzioni per ciclo di clock, e non puo' essere maggiore di questa soglia. In MT, presumibilmente il throughput medio si abbassa a causa della logica condivisa che di fatto, limita le performance dei cluster int.

Tutto giusto con prefech identico a thuban (il famoso scemo + scemo di BJT2 ).

[Spitfire84]

Originariamente inviato da gi0v3

non so se er agià stato postato, xt review conferma i clock per fx-8120 e fx-8150



http://xtreview.com/addcomment-id-18...epping-B2.html

quindi
8120->3,1/4,0 ghz
8150->3,6/4,2 ghz

si è poi capito se il secondo clock è quello che ci dice il massimo clock raggiungibile su tutti i core o il massimo turbo su 4 core soli?

è un copia incolla dal blog di obr..certo che pubblicare una immagine di cpu-z con scritto sopra "crap is coming..."

[The3DProgrammer]

Perhaps everyone should consider that AMD did not release these benchmarks and they might not even be real. Nothing I have seen, to date, has been representational of actual performance.

post di JFAMD su XS

[calabar]

Originariamente inviato da blackshard

Il turbo è un bello specchietto per le allodole [...]
Guarda io vedo solo che il turbo su thuban non ha reso quello che doveva rendere. [...]

A me sembra che il turbo, a livello generale, funzioni abbastanza bene.
Persino quello di thuban, che per esempio nei giochi compete grazie ad esso con i phenom quad core a frequenza più spinta.
Nei nehalmen poi hanno portato un miglioramento davvero notevole (prova a cercare qualche recensione con e senza turbo attivo).
A questo punto non vedo perchè su BD il turbo debba essere inefficace. Quello di Thuban era un pezza per portarlo ad essere più competitivo nelle applicazioni che fanno uso di pochi thread a causa dell'elevato numero di core, ma in BD diventa una funzionalità con un altro livello di integrazione.

Su una cosa però sicuramente hai ragione: il turbo da solo non basta.
E fortunatamente, come dicevo sopra, è solo una delle carte che questo BD è in grado di giocare sul single thread.
Oltretutto con un ipc basso non c'è turbo che tenga: all'aumentare della frequenza il gap tra un processore con ipc elevato e uno con ipc più basso non fa altro che aumentare, per colmare questo gap con la frequenza bisogna raggiungere frequenze che, nonostante un progetto mirato i questo senso, diventano comunque troppo elevate per essere raggiunte.
Per capirci, se ho un prodotto con ipc=6 (numero a caso) a 4ghz, per raggiungere lo stesso risultato con un prodotto con ipc=4 devo raggiungere i 6ghz, traguardo a mio parere un po' troppo elevato da raggiungere (tenendo poi conto che anche il prodotto concorrente si clocca bene).

Morale della favola, serve in ogni caso una base consistente, o non c'è turbo ne frequenze alte che tengano.

Originariamente inviato da digieffe

data la struttura a cluster di BD, ipotizando un ipc uguale in ST con il Thuban, non credo affatto che l'8 core dia +33% rispetto al Thuban, in quanto ogni cluster avrà un throughput inferiore a 2 core Thuban (alla condizione specificata -> uguale ipc)

Esattamente. Vista la struttura di BD, un ipc in single core identico a thuban sarebbe a dir poco tragico.
Significherebbe che sfruttando tutti i core avremo il famoso calo all'80% dichiarato da AMD per la logica condivisa: BD rischierebbe di essere solo leggermente più veloce di thuban in multicore, ma con due core in più!

Originariamente inviato da The3DProgrammer

In realta' non è cosi' e non puo' esserlo, purtroppo. Che sia single thread o multithread, ogni cluster int ha 2 ALU e 2 AGU e lo scheduler int (che non è condiviso) puo' schedulare massimo 4 op per ciclo di clock (una a pipeline). Di conseguenza, in single thread il throughtput massimo di BD è di 2 istruzioni per ciclo di clock, e non puo' essere maggiore di questa soglia. In MT, presumibilmente il throughput medio si abbassa a causa della logica condivisa che di fatto, limita le performance dei cluster int.

Al di la dei particolari tecnici (per cui mi piacerebbe sentire anche qualche altra voce informata, per confronto), il discorso non mi torna affatto. Significherebbe che la logica condivisa non fa mai da collo di bottiglia in single thread, neanche nelle situazioni limite, e questo mi pare senza senso, perchè significa aver fatto una logica troppo castrata per servire due core, se poi tale sovrabbondanza non porta alcun seppur piccolo vantaggio quando il core utilizzato è uno solo. Vantaggio rispetto ad una logica studiata per un solo core in un approccio tradizionale, intendo.

[The3DProgrammer]

Originariamente inviato da calabar

Al di la dei particolari tecnici (per cui mi piacerebbe sentire anche qualche altra voce informata, per confronto), il discorso non mi torna affatto. Significherebbe che la logica condivisa non fa mai da collo di bottiglia in single thread, neanche nelle situazioni limite, e questo mi pare senza senso, perchè significa aver fatto una logica troppo castrata per servire due core, se poi tale sovrabbondanza non porta alcun seppur piccolo vantaggio quando il core utilizzato è uno solo. Vantaggio rispetto ad una logica studiata per un solo core in un approccio tradizionale, intendo.

Ma guarda che l'approccio di BD è tradizionalissimo eh. Potresti tranquillamente togliere il cluster int e la logica aggiunta per gestirlo (che fondamentalmente sono la fetch window e poco altro) ed avere comunque un design 4 way perfettamente bilanciato (4 decoder servono 8 unita di esecuzione, 4 int e 4 FP). Rispetto a questa ipotetica configurazione, l'aggiunta del secondo cluster int comporta una penalita' delle prestazioni (chiaramente intuibile, visto che ora 4 decoder servono 12 unita' di esecuzione invece di 8) quantificabile, secondo AMD, nel 20%. Non vedo come possa esserci un boost nel ST dato dal non utilizzare il secondo cluster int. Il colpaccio ci sarebbe stato se avessro trovato un modo di riutilizzare le ALU del secondo cluster int in ST, rendendo di fatto un modulo un mega cluster int in situazioni ST...

[calabar]

Originariamente inviato da The3DProgrammer

La logica aggiunta per gestire il secondo cluster int non da alcun vantaggio prestazionale quando non utilizzata.

Dovrebbe invece, dato che è condivisa, quindi in grado di servire entrambi i core. Nei casi limite ovviamente (in cui la logica fa da collo di bottiglia), dando quindi un piccolo aiuto, ma pur sempre un aiuto.

Per "approccio tradizionale" intendo naturalmente quello utilizzato finora con i phenom o i processori intel: non un modulo con due core e logica condivisa, ma un singolo core con la sua logica.

[The3DProgrammer]

Originariamente inviato da calabar

Dovrebbe invece, dato che è condivisa, quindi in grado di servire entrambi i core. Nei casi limite ovviamente, dando quindi un piccolo aiuto, ma pur sempre un aiuto.

Per "approccio tradizionale" intendo naturalmente quello utilizzato finora con i phenom o i processori intel: non un modulo con due core e logica condivisa, ma un singolo core con la sua logica.

ho editato il post precedente per errore invece di farne uno nuovo rileggi quello sopra per la risposta

[digieffe]

Originariamente inviato da The3DProgrammer

In realta' non è cosi' e non puo' esserlo, purtroppo. Che sia single thread o multithread, ogni cluster int ha 2 ALU e 2 AGU e lo scheduler int (che non è condiviso) puo' schedulare massimo 4 op per ciclo di clock (una a pipeline). Di conseguenza, in single thread il throughtput massimo di BD è di 2 istruzioni per ciclo di clock, e non puo' essere maggiore di questa soglia. In MT, presumibilmente il throughput medio si abbassa a causa della logica condivisa che di fatto, limita le performance dei cluster int.

..cut

A questo punto si dovrebbe supporre che l'ipc dei phenomII (con 3 pipeline int+agu e scheduler scemo+scemo) sia abbastanza inferiore a 2:
per poter avere BD un incremento del 20% di ipc, il PhenomII dovrebbe avere un ipc di 1.67... (1.67+20%=2) ?!? possibile così basso?

nessuno conosce l'ipc del PhenomII? (es nelle schede Amd/Ati serie 5870 l'ipc è di 3,4 su 5 unità,ma parliamo di una architettura vliw asimmetrica e non centra nulla, era solo per far capire che a volte si conoscono questi dati)

[calabar]

Il boost, seppure limitato, dovrebbe esserci proprio perchè se hanno calcolato che il decoder è sufficiente per gestire 2 core con una perdita di prestazioni contenuto, allora dovrebbe risultare almeno un po' "abbondante" per un solo core.
Se cioè avessero fatto un modulo con un singolo core, presumibilmente avrebbero bilanciato la minore capacità di calcolo con un decoder più limitato (se non sbaglio quello del k10 riesce a processare una istruzione in meno, infatti), perchè sarebbe inutile sprecare tanti transistor in una logica usata poi solo in casi estremi.
Ma se questa logica già c'è per servire un secondo core, allora tanto di guadagnato.

Sul fatto che il colpaccio sarebbe riuscire ad utilizzare le unità del secondo core sono d'accordo, ma se ne era già discusso, e al di la della difficoltà tecnica, mi pare non fosse tanto conveniente per due motivi:
- un'unità int difficilmente sfrutta più di tre pipeline, quindi non si avrebbe certo un raddoppio di prestazioni, ma un boost limitato.
- non potresti mettere a riposo il secondo core, avendo quindi consumi elevati che renderebbero impossibile l'uso del turbo core. In tal caso, si avrebbero più vantaggi dalla "fusione" o dall'aumento di frequenza?

[capitan_crasy]

Originariamente inviato da gi0v3

non so se er agià stato postato, xt review conferma i clock per fx-8120 e fx-8150



http://xtreview.com/addcomment-id-18...epping-B2.html

quindi
8120->3,1/4,0 ghz
8150->3,6/4,2 ghz

si è poi capito se il secondo clock è quello che ci dice il massimo clock raggiungibile su tutti i core o il massimo turbo su 4 core soli?

Lo chiedo a tutti:
Basta postare, una volta per tutte le porcate provenienti da quel mentecatto di Obrovsky: nel forum di xtremesystems.org sono stati bandite qualsiasi cosa che riguarda o prevenga da questo individuo...