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

[cionci]

Il tuo discorso in certi casi può andare in altri no, dipende tutto dal tipo di carico che esegui. Se esegui un processo che mette sotto sforzo il sotto sistema di memoria allora più banda hai e maggiore è l'IPC.
Chissà perché le prestazioni aumentano considerevolmente, e molto più linearmente, proprio overclockando il memory controller.
E' chiaro che se overclocki il memory controller e le prestazioni aumentano quasi linearmente, il sistema non riesce a fruttare la bandwidth della RAM.
Quel 30% di prestazioni in più equivale su un Thuban ad overclockare del 30% il memory controller.

Originariamente inviato da paolo.oliva2

Che poi il dato presente nella ram per via di potenziamenti possa essere del 30% più veloce nel trasferimento (throughput) a parità di velocità banda ram, ben venga...

Il throughput non è il tempo necessario a trasferire il dato. Il throughput è la quantità di dati che riescono a gestire nell'unità di tempo. Che equivale appunto, sul Thuban, ad overclockare il memory controller.

[paolo.oliva2]

Originariamente inviato da cionci

Il tuo discorso in certi casi può andare in altri no, dipende tutto dal tipo di carico che esegui. Se esegui un processo che mette sotto sforzo il sotto sistema di memoria allora più banda hai e maggiore è l'IPC.
Chissà perché le prestazioni aumentano considerevolmente, e molto più linearmente, proprio overclockando il memory controller.
E' chiaro che se overclocki il memory controller e le prestazioni aumentano quasi linearmente, il sistema non riesce a fruttare la bandwidth della RAM.
Quel 30% di prestazioni in più equivale su un Thuban ad overclockare del 30% il memory controller.

Il throughput non è il tempo necessario a trasferire il dato. Il throughput è la quantità di dati che riescono a gestire nell'unità di tempo. Che equivale appunto, sul Thuban, ad overclockare il memory controller.

D'accordo... ma è la stessa cosa che succede nel QPI Intel (si scrive così?) o intervenendo comunque sulla frequenza del bus.
Però, questo, non è conseguenza di un punto debole del procio, ma di un OC del throughput del procio.
Mi sembra chiaro che qualsiasi parte del procio fatta lavorare sopra le specifiche def, porti un aumento dell'IPC def.

throughput:
Secondo me... se un Thuban può lavorare con DDR2 a frequenze di 800MHz, senza perdite prestazionali degne di nota, ma rispetto alle DDR3 (oramai i timing sono simili) la frequenza è quasi 1/3, per forza di cose, il throughput dovrebbe essere ottimo per forza, altrimenti... il procio sarebbe castrato ai massimi livelli. Per farti un esempio... io non penso di aver visto mai un i7 X4 in bench con DDR3 <1333, ma queste sono nettamente superiori in banda a delle DDR2 800MHz, contando per entrambe timing nella media. Sarei curioso di vedere un i7 X4 con delle DDR3 settate a 800MHz quale IPC ne caverebbe fuori.

[cionci]

Originariamente inviato da paolo.oliva2

Mi sembra chiaro che qualsiasi parte del procio fatta lavorare sopra le specifiche def, porti un aumento dell'IPC def, ma questo non è da considerare come punto debole, no?

Dipende. Se il throughput è sufficiente a soddisfare le richieste del carico allora non ci sono comunque aumenti di IPC o al limite sono minimi.
Allora spiegamei perché Thuban ne tocca di brutto dall'i7 proprio nei programmi più dipendenti dalla bandwidth. Vedi appunto tutti i vari compressori/decompressori.

[cionci]

Originariamente inviato da paolo.oliva2

throughput:
Secondo me... se un Thuban può lavorare con DDR2 a frequenze di 800MHz, senza perdite prestazionali degne di nota, ma rispetto alle DDR3 (oramai i timing sono simili) la frequenza è quasi 1/3, per forza di cose, il throughput dovrebbe essere ottimo per forza, altrimenti... il procio sarebbe castrato ai massimi livelli. Per farti un esempio... io non penso di aver visto mai un i7 X4 in bench con DDR3 <1333, ma queste sono nettamente superiori a delle DDR2 800MHz, contando per entrambe timing nella media.

Posto che il protocollo e la temporizzazione delle DDR2 e delle DDR3 sono completamente diversi e che le DDR3 sono per forza di cose più lente a parità di frequenza, è proprio questo che ti sto dicendo: se ci sono aumenti prestazionali minimi significa che il throughput non è sufficiente per sfruttare la maggiore bandiwidth offerta.

