[Thread Ufficiale] CPU serie FX: AMD Bulldozer/Piledriver - Aspettando Steamroller

[digieffe]

Originariamente inviato da paolo.oliva2

...
Quindi... l'enorme problema di AMD non è nella scalabilità di n moduli, quanto nella condivisione di 2 core all'interno del modulo.
Personalmente io credevo che AMD migliorasse la parallelizzazione dei moduli con Steamroller, evidentemente ho interpretato male, perchè non è certo il -1,5% dei moduli ad incrinare le performances di BD, quanto invece la parallelizzazione all'interno del modulo con i 2 core.

Ma sto cacchio di +30% (fino a) mi suona male, perchè da -20% al limite si potrà arrivare ad eliminare completamente quel -20%, ma è chiaro che non si potrà mai superare i 200 massimi teorici (100 1 core, 180 2 core, al max 200 2 core).

Che forse in quel fino al +30% si inglobi pure un aumento di IPC? Tipo 100 Piledriver, 110 Steamroller, 180 il modulo Piledriver, 234 il modulo Steamroller?

P.S.
So benissimo che ho fatto dei calcoli contorti... , ma almeno sono gli unici su cui potremmo fare teorie sia sulla pecca di Piledriver e sia su quanto potrebbe migliorare Steamroller.

L'ho già scritto mesi fa!

ci sono anche casi nei quali i due core di un modulo fanno 150% (vedi hardware.fr)
150 +30% = 195% (limite sostanzialmente invalicabile - è sempre un CMT -, i 200 sono molto teorici)

quindi il maggior guadagno si avrà dai programmi che scalano peggio sul modulo, mentre quelli che già fanno 180+ avranno un guadagno risicato 5-8%.

tutto ciò indipendentemente dall'IPC, che immagino possa avere un aumento dal 5 al 10%.

[digieffe]

Originariamente inviato da paolo.oliva2

Secondo me... un X10 darebbe un po' di più ma aumenterebbe i costi più delle performances maggiori ottenute (un +20% di die contro un +6% di performances a parità di consumo), un X12 garantirebbe un +30% ma con un costo die del +50% ed entrambi suppergiù con potenze da 8150 in ambito desktop ST/gioco max 3-4TH, ma ambedue con un costo produzione maggiore percentualmente rispetto all'aumento di potenza... Lo so che è tutto a spannella, anche perchè teoricamente un 8350 forse già potrebbe arrivare a 4,2GHz def nei 125W (variando da 1,38V def a 1,3V, già si arriverebbe a 4,4GHz addirittura con un TDP inferiore), quindi un X10 probabile che possa funzionare a 3,6GHz circa come 125W TDP, ma rimarrebbe pur sempre più competitivo per prezzo/prestazioni un X12 rispetto ad un X10. Mi sembra chiaro che nell'attuale posizione AMD vende meglio un 8350 a 180€ che un teorico X12 a 270€ (meglio 300€) seppur più potente del 30% rispetto ad un 8350, ma probabilmente c'è un livello minimo di potenza (quella a core) oltre il quale non si può andare, e 3,4GHz circa sono troppo pochi per l'IPC di BD.

i tuoi calcoli a spannella li avevo fatti pure io: la sera invece di contare le pecore per prendere sonno, faccio calcoletti a spannella che conciliano il sonno .


Un 6 moduli a frequenza più bassa renderebbe qualche punto % di più, però ad un costo del silicio + o - come hai calcolato tu.

Anche uno Steamroller 4 moduli su SOI 32nm, renderebbe di più, non ti riporto i calcoli, ti do le ipotesi: aumento di potenza medio 15/20% tra IPC e +30% (mops) con implicazione di aumento del consumo del ~20% (approssimativamente quanto le performance).

Partendo dai 4ghz del 8350, per steamroller sarebbe necessario un abbassamento della frequenza base a 3.6 per restare nei 125W (ricordati che il consumo è da calcolare al quadrato).
3.6ghz + 15/20% (aumento perf.) = 4.14/4.32 (senza considerare il turbo, che per ipotesi da vantaggi identici)

Insomma uno steamroller @3.6 125W potrebbe dare vantaggi a 32nm SOI pari ad un 8350 @ 4.2/4.3 (5-8%). Ora anche se questa ipotesi fosse reale può AMD spendere per tutto il processo di realizzazione ecc, solo per un guadagno del 5-8% ???

e se poi uscisse qualche intoppo che costringa a limare la frequenza di 200mhz, si ritroverebbero con le stesse prestazioni? come ammortizzerebbero i costi? IMHO troppo rischioso ed inutile.


Ps: tutte queste ipotesi sono a parità di vcore e silicio (senza fare calcoli con vcore striminziti da utente appassionato)

[paolo.oliva2]

Però in ambedue i casi ci sarebbe pure da considerare un fatto: AMD ha pagato a GF delle penali perchè la produzione di BD (non ricordo se con Zambesi o inizio Piledriver) non ha raggiunto i volumi come da contratto.
Presumibilmente, credo che il calcolo lo si faccia a wafer, non a die, perchè a seconda della grandezza del die varierebbe il numero occorrente di wafer.
Produrre un X12 significherebbe un numero maggiore di wafer a parità di volume di die rispetto a degli X8, quindi se da una parte ci sarebbero meno utili, dall'altra non avrebbe in teoria pagato penali (da considerare che se questa situazione si fosse verificata agli inizi del 2013, un Piledriver X12 avrebbe di per sè sopportato molto meglio il mercato anche fino al 2015 rispetto ad un Piledriver X8 oramai alla frutta (vedremo Varsavia).
In secondo caso, AMD subisce un danno sia di immagine che commerciale per il fatto che gli FX sia ST che MT stiano sotto agli Haswell e IVY X4. All'epoca Phenom II, il Thuban X6 anche avendo lo stesso IPC, non superava gli Intel in ST, ma aumentando da X4 a X6 otteneva una potenza MT superabile unicamente da un i7 32nm X6, ed abbiamo visto che le vendite del Thuban erano più che soddisfacenti.
Realizzare già solamente un X10 vorrebbe dire superare gli X4 Intel in MT, e chi valuta l'acquisto del procio in base a specifiche esigenze MT, vedrebbe non più un X4 Intel come antagonista di un FX ma un 2011, oltre che chiaramente si avrebbe un ritorno pure con gli Opteron, perchè una potenza superiore a parità di consumo la si avrebbe pure con un X24 vs X16.

A mio parere una decisione commerciale definitiva non è stata presa sul numero dei moduli max di Piledriver non tanto per possibilità silicio in sè o per calcoli sugli effettivi guadagni, ma unicamente perchè c'era la carta Steamroller FX e forse pure un FD-SOI, tra l'altro comunque per le road-map vecchie Steamroller figurava, come figurava pure un aumento del numero dei core, quindi di per sè la volontà c'era.
Cioè... facendo un esempio... se il 28nm FD-SOI avrebbe permesso un Piledriver X12 a 4GHz (a caso), è chiaro che AMD scarterebbe la produzione di un X12 32nm SOI per farlo sul 28nm FD-SOI, come pure avrebbe abbandonato sempre un X12 Piledriver a favore di un Steamroller X8 che avrebbe ottenuto una potenza massima simile ma con un die un tot più piccolo.
Stessa logica... incremento IPC non vuole dire per forza procio più potente, perchè in definitiva l'aumento di potenza di qualsiasi architettura alla fin fine si riduce in un TDP prodotto inferiore a parità di potenza elaborativa e di qui l'aumento di potenza finale perchè minor TDP = o più transistor (potenziamento parte logica o aumento dei moduli) o frequenze operative più alte. Se un 32nm SOI non riuscisse a sfruttare pienamente Steamroller, il guadagno si ridurrebbe.

Steamroller è prodotto sul Bulk per gli APU, quindi comporterebbe un lavoro più pesante ad esempio di un trasbordo sullo stesso silicio ma con miniatura differente... e come hai scritto tu, se il 32nm SOI non permettesse un Steamroller X8 alle frequenze di un Piledriver X8, l'aumento IPC svanirebbe proporzionatamente alla perdita di frequenza operativa, e di qui i vantaggi rispetto ai costi e quindi l'utilità/fattibilità.