[paolo.oliva2]

Originariamente inviato da cionci

Posto che il protocollo e la temporizzazione delle DDR2 e delle DDR3 sono completamente diversi e che le DDR3 sono per forza di cose più lente a parità di frequenza, è proprio questo che ti sto dicendo: se ci sono aumenti prestazionali minimi significa che il throughput non è sufficiente per sfruttare la maggiore bandiwidth offerta.

Che le DDR3 sono più lente delle DDR2 a parità di frequenza, non si discute, ma delle DDR3 a 1333 7-7-7 sono più veloci delle DDR2 800MHz 5-5-5.
Però, credo che tu non mi segua in questo. lascia perdere l'esempio del massimo.

Quello che ti sto dicendo, è che se L3/MC nel Thuban/Phenom II fossero fatti alla boia di cane, un X6 con DDR2 800MHz sarebbe castrato duro.

Il fatto poi che aumentando la banda oltre un certo valore non aumenti l'IPC, io in questo vedo proprio come conferma che l'MC riesce ad ottenere già il max richiesto dal procio senza dover montare memorie velocissime, e lo interpreto come throughput ottimo e non certo scarso.

Intendiamoci... se proprio vogliamo vedere dei problemi, ci potranno essere nella L3, nella L2, nella L1, nella logica delle pipeline, in un IPC max non proprio max ottenibile da un X86, in qualsiasi altra cosa, ma non li vedo nell'MC.

Ti faccio un altro esempio: se ci fossero prb di throughput da parte dell'MC, io lo vedrei immediatamente con questo esempio:

prendo un 965C3 X4, imposto delle DDR3 a 1333, lo porto a 4GHz e ci faccio girare Cinebench su tutti i core.

Smonto il 965C3 e ci monto il 1090T X6, sempre con le 1333MHz, lo occo sempre a 4GHz, e rifaccio il test con Cinebench.

SE ci fossero problemi di throughput, io dovrei essere OBBLIGATO ad aumentare il clock delle ram per sopperire al throughput inferiore che non riesce ad alimentare 6 core mentre prima ce la faceva ad alimentarne 4, e vedrei performances inferiori, con evidenti perdite di IPC.

Invece cosa mi ritrovo? Che se anche porto le DDR3 a 1066, non otterrei peggioramenti. Questo può essere dovuto unicamente ad un throughput migliore rispetto all'X4.

Il fatto che aumentando la banda delle ram non ottengo nulla di più, non lo lego ad un throughput scarso... anzi, vedo tutto l'opposto. Se i core vogliono 1 litro d'acqua al secondo, se gli do' 0,9 litri mi cala l'IPC, ma se gli do 2 litri al secondo, non ottengo nulla di più perché di più non possono ricevere, ma perché sono arrivato al max IPC, di più, non c'è.

[cionci]

Originariamente inviato da paolo.oliva2

Quello che ti sto dicendo, è che se L3/MC nel Thuban/Phenom II fossero fatti alla boia di cane, un X6 con DDR2 800MHz sarebbe castrato duro.

Il fatto poi che aumentando la banda oltre un certo valore non aumenti l'IPC, io in questo vedo proprio come conferma che l'MC riesce ad ottenere già il max richiesto dal procio senza dover montare memorie velocissime, e lo interpreto come throughput ottimo e non certo scarso.

Tu sopra mi dici che non sono castrati nemmeno con DDR2 800 Mhz, quindi se questo throughput non aumenta mai significa che non riesce a sfruttare mai più della banda offerta dalle DDR2 800 Mhz (o comunque pochi punti percentuali oltre). E questo sarebbe un throughput ottimo ?

[paolo.oliva2]

Originariamente inviato da cionci

Tu sopra mi dici che non sono castrati nemmeno con DDR2 800 Mhz, quindi se questo throughput non aumenta mai significa che non riesce a sfruttare mai più della banda offerta dalle DDR2 800 Mhz (o comunque pochi punti percentuali oltre). E questo sarebbe un throughput ottimo ?

Te la rigiro così:

Se con delle DDR2 800 si riesce a raggiungere un IPC di circa il 5% inferiore (nel reale, i bench di banda non dicono nulla di reale sul campo) rispetto a delle DDR3 2000, che certamente sono molto più veloci del 5%, vuol dire far arrivare quasi gli stessi dati su una banda di gran lunga inferiore. Cosa impossibile se il throughput fosse scarso, no?