Ma infatti è per questo che io ipotizzerei un salto ad Exavator senza Steamroller su FX/Opteron, perchè se l'architettura Exavator fosse ultimata un 6 mesi almeno prima della disponibilità di un nuovo silicio più performante, realizzare il trasbordo di un Steamroller Bulk sull'FD-SOI costerebbe tale ed uguale a realizzare un Exavator FX direttamente sull'FD-SOI. Anzi, se l'APU Exavator previsto per il 2015 venisse prodotto sull'FD-SOI anzichè sul Bulk (e non c'è nessuna info mi sembra su quale silicio si userà per il next-next APU), la spesa realizzazione APU/FX-Opteron sarebbe condivisibile a livello modulo/MC = meno spesa. Che senso avrebbe spendere di più per realizzare un prodotto FX/Opteron meno potente?
Tra l'altro... secondo me, sempre se si confermeranno le aspettative APU viste come IGP/X86 unite per elaborare i dati, e forse un dopo Exavator lo potrebbe permettere sia come tempistica dell'evoluzione architetturale che come disponibilità miniaturizzazione silicio < di 20nm, avere un FX/Opteron al passo con gli APU sarebbe una condizione ideale per un APU FX/Opteron, cosa non possibile o comunque richiederebbe tempi maggiori nel caso di un FX/Opteron indietro di una architettura.

[paolo.oliva2]

@Digieffe
Ti do delle info su cui si potrebbero fare supposizioni.

Ho provato a confrontare il comportamento dell'8350 sempre con 4 core attivi, ma da una parte su 2 moduli e dall'altra su 4 moduli e c'è un comportamento contorto...

Nel complessivo 4 core su 4 moduli rende molto meglio nel range tra 1 applicazione e 2, ma a 3 s'ingrippa, mentre 4 core su 2 moduli da risultati inferiori ma tiene tranquillamente 3 applicazioni e arriva a 4. Sarebbe come se un 8350 con 1 core a modulo sia più potente di un 4350 X4 (2 moduli), ma nel contempo l'FX X4 supporterebbe meglio carichi gravosi pur avendo una L2 di 4MB rispetto a 8MB di un 4 moduli con 1 core a modulo....

Non riesco ad unire il fatto che il CMT, non ancora pienamente ottimizzato, da una parte produca potenze massime inferiori e dall'altra consenta carichi più intensivi... non sarebbe un controsenso?

P.S. Edit
Tra l'altro mi ritrovo pure la stessa situazione del Vcore inferiore con 1 core a modulo vista sulla CF V, non so se ti ricordi, 1,525V per @5,3GHz. Con 1 core a modulo su 4 moduli tengo 4,2GHz a 1,25V. Comincio a pensare, visto che AMD utilizza gli emulatori per simulare il funzionamento del procio, su carta era effettivamente possibile l'aspettativa di IPC e frequenze, ma che poi il silicio non ha permesso quello che su carta si sarebbe dovuto raggiungere. D'altronde non è strano questa differenza di Vcore? Vcore maggiore = TDP maggiore, TDP maggiore = frequenze massime inferiori e numero di core non aumentabile.

[digieffe]

Originariamente inviato da paolo.oliva2

@Digieffe
Ti do delle info su cui si potrebbero fare supposizioni.

Ho provato a confrontare il comportamento dell'8350 sempre con 4 core attivi, ma da una parte su 2 moduli e dall'altra su 4 moduli e c'è un comportamento contorto...

Nel complessivo 4 core su 4 moduli rende molto meglio nel range tra 1 applicazione e 2, ma a 3 s'ingrippa, mentre 4 core su 2 moduli da risultati inferiori ma tiene tranquillamente 3 applicazioni e arriva a 4. Sarebbe come se un 8350 con 1 core a modulo sia più potente di un 4350 X4 (2 moduli), ma nel contempo l'FX X4 supporterebbe meglio carichi gravosi pur avendo una L2 di 4MB rispetto a 8MB di un 4 moduli con 1 core a modulo....

Non riesco ad unire il fatto che il CMT, non ancora pienamente ottimizzato, da una parte produca potenze massime inferiori e dall'altra consenta carichi più intensivi... non sarebbe un controsenso?

dovrei almeno sapere con quali applicazioni e cosa intendi per s'ingrippa...
insomma un contesto un po' più definito.

[isomen]

Originariamente inviato da paolo.oliva2

@Digieffe
Ti do delle info su cui si potrebbero fare supposizioni.

Ho provato a confrontare il comportamento dell'8350 sempre con 4 core attivi, ma da una parte su 2 moduli e dall'altra su 4 moduli e c'è un comportamento contorto...

Nel complessivo 4 core su 4 moduli rende molto meglio nel range tra 1 applicazione e 2, ma a 3 s'ingrippa, mentre 4 core su 2 moduli da risultati inferiori ma tiene tranquillamente 3 applicazioni e arriva a 4. Sarebbe come se un 8350 con 1 core a modulo sia più potente di un 4350 X4 (2 moduli), ma nel contempo l'FX X4 supporterebbe meglio carichi gravosi pur avendo una L2 di 4MB rispetto a 8MB di un 4 moduli con 1 core a modulo....

Non riesco ad unire il fatto che il CMT, non ancora pienamente ottimizzato, da una parte produca potenze massime inferiori e dall'altra consenta carichi più intensivi... non sarebbe un controsenso?

Probabilmente sopportare carichi pesanti anche superiori al 100% teorico é una prerogativa del modulo nella sua interezza, mentre disattivandogli un core nn perde più la percentuale x che perde con la condivisione ma torna ad essere simile ad un core classico... cmq é scontato che il modulo ha un ipc più basso ma un'efficenza più alta del core intel + ht e se amd riuscisse ad alzarlo diventerebbero dei mostri sotto ogni aspetto... ma al momento questa é fantainformatica

[paolo.oliva2]

Originariamente inviato da isomen

Probabilmente sopportare carichi pesanti anche superiori al 100% teorico é una prerogativa del modulo nella sua interezza, mentre disattivandogli un core nn perde più la percentuale x che perde con la condivisione ma torna ad essere simile ad un core classico... cmq é scontato che il modulo ha un ipc più basso ma un'efficenza più alta del core intel + ht e se amd riuscisse ad alzarlo diventerebbero dei mostri sotto ogni aspetto... ma al momento questa é fantainformatica

Quoto.

Comunque, rispondendo a Digieffe, è come se, postando dati così, 4 core su 2 moduli dassero 100 e 4 core su 4 moduli dassero 120, ma mentre i 4 core su 2 moduli in un certo senso arriverebbero a 120 stracaricandolo, i 4 core su 4 moduli si comporterebbero stile Thuban, cioè aumentando il carico i 120 passerebbero per dire a 115 nel complessivo.

[carlottoIIx6]

Originariamente inviato da isomen

Probabilmente sopportare carichi pesanti anche superiori al 100% teorico é una prerogativa del modulo nella sua interezza, mentre disattivandogli un core nn perde più la percentuale x che perde con la condivisione ma torna ad essere simile ad un core classico... cmq é scontato che il modulo ha un ipc più basso ma un'efficenza più alta del core intel + ht e se amd riuscisse ad alzarlo diventerebbero dei mostri sotto ogni aspetto... ma al momento questa é fantainformatica

potrebbe essere un problema di avere spazio a disposizione.

mi spiego, amd a condiviso parte delle cose tra i core nel mudulo.
se disattivi il core nel mudulo le cose condivise rimangono adispozione di un core che ha meno problemi, ma ci sono meno opportunità di smistare il traffico:
e come essere ne traffico autstradale e avere 4 vie larghe senza sbarra o averne 8 con sbarra, quando il traffico aumenta è meglio averne 8 anche se qualche volta si aspetta un po che la sbara si alzi.

[paolo.oliva2]

Originariamente inviato da carlottoIIx6

potrebbe essere un problema di avere spazio a disposizione.

mi spiego, amd a condiviso parte delle cose tra i core nel mudulo.
se disattivi il core nel mudulo le cose condivise rimangono adispozione di un core che ha meno problemi, ma ci sono meno opportunità di smistare il traffico:
e come essere ne traffico autstradale e avere 4 vie larghe senza sbarra o averne 8 con sbarra, quando il traffico aumenta è meglio averne 8 anche se qualche volta si aspetta un po che la sbara si alzi.

Ti copio l'esempio .

Se si arrivasse ad una autostrada a 4 corsie, una con ogni corsia "chiusa", l'altra a corsie libere, in quella a corsia unica si terrebbe, volenti o nolenti, sempre la medesima corsia, nell'altra libera, praticamente si andrebbe a zig-zag ed alla fine si farebbe più strada.

Io penso che il saltello dei TH non influisce (o influisce minimamente) se da 1 modulo si passa a 4. Non ho provato (ma lo posso fare) ma a naso se imposto l'affinità sul 1° e 3° core, avrei un saltello da modulo a modulo, ma a me non sembra di vedere un calo di prestazioni.
Ad esempio quelle patch per risolvere il problema rendevano unicamente nella condizione >4 core <8 core, cioè quando si verificherebbe la condizione di 2 core funzionanti a modulo.

A fantasia, potrei supporre che l'architettura CMT non soffra per quanto riguarda la condivisione di parti intesa come riduzione complessiva delle unità logiche a core, quanto invece nello smistamento vero e proprio dei dati.
Se considerassimo per un attimo il modulo come 1 core con L2, fondamentalmente il saltello dei TH sarebbe tale e quale a un procio multicore tradizionale.