Banda DDR3 2GHz ~27GB/s
Banda DDR2 800MHz ~13GB/s + throughput scarso, = IPC almeno inferiore del 50%. Se invece l'IPC è inferiore del solo 5% max (sparo a caso), dove avviene il miracolo? Io lo vedo in un throughput ottimo da parte dell'MC nel riuscire a portare il massimo dei dati su una banda minima.

Almeno possiamo pensare che il throughput è bilanciato per la richiesta di dati di un Thuban. Se ci fosse un Phenom II X8 e l'MC riuscirebbe a soddisfarlo ugualmente, il merito non sarebbe dell'MC? Ma lo riuscirebbe a soddisfare, perché pensare ad un BD X8 che "vivrebbe" con un potenzionamento dell'MC del Thuban del solo 50% ma con una potenza dell'elaborazione dati almeno superiore del 100%, porta a considerare che l'MC del Thuban supera almeno del 50% la richiesta dei core... come del resto lo si evidenzia nel fatto che un 1090T a 4,5GHz non ha alcun collo di bottiglia visto che scala linearmente, ma senza dover aumentare la banda della ram per compensare un throughput inferiore.

Non dimentichiamoci che AMD rendendoli compatibili i procio per DDR2 e DDR3 con lo stesso MC, si è trovata nel problema di riuscire a fornire gli stessi dati +/- di un sistema magari sufficiente per un X2 a 2,8GHz, per passare fino ad un X6 a 3,2GHz, per permettere al cliente di poter upgradare cambiando solamente il procio. Questo è stato un gran lavoro, oltretutto nemmeno retribuito, visto che il cliente, non dovendo necessariamente cambiare mobo, ha di fatto impedito ad AMD di vendere i chip-set nuovi che altrimenti avrebbe venduto con una mobo nuova.

[cionci]

Originariamente inviato da paolo.oliva2

Te la rigiro così:

Se con delle DDR2 800 si riesce a raggiungere un IPC pari a chi abbisogna almeno delle DDR3 1333, come lo giudichi il throughput? Che riesce a passare gli stessi dati con una banda inferiore. Come puo allora essere il throughput inferiore?

E' quasi uguale, ma è quasi uguale anche con le DDR3 1600, quindi non variando al variare della banda (o variando minimamente) significa che il memory controller non riesce a generare un throughput sufficiente per garantire aumenti di prestazioni dovuti alla aumento della bandwidth.
Ne è riprova che con l'overclock del memory controller invece il throughput aumenta notevolmente. Se il throuhput fosse sufficiente per gestire al meglio la bandwidth con una data bandwidth, all'aumento della frequenza della RAM non aumenterebbe il risultato della bandwidth rilevato dai test sintetici.
I test sintetici per misurare la bandwidth non sono altro che programmi che fanno l'uso più intenso possibile del memory controller.

Ad esempio:



Il memory controller ha throughput sufficiente a gestire a pieno la bandwidth offerta da una data tecnologia di RAM, quando la curva diventa orizzontale.
Come vedi rispetto alla frequenza di default, ci sono almeno tre step di frequenza necessari.
La latenza invece diminuisce sempre e comunque all'aumentare della frequenza del MC, quindi fornisce qualche disturbo nel testare le performance nelle applicazioni reali.

[paolo.oliva2]

Originariamente inviato da cionci

E' quasi uguale, ma è quasi uguale anche con le DDR3 1600, quindi non variando al variare della banda (o variando minimamente) significa che il memory controller non riesce a generare un throughput sufficiente per garantire aumenti di prestazioni dovuti alla aumento della bandwidth.
Ne è riprova che con l'overclock del memory controller invece il throughput aumenta notevolmente. Se il throuhput fosse sufficiente per gestire al meglio la bandwidth con una data bandwidth, all'aumento della frequenza della RAM non aumenterebbe il risultato della bandwidth rilevato dai test sintetici.
I test sintetici per misurare la bandwidth non sono altro che programmi che fanno l'uso più intenso possibile del memory controller.

L'OC dell'MC lo si fa portandolo da 2GHz a 2,8GHz, almeno nel mio caso ma a riprova di ciò ti porto questo:

Se overclocchi l'MC a 2,8GHz LASCIANDO il procio a frequenza def NON OTTIENI NULLA DI PIU', perchè? Perché il throughput è già più che sufficiente per la richiesta del procio, visto che nulla impedirebbe ad AMD di impostare un NB/MC a 2,2GHz o 2,4GHz def, se facesse guadagnare.
Perché con un 1090T porti l'NB a 2,8GHz (+40%) e ottieni guadagni?
Semplice... perché portando il procio a +40% di clock (3,2GHz --> 4,5GHz), ottieni un potenziamento dell'elaborazione dei core del 40%, quindi hai bisogno del + 40% di apporto dati per ristabilire lo stesso bilanciamento.