Supponiamo che l'SO faccia il suo saltello dei TH a core con un minimo di logica... cioè quando la Pipeline ha elaborato interamente i dati e non ne ha ricevuto altri, quindi i risultati dalla L1 tornano alla L2 e di qui passerebbero al prox core.

Che probabilità ci sarebbe in un modulo con 2 core che la pipeline del 1° core finisca di passare i dati contemporaneamente alla Pipeline del 2° core? Ed in questo caso che si farebbe? Il core libero aspetta (e quindi fa dei cicli senza elaborare). Intendiamoci, faccio ipotesi per quanto ne so io di come funzia un procio dentro, quindi a livello basso... i guru siete voi .
Inoltre, ipotizzandone il funzionamento, il 3° e 4° core del modulo 2 ipotizzerei faccia questo:
il 3° core passa i dati al 4°, il 4° core passa i dati al modulo successivo ed il 2° core del 1° modulo passerebbe i dati al 3° core.
In un procio multicore praticamente avremmo che i core sarebbero "vuoti" e caricherebbero da zero. Nel modulo AMD per forza di cose, essendoci 1 sola FPU e una L2 che alimenta 2 proci, ci dovrebbe essere una sorta di priorità dei dati a seconda di quale core servire... ma quando 1 core non passerebbe più, queste priorità come si comporterebbero? Se 1 dato dovesse entrare per 3°... ed il core che non lavora più occupava il 1° ed il 2° posto... i dati nuovi andrebbero nel 1° o 2° posto che sarebbe libero o si accoderebbero al 3°? Quindi il 3° farebbe dei cicli a vuoto aspettando che i dati passino al 2° posto e poi al 1°?

Sempre con il tuo esempio dell'autostrada , è come se io scegliessi la 1° corsia a sinistra e poi dovessi uscire di colpo... è chiaro che le macchine (o i dati) dovrebbero rallentare per farmi passare.

Condivido con isomen che l'architettura CMT avrebbe un potenziale enorme, ma comunque deve lavorare come un orologio perchè renda... ed onestamente sono passati 3 anni ormai da Zambesi... Quello di positivo è che l'ossatura c'è, visto che con 1 core disattivato a modulo si ha un IPC superiore a quello di un Phenom II con il vantaggio di un clock superiore almeno del 20% di media... quindi potenzialmente un CMT che faccia bene il suo lavoro dovrebbe portare senza interventi di potenziamento delle parti logiche, ad un +20% a parità di core vs un Phenom II a cui si aggiungerebbe il +25% di core (un X8 vs max X6 del Thuban), che dovrebbe portare in teoria un Piledriver ad un +50% nei confronti del Thuban.

Cioè... tanto si analizza il problema senza certamente affermare che domani un 8350 sarebbe più potente di un 40% rispetto all'attuale... ma il CMT praticamente condividerebbe la L2 e l'FP, con una L2 che è di 2MB per 2 core, contro quella del Phenom II che era 512KB per ogni core, quindi come INT un core BD dovrebbe avere nè più nè meno le potenzialità di quello di un Phenom II (di certo superiori visto i set di istruzioni nuove), e mi sembrerebbe scontato che AMD, rifacendo una architettura interamente nuova, abbia lesinato sui transistor della FPU, che poi, tra l'altro, mi sembrava di aver sentito che le istruzioni FP sarebbero di media meno del 30% del totale, quindi se proprio fosse la FPU il problema, al più NON si potrebbe superare un -30% di performances, non di certo un -50%.
Per il discorso della lunghezza delle pipeline, mi sembra chiaro che se io faccio lavorare 1 core a modulo ed ottengo un IPC superiore rispetto al funzionamento di 2 core o anche di 1 core ma con l'altro disattivato con l'affinità (e non escluso da bios), non ho mica variato la lunghezza della Pipeline.

Ecco qua uno screen del cesso della mia mobo a @4,8GHz come X2 con Vcore 1,464V, ma dovrei starci anche a 1,4-1,42V, ma l'alimentazione di sta mobo non brilla di certo per stabilità...
Il mio 8350 voleva 1,45V per 4,6GHz come X8 (con una CF V 8+2 fasi), con 1 core a modulo (e con una mobo a 3 fasi) ottengo +200MHz impostando lo stesso Vcore, e se non ballasse potrei arrivare a 1,425V sicuramente.