Ad esempio:

Il memory controller ha throughput sufficiente a gestire a pieno la bandwidth offerta da una data tecnologia di RAM, quando la curva diventa orizzontale.
Come vedi rispetto alla frequenza di default, ci sono almeno tre step di frequenza necessari.
La latenza invece diminuisce sempre e comunque all'aumentare della frequenza del MC, quindi fornisce qualche disturbo nel testare le performance nelle applicazioni reali.

Io posso capire i tuoi esempi, ma sul campo è come ti riporto.

Il discorso è nato dal fatto che reputi il punto debole del Phenom l'MC, come se un Thuban non possa aumentare in IPC per via di un throughput "inferiore".
Io ti sto dimostrando che il throughput è ottimo per l'esempio che ti ho postato sopra... e comunque ben al di sopra delle necessità di un'architettura Phenom II, e lo dimostra il fatto che overcloccando il Thuban a + 40% (chiaramente occando in proporzione l'intero sistema) non perde una virgola... ma stiamo sempre parlando di un +41%... 4,515GHz, che sono limitati per il TDP, ma l'architettura di per sé reggerebbe, visto che comunque in monocore supera i 4,7GHz, e la linearità è perfetta, non perdendo assolutamente nulla. Già questo, per me, porta a considerare il throughput ottimo.

[cionci]

Comunque te l'ho detto, se cambiando frequenza delle RAM le prestazioni non cambiano quasi lineaermente nei programmi molto dipendenti dalla memoria allora è il memory controller che non ce la fa.
Come vedi le prestazioni di WinRar cambiano quasi linearmente con l'overclock del memory controller. Prova a mettere tutto a default e prova a mettere le DDR3 nei vari step 800-1066-1333-1600-1866. Se le prestazioni di WinRar aumentato quasi linearmente hai ragione te, se non aumentano quasi lineramente ho ragione io. Mi raccomando prova lasciando esattamente gli stessi timings.

[capitan_crasy]

Paolo se vuoi fare qualche prova suggerita da cionci con i tuoi Phenom2 (ancora? ) postali per cortesia sul thread del K10...

[Alekz]

Bene, tornando a Fusion e Bulldozer
Si conosce la prossima scadenza nda o evento amd, per avere altre notizie ufficiali?

[bjt2]

Originariamente inviato da cionci

Sì, ma non è un miglioramento architetturale. Anche gli attuali se non sbaglio fuori specifica supportano Ram con quelle frequenze, no ?

Le CPU INTEL con NB a 2133 supportano NATIVAMENTE le DDR3 1066, quelle con NB a 2666 supportano NATIVAMENTE le DDR3 a 1333. Per andare oltre si DEVE necessariamente overcloccare il NB per il limite architetturale del Nehalem. Quindi sicuramente per i server, dove l'OC è assolutissimamente vietato, non si va oltre i 1333. E addirittura l'8 core (Nehalem EX, mi pare), ha si il triple channel, ma il NB (probabilmente per questioni di TDP) va a 2133, quindi supporta massimo DDR3 1066. Non so se SB abbia risolto questo problema. Per i Phenom si può portare la RAM anche a 2133 senza alzare il NB, il BUS e la CPU, quindi non ci sarebbero problemi nenache nei server (posto che il Jedec approvi la specifica e AMD la validi sulle proprie CPU)...

[bjt2]

@Paolo: ha ragione Cionci.
Ora ti spiego:

qualsiasi sia il carico sulla CPU, la prestazione massima è limitata dall'anello debole della catena CPU-NB-RAM. Per ogni tipo di carico ci sarà un diverso elemento che fa da tappo. Per esempio per super PI, che richiede pochissima banda memoria, la CPU farà da tappo e potrai anche usare DDR3 scarse e NB basso. Per winrar, ad esempio, sotto una certa frequenza CPU, farà lei da tappo, ma sopra una certa frequenza, iniziarà a fare da tappo il NB e poi la RAM, se quest'ultima è abbatsanza performante. Con il NB a 2GHz (default AMD) la RAM farebbe da tappo solo sotto il GHz (e quindi con le DDR2, ad esempio). In tutti gli altri casi è il NB che fa da tappo e tu lo sai, visto le prove che ti feci fare anche con 2 e 4 moduli. Il NB fa da tappo con 2 moduli a frequenza pari almeno alla metà del NB. Con 4 moduli poi non ne parliamo: sul C3 non c'è storia, sullE0 (Thuban) tu hai verificato che c'è un miglioramento con 4 moduli... Insomma: aumentare il clock NB fa sempre bene perchè si velocizza la L3, ma fa MOOOOLTO bene per applicazioni avide di memoria almeno fino a che il NB arriva al doppio della frequenza RAM. Oltre migliora molto lentamente solo per la maggiore velocità della L3. Per programmi poco avidi di memoria e che non stanno nella L1 e L2 ma solo nella L3, aumentare il NB aumenta sempre quasi linearmente le prestazioni. Per programmi pochissimo avidi di memoria e che stanno nella L1 e L2, le prestazioni aumentano linearmente con il clock CPU e di poco con il clock NB e RAM...

[Pihippo]

Originariamente inviato da paolo.oliva2

Te la rigiro così:

Se con delle DDR2 800 si riesce a raggiungere un IPC di circa il 5% inferiore (nel reale, i bench di banda non dicono nulla di reale sul campo) rispetto a delle DDR3 2000, che certamente sono molto più veloci del 5%, vuol dire far arrivare quasi gli stessi dati su una banda di gran lunga inferiore. Cosa impossibile se il throughput fosse scarso, no?

.

Ciao Paolo.
Il miracolo avviene perchè il prefetch nel mem controller cerca in tutti i modi possibili (non so l'offset di n+-n byte) di far comparire i dati al momento giusto (in un buffer di scrittura del mem controller). Tuttavia ciò non toglie che in caso di cache miss branch mispredict più il tuo mem controller è efficiente più puoi riempire prima le caches.
Siccome queste sono le cause maggiori di un degradamento delle prestazioni più veloce ricarichi prima ricominci a lavorare.

[capitan_crasy]

Originariamente inviato da Alekz

Bene, tornando a Fusion e Bulldozer
Si conosce la prossima scadenza nda o evento amd, per avere altre notizie ufficiali?

Forse al CES 2011 AMD mostrerà qualcosa, ma non ne sono sicuro...

[AceGranger]

Originariamente inviato da bjt2

Le CPU INTEL con NB a 2133 supportano NATIVAMENTE le DDR3 1066, quelle con NB a 2666 supportano NATIVAMENTE le DDR3 a 1333. Per andare oltre si DEVE necessariamente overcloccare il NB per il limite architetturale del Nehalem. Quindi sicuramente per i server, dove l'OC è assolutissimamente vietato, non si va oltre i 1333. E addirittura l'8 core (Nehalem EX, mi pare), ha si il triple channel, ma il NB (probabilmente per questioni di TDP) va a 2133, quindi supporta massimo DDR3 1066. Non so se SB abbia risolto questo problema. Per i Phenom si può portare la RAM anche a 2133 senza alzare il NB, il BUS e la CPU, quindi non ci sarebbero problemi nenache nei server (posto che il Jedec approvi la specifica e AMD la validi sulle proprie CPU)...

Nehalem EX hanno il QUAD-channel

[paolo.oliva2]

Originariamente inviato da bjt2

@Paolo: ha ragione Cionci.
Ora ti spiego:

qualsiasi sia il carico sulla CPU, la prestazione massima è limitata dall'anello debole della catena CPU-NB-RAM. Per ogni tipo di carico ci sarà un diverso elemento che fa da tappo. Per esempio per super PI, che richiede pochissima banda memoria, la CPU farà da tappo e potrai anche usare DDR3 scarse e NB basso. Per winrar, ad esempio, sotto una certa frequenza CPU, farà lei da tappo, ma sopra una certa frequenza, iniziarà a fare da tappo il NB e poi la RAM, se quest'ultima è abbatsanza performante. Con il NB a 2GHz (default AMD) la RAM farebbe da tappo solo sotto il GHz (e quindi con le DDR2, ad esempio). In tutti gli altri casi è il NB che fa da tappo e tu lo sai, visto le prove che ti feci fare anche con 2 e 4 moduli. Il NB fa da tappo con 2 moduli a frequenza pari almeno alla metà del NB. Con 4 moduli poi non ne parliamo: sul C3 non c'è storia, sullE0 (Thuban) tu hai verificato che c'è un miglioramento con 4 moduli... Insomma: aumentare il clock NB fa sempre bene perchè si velocizza la L3, ma fa MOOOOLTO bene per applicazioni avide di memoria almeno fino a che il NB arriva al doppio della frequenza RAM. Oltre migliora molto lentamente solo per la maggiore velocità della L3. Per programmi poco avidi di memoria e che non stanno nella L1 e L2 ma solo nella L3, aumentare il NB aumenta sempre quasi linearmente le prestazioni. Per programmi pochissimo avidi di memoria e che stanno nella L1 e L2, le prestazioni aumentano linearmente con il clock CPU e di poco con il clock NB e RAM...

Ma io veramente non è che sono in disaccordo su questo, sono in disaccordo sul throuhput che sia debole quello di AMD.

Faccio questo esempio:

ho una banda che mi darebbe 100. L'MC con basso throuhput mi permette di utilizzare 50, uno con throuhput alto, me ne farebbe utilizzare 70 (dati a caso).

Quindi, tenendo come costante la stessa banda ram, più l'MC ha un ottimo throuhput, più tardi mi si presenteranno prb di colli di bottiglia, permettendomi di avere con una banda minore con un throuhput migliore lo stesso flusso dati.
(e qui era il mio esempio delle DDR2 800MHz).

Ora... faccio un esempio tra AMD ed Intel.

Un i7 9XX, con il triple channel avrebbe una banda nominale maggiore di quella AMD, quindi in OC dovrebbe scalare meglio di AMD.
Invece cosa vediamo? Che un i7 sopra i 4GHz comincia a perdere, mentre un Thuban almeno fino a 4,5GHz non perde.

Considerando anche il fatto che già gli X6 i7 hanno una L3 ben maggiore e gli X8-X10 futuri l'avranno di 20MB circa, pure contando su triple-channel e quad-channel, ne esco fuori che la L3 di dimensioni industriali assolva lo stesso compito delle L2 sempre industriali dei Penryn, cioè fungere da serbatoio per un throuhput non eccelso.

BD X8, invece, avrà una L3 di soli 8MB, con il dual-channel, quindi per me questo è l'esempio che se si parla di throuhput, AMD certamente l'ha buono, perché con una L3 "inferiore" in grandezza (meno della metà) e con il "solo" dual.channel, dovrebbe avere un throuhput tale al minimo da equivalere un sistema Intel con L3 da 20MB e triple o quad chnnel.

Poi, tra l'altro, questo sarebbe a tutto vantaggio, in primis di un size die inferiore e quindi potenzialmente ad un prezzo inferiore, poi di una mobo più economica, nel fatto di poter assemblare un sistema con solo 2 banchi DDR3... il tutto, tradotto i soldi, equivarrebbe a una minor spesa per la stessa potenza.

Non essendo perito elettronico (), io ragiono un po' da "contadino" (senza alcuna offesa per chi lo fa) su dati e riflessioni che vedo. Dove sbaglio?

[paolo.oliva2]

Originariamente inviato da Pihippo

Ciao Paolo.
Il miracolo avviene perchè il prefetch nel mem controller cerca in tutti i modi possibili (non so l'offset di n+-n byte) di far comparire i dati al momento giusto (in un buffer di scrittura del mem controller). Tuttavia ciò non toglie che in caso di cache miss branch mispredict più il tuo mem controller è efficiente più puoi riempire prima le caches.
Siccome queste sono le cause maggiori di un degradamento delle prestazioni più veloce ricarichi prima ricominci a lavorare.

D'accordo... ma il throuhput non è come pensare all'ottimizzazione di tutto il processo? Il punto sarebbe quindi, con il sistema A otterrei la stessa velocità ma con DDR3 1333 o 2000 rispetto al sistema B che monterebbe le 1600?

[cionci]

Originariamente inviato da paolo.oliva2

D'accordo... ma il throuhput non è come pensare all'ottimizzazione di tutto il processo? Il punto sarebbe quindi, con il sistema A otterrei la stessa velocità ma con DDR3 1333 o 2000 rispetto al sistema B che monterebbe le 1600?

Il memory controller ha una certa frequenza. In base a quella frequenza riesce a gestire un massimo throughput. Ovviamente se il massimo throughput è minore di quello necessario a gestire una certa frequenza delle memorie non ci sono problemi. Se aumentando la frequenza delle memorie il throughput che sarebbe necessario è maggiore del massimo throughput ottenibile dal controller di memoria a quella data frequenza, allora è il controller di memoria a fare da collo di bottiglia.