[carlottoIIx6]

quel che è sicuro è che con steam la sbarra sarà più tempo altazate che abbassata, e questo fa salire di molto le prestazioni in multi.
ci avviciniamo di più ad 8 vie vere ovvero un vero x8.
qualche miglioria di ipc e frequenza e le prestazioni si lazeranno sopratutto in multi.

@paolo nota anche ora un phenom perde con gli fx se le istruzioni sonos sfruttate tutte. se un fx x8 la barra sta abbassata un 25% delle volte (stima esagerata) e dopo 0% è come se si avvesse un modulo in più attuale. quindi la strada mettere meno hardware condiviso è alternativa ad aggiungere più core, ma sicuramente con meno spesa silicio.

ps vorrei distinguere alcune cose, multi è un termine generico di intendere almeno tre cose imo:

1) software parallelizzato, 2)multi task interno al programma 3) multi task esterno (lanciare vari programmi).

un softeware è parallelizzato quando un calcolo si può dividere in tanti rami indipendenti che concorrono poi al medesimo risultato.
un multi task è quanto il programma fa tante cose diverse e indipendenti e le divide per i core che ha a disposizione ecc.

questa distinzione serve per capire l'evoluzione imo.
ovvero i giochi di ora sono massimo da multi task e non sono parallelizati.
mi aspetto la parallelizazione nell'immediato futuro.

[feldvonmanstein]

Originariamente inviato da paolo.oliva2

Ti copio l'esempio .

Se si arrivasse ad una autostrada a 4 corsie, una con ogni corsia "chiusa", l'altra a corsie libere, in quella a corsia unica si terrebbe, volenti o nolenti, sempre la medesima corsia, nell'altra libera, praticamente si andrebbe a zig-zag ed alla fine si farebbe più strada.

Io penso che il saltello dei TH non influisce (o influisce minimamente) se da 1 modulo si passa a 4. Non ho provato (ma lo posso fare) ma a naso se imposto l'affinità sul 1° e 3° core, avrei un saltello da modulo a modulo, ma a me non sembra di vedere un calo di prestazioni.
Ad esempio quelle patch per risolvere il problema rendevano unicamente nella condizione >4 core <8 core, cioè quando si verificherebbe la condizione di 2 core funzionanti a modulo.

A fantasia, potrei supporre che l'architettura CMT non soffra per quanto riguarda la condivisione di parti intesa come riduzione complessiva delle unità logiche a core, quanto invece nello smistamento vero e proprio dei dati.
Se considerassimo per un attimo il modulo come 1 core con L2, fondamentalmente il saltello dei TH sarebbe tale e quale a un procio multicore tradizionale.

Supponiamo che l'SO faccia il suo saltello dei TH a core con un minimo di logica... cioè quando la Pipeline ha elaborato interamente i dati e non ne ha ricevuto altri, quindi i risultati dalla L1 tornano alla L2 e di qui passerebbero al prox core.

Che probabilità ci sarebbe in un modulo con 2 core che la pipeline del 1° core finisca di passare i dati contemporaneamente alla Pipeline del 2° core? Ed in questo caso che si farebbe? Il core libero aspetta (e quindi fa dei cicli senza elaborare). Intendiamoci, faccio ipotesi per quanto ne so io di come funzia un procio dentro, quindi a livello basso... i guru siete voi .
Inoltre, ipotizzandone il funzionamento, il 3° e 4° core del modulo 2 ipotizzerei faccia questo:
il 3° core passa i dati al 4°, il 4° core passa i dati al modulo successivo ed il 2° core del 1° modulo passerebbe i dati al 3° core.
In un procio multicore praticamente avremmo che i core sarebbero "vuoti" e caricherebbero da zero. Nel modulo AMD per forza di cose, essendoci 1 sola FPU e una L2 che alimenta 2 proci, ci dovrebbe essere una sorta di priorità dei dati a seconda di quale core servire... ma quando 1 core non passerebbe più, queste priorità come si comporterebbero? Se 1 dato dovesse entrare per 3°... ed il core che non lavora più occupava il 1° ed il 2° posto... i dati nuovi andrebbero nel 1° o 2° posto che sarebbe libero o si accoderebbero al 3°? Quindi il 3° farebbe dei cicli a vuoto aspettando che i dati passino al 2° posto e poi al 1°?

Sempre con il tuo esempio dell'autostrada , è come se io scegliessi la 1° corsia a sinistra e poi dovessi uscire di colpo... è chiaro che le macchine (o i dati) dovrebbero rallentare per farmi passare.

Condivido con isomen che l'architettura CMT avrebbe un potenziale enorme, ma comunque deve lavorare come un orologio perchè renda... ed onestamente sono passati 3 anni ormai da Zambesi... Quello di positivo è che l'ossatura c'è, visto che con 1 core disattivato a modulo si ha un IPC superiore a quello di un Phenom II con il vantaggio di un clock superiore almeno del 20% di media... quindi potenzialmente un CMT che faccia bene il suo lavoro dovrebbe portare senza interventi di potenziamento delle parti logiche, ad un +20% a parità di core vs un Phenom II a cui si aggiungerebbe il +25% di core (un X8 vs max X6 del Thuban), che dovrebbe portare in teoria un Piledriver ad un +50% nei confronti del Thuban.

Cioè... tanto si analizza il problema senza certamente affermare che domani un 8350 sarebbe più potente di un 40% rispetto all'attuale... ma il CMT praticamente condividerebbe la L2 e l'FP, con una L2 che è di 2MB per 2 core, contro quella del Phenom II che era 512KB per ogni core, quindi come INT un core BD dovrebbe avere nè più nè meno le potenzialità di quello di un Phenom II (di certo superiori visto i set di istruzioni nuove), e mi sembrerebbe scontato che AMD, rifacendo una architettura interamente nuova, abbia lesinato sui transistor della FPU, che poi, tra l'altro, mi sembrava di aver sentito che le istruzioni FP sarebbero di media meno del 30% del totale, quindi se proprio fosse la FPU il problema, al più NON si potrebbe superare un -30% di performances, non di certo un -50%.
Per il discorso della lunghezza delle pipeline, mi sembra chiaro che se io faccio lavorare 1 core a modulo ed ottengo un IPC superiore rispetto al funzionamento di 2 core o anche di 1 core ma con l'altro disattivato con l'affinità (e non escluso da bios), non ho mica variato la lunghezza della Pipeline.

Ecco qua uno screen del cesso della mia mobo a @4,8GHz come X2 con Vcore 1,464V, ma dovrei starci anche a 1,4-1,42V, ma l'alimentazione di sta mobo non brilla di certo per stabilità...
Il mio 8350 voleva 1,45V per 4,6GHz come X8 (con una CF V 8+2 fasi), con 1 core a modulo (e con una mobo a 3 fasi) ottengo +200MHz impostando lo stesso Vcore, e se non ballasse potrei arrivare a 1,425V sicuramente.

non è che 2 core su un modulo sono più fluidi di 2 core su due moduli pur avendo prestazioni assolute inferiori proprio per la condivisione della cache l2?
in caso di saltellio dei TH i dati in essa contenuti nn dovrebbero essere ricopiati o comq la comunicazione tra le 2 unità logiche comporta latenze inferiori dato che sono vicinissime. sbaglio o c'è del vero?

[N@meZ]

Signori vale la pena prendere una saber r 2.0 e togliermi la ud3 990fx rev3 per poi cercare di spremere questo 8350?
Ho trovato sul mercatino una saber rev1 ma vorrei mettere su almeno una r2.
Che ne pensate?

Inviato dal mio GT-I9505 con Tapatalk 2

[paolo.oliva2]

Si... per quanto ho visto e per quanto riesco a capirne, il problema "grosso" è nel modulo e non tra i moduli. Ci deve essere un qualche cosa di più... perchè se fosse solamente un discorso di 1 core o 2 core a modulo, direi che se il 2° core fosse disattivato da bios o lasciato inattivo tramite l'affinità, dovrebbe dare lo stesso risultato.
In questo ci viene d'aiuto il Vcore... se si disattiva il 2° core da bios, il Vcore richiesto dal modulo cala di un -0,05V, mentre con l'affinità non cambia una mazza.
Se interpretassimo questa differenza di Vcore non tanto per le parti logiche del 2° core quanto invece per la parte di smistamento dei dati, è chiaro che l'aumento di IPC verrebbe fuori unicamente perchè i dati arriverebbero direttamente al core senza una parte che si interesserebbe di smistare i dati tra 2 core.

Ho fatto delle ulteriori prove incrociate... ma non intensive perchè non posso correre il rischio di rimanere a piedi (ho solo questa mobo).
Come X4, che sia 1 core a modulo o 2 core a modulo, la frequenza max raggiungibile è simile (la mia mobo non supporta >95W TDP).
Ma come X4 con 1 core a modulo riesco a stare a -0,05V rispetto a 2 core a modulo alla stessa frequenza.
Ma c'è una cosa che mi sorprende. Come X4 dovremmo avere consumi superiori se quisti sono su 4 moduli anzichè 2, perchè 4MB di L2 funzionanti alla stessa frequenza del core dovrebbero consumare di più rispetto alla sola parte che si occuperebbe di smistare i dati ad un core o all'altro (situazione modulo con 2 core). E poi perchè aumenterebbe la richiesta di Vcore con 2 core anzichè 1 a modulo? Una vecchia regola di elettronica dice che quando si hanno consumi superiori, qualche cosa non sta lavorando bene.

[carlottoIIx6]

http://www.tomshw.it/cont/articolo/a...x/48438/1.html

[N@meZ]

Originariamente inviato da carlottoIIx6

http://www.tomshw.it/cont/articolo/a...x/48438/1.html

grazie carlotto.
Ho sempre avuto asus di un certo livello e sinceramente mi piacciono molto di piu.
Per la sabertooth rev1 o rev2?

Per carità la gigabyte va bene ed è fresca. Ma sono abituato ad asus e voglio quella. La C5F non la voglio prendere, costa troppo

[paolo.oliva2]

Originariamente inviato da N@meZ

Signori vale la pena prendere una saber r 2.0 e togliermi la ud3 990fx rev3 per poi cercare di spremere questo 8350?
Ho trovato sul mercatino una saber rev1 ma vorrei mettere su almeno una r2.
Che ne pensate?

Inviato dal mio GT-I9505 con Tapatalk 2

Dipende quanta frequenza vuoi di più rispetto a quella che hai già.
E' difficile darti una risposta perchè dipende da che hardware hai e per cosa lo usi... tanto per i giochi conta unicamente la VGA per configurazioni "normali"... per un uso MT da 4,4GHz a 4,6GHz rappresenterebbe meno del 5% in più... oltre bisogna vedere che sistema di dissipazione hai, perchè 8 core a 4,8/5GHz certamente frullano ma scaldano un tot... e dovresti avere il liquido oltre i 5GHz...

Conviene?

[gyonny]

Non vorrei andare in OT ma comunque una bella scheda madre per gli FX è anche la Asrock 990FX EXTREME9

[N@meZ]

Originariamente inviato da paolo.oliva2

Dipende quanta frequenza vuoi di più rispetto a quella che hai già.
E' difficile darti una risposta perchè dipende da che hardware hai e per cosa lo usi... tanto per i giochi conta unicamente la VGA per configurazioni "normali"... per un uso MT da 4,4GHz a 4,6GHz rappresenterebbe meno del 5% in più... oltre bisogna vedere che sistema di dissipazione hai, perchè 8 core a 4,8/5GHz certamente frullano ma scaldano un tot... e dovresti avere il liquido oltre i 5GHz...

Conviene?

Grazie della risposta paolo.
come target minimo vorrei arrivare a 4.8. L'unica cosa che non mi sta bene e non poter fare oc manuale e smanettare come dico io. Adesso con l'h80i non supero i 52 gradi in full con linx (ventole non su performance). Credo di avere ancora buon margine se l'esperienza non mi inganna. Calcola che prima di attivare LLC a scarsi 1.35v stava a 4.4 come ora Rs. Con llc ho circa 1.38. Credo di poter rimanere sotto la temp di soglia anche con 1.4/1.45 considerando il caldo di ora. Dovrebbero bastare per 4.8, ma voglio una mb che non scazzi troppo sul vcore. Con questa non ho provato ma sono sempre piu convinto sulla saber r2.0

Originariamente inviato da gyonny

Non vorrei andare in OT ma comunque una bella scheda madre per gli FX è anche la Asrock 990FX EXTREME9

Bella davvero bella.
Pero a quel punto ci metto 15&euro; e vado sulla c5f.

Vorrei prendere una scheda di fascia alta ch3 cmq mi garantisca una buona rivendibilitá senza doverla svalutare troppo.


Inviato dal mio GT-I9505 con Tapatalk 2

[carlottoIIx6]

Originariamente inviato da gyonny

Non vorrei andare in OT ma comunque una bella scheda madre per gli FX è anche la Asrock 990FX EXTREME9

sembrerebbe avere migliori consumi idle, che non è male.

[RedPrimula]

Cpu arrivata e montata! Ora formatto tutto e inizio coi vari test