PIV bandwidth memory : chi la sfrutta?

[ftigli]

Un dubbio...

Con SiSoft Sandra un PIV con i850 rimm mostra una performance di memoria pressoche' doppia rispetto a una soluzione tradizionale Sdramm single , e cio' e' lecito osservando l'architettura del quad pump.


MA :

Utilizzando tutti i software, games etc etc si hanno vantaggi dell'ordine max di pochi punti percentuali.... addirittura negli applicativi prof. (VB., Java, C++) e' adddirittura la struttura del processore a prevalere (cioe' un PIII o un athlon danno risultati molto migliori indipendentemente dalla memoria)

PERTANTO :

Chi e' che sfrutta questa enorme performance sulla memory bandwidht delle Rimm + 850?????
E' l'architettura del PIV che fa da collo di bottiglia ?????


Illuminatemi... vi prego !!!!!

Non e' un post polemico.. voglio solo capire !!! Altrimenti posso solo pensare che SiSoft - memory sia un bench assolutamente falso, il cui eclatante risultato sulle rimm non trova riscontro nell'utizzo reale dell'utente con ogni software oggi esistente.


Bye !

[robnet77]

Da quello che so i giochi 3d dovrebbero sfruttare l'ampiezza di banda delle RIMM, in quanto si tratta di una mole enorme di dati che viaggia, tra l'altro, con buone probabilità di prefetch ("predizione dei dati che saranno richiesti nei momenti immediatamente successivi", scusa il linguaggio un po' rozzo), quindi l'alta latenza delle RIMM nei giochi dovrebbe passare in secondo piano rispetto alla quantità di dati effettivamente richiesti.
Da alcuni benchmark, infatti, si legge che i sistemi con memorie DDR non sfruttano appieno le Geforce3 nei giochi, poiché il collo di bottiglia sembra essere proprio la bandwidth delle DDR, mentre i PIV con RIMM dipendono in misura maggiore dal tipo di scheda video utilizzato...
Tuttavia, non sono sicuro al 100% di ciò che ho scritto, se qualcuno ha letto qualcosa a riguardo sarebbe gradito un suo post
Ciao

[SaMu]

Originariamente inviato da ftigli
[b]
Non e' un post polemico.. voglio solo capire !!! Altrimenti posso solo pensare che SiSoft - memory sia un bench assolutamente falso, il cui eclatante risultato sulle rimm non trova riscontro nell'utizzo reale dell'utente con ogni software oggi esistente.

Non è un test falso. E' semplicemente il test di uno dei molteplici aspetti di un architettura, e proprio perchè è solo uno degli aspetti, non puoi aspettarti che al raddoppiare del risultato di questo raddoppino le prestazioni complessive.


E' (seppur con tutte le differenze del caso) simile alla vicenda del pluriosannato e rivoluzionario nForce, la cui doppia banda secondo alcuni avrebbe garantito prestazioni cosmiche, quando io per mesi sostenevo che la maggior banda serviva solo ed unicamente a non costituire un collo di bottiglia nell'utilizzo del video integrato, con accessi simultanei di GPU e processore alla memoria RAM. Al contrario, le prestazioni sono comparabili a quelle del chipset Via KT266a, che ha banda singola tradizionale verso le memorie.


Stesso risultato, raddoppiando la banda, il risultato varia sì, ma non eccessivamente. Non è strano che succeda così, sarebbe strano se succedesse diversamente.

[Lorenzo k7]

non capisco una cosa:
il chipset nforce avrà un bus per la ram di 128bit e frequenza 266Mhz, però il bus del processore é a 64bit sempre 266Mhz. Quindi dovrebbe servire a poco se non si usa la scheda video integrata visto che il collo di bottiglia diventerebbe il bus del processore

[shodan]

Credo che le cose non stiano proprio cosi... il singolo canale ram del chipset nforce 420 è largo 64bit, 2 canali fanno quindi 128 bit. E' come ha detto Samu: in pratica un canale serve il processore e uno l'adattatore video integrato, al fine di non penalizzare le prestazioni.
PS scusatemi so che non è proprio così ma volevo essere chiaro .
Se ho fatto qualche errore madornale correggetemi!!!

[subrahmanyam]

io non ci sto capendo un cazzo....
ma mi sembra questa sia una discussione splendida



j

[ftigli]

trovo conferma : l'argomento non e' propriamente semplice e presenta molteplici aspetti.

Questo post serve per evidenziare cio' che e' veramente utile all'utente finale ....

Da come si sta mettendo il mercato, e' estremamente probabile la sparizione dell'architettura Rambus entro il I Q1 2002 , a meno che rambus stessa non faccia un chipset.

Coem utenti non ci mettiamo la mano nei capelli, in quanto la mostruosa bandwith Rimm quad pump sembra proprio non avere riscontri pratici evidenti da quanto mi dite e da tutti i vari bench che si trovano in giro..

Solo su Quake III+GeforceIII il PIV 2 Ghz+ rimm sembrava avere qualche percento di vantaggio su un 1800+ XP +DDR .. ma, con il 1900+ anche questo lieve vantaggio e' annullato.
Sembra proprio che l'architettura Rimm non offra praticamente nulla di effettivo.

Il dubbio e' invece : se il PIV rende solo con le Rimm, perdera' parecchio passando alle DDR (I845D) ???????

In tal caso la situazione si sposterebbe in termini di perfomances ancora di piu' a favore dell'SP+DDR...

Se poi ci mettiamo le DDR 333 col nuovo sis...


Morale della favola .. se uno mi chiede cosa posso comperare di piu' performante ad oggi, senza parteggiare ne per Intel o AMD onestamente devo rispondergli


L'altro Ieri : un PIV 2Ghz con rimm , magari su Abit TH7 raid

Oggi :

ASUS col via Kt266A + DDR
Athlon XP 1900+


Domani ???????

[SaMu]

Originariamente inviato da ftigli
[b]trovo conferma : l'argomento non e' propriamente semplice e presenta molteplici aspetti.

Questo post serve per evidenziare cio' che e' veramente utile all'utente finale ....

Da come si sta mettendo il mercato, e' estremamente probabile la sparizione dell'architettura Rambus entro il I Q1 2002 , a meno che rambus stessa non faccia un chipset.

Coem utenti non ci mettiamo la mano nei capelli, in quanto la mostruosa bandwith Rimm quad pump sembra proprio non avere riscontri pratici evidenti da quanto mi dite e da tutti i vari bench che si trovano in giro..

Solo su Quake III+GeforceIII il PIV 2 Ghz+ rimm sembrava avere qualche percento di vantaggio su un 1800+ XP +DDR .. ma, con il 1900+ anche questo lieve vantaggio e' annullato.
Sembra proprio che l'architettura Rimm non offra praticamente nulla di effettivo.

Il dubbio e' invece : se il PIV rende solo con le Rimm, perdera' parecchio passando alle DDR (I845D) ???????

In tal caso la situazione si sposterebbe in termini di perfomances ancora di piu' a favore dell'SP+DDR...

Se poi ci mettiamo le DDR 333 col nuovo sis...


Morale della favola .. se uno mi chiede cosa posso comperare di piu' performante ad oggi, senza parteggiare ne per Intel o AMD onestamente devo rispondergli


L'altro Ieri : un PIV 2Ghz con rimm , magari su Abit TH7 raid

Oggi :

ASUS col via Kt266A + DDR
Athlon XP 1900+


Domani ???????

Non ho capito Tigli, ma volevi parlare di RDRAM e bandwidth, oppure fare i consigli degli acquisti di questo mese?


I bench con le prestazioni comparate di 850+RDRAM, 845+SDRAM, P4X+DDR266, Sis645+DDR266, Sis 645+DDR333 sono già disponibili in vari siti in rete, se ti interessa valutare l'argomento.

Su www.aceshardware.com c'era un mesetto fa, lo trovi ancora sulla colonna di destra, un articolo con l'analisi di pregi e difetti della tecnologia RDRAM, anche dal punto di vista costruttivo (per le mobo) e produttivo (per i chip e per i moduli in se'). Qualcosa di simile c'era anche su www.arstechnica.com

[pipozzolo]

Volevo dire solo che la bandwidth offerta dalle RIMM se la brucia il p4 stesso. Evidentemente l'unità di branch predition del p4 non è così efficiente come la intel sostiene (o i programmi non sono ottimizzati x avvantaggiarsene)

[SaMu]

Originariamente inviato da pipozzolo
[b]Volevo dire solo che la bandwidth offerta dalle RIMM se la brucia il p4 stesso. Evidentemente l'unità di branch predition del p4 non è così efficiente come la intel sostiene (o i programmi non sono ottimizzati x avvantaggiarsene)

Questa non l'ho mica capita.. mi spieghi meglio cosa vuoi dire?

[ftigli]

"Non ho capito Tigli, ma volevi parlare di RDRAM e bandwidth, oppure fare i consigli degli acquisti di questo mese?"ù

Sara' brutto ma dopo la teoria viene la pratica.. e' quello che mi domandano prima di spendere per i sistemi !!!!!!!!

E quindi l'argomento mi rientra sempre anche se volevo fareun post puramente tecnico...

Grazie per i link vado a studiare...


Bye

[pipozzolo]

Il discorso è un po tecnico. Il 'punto debole' di un'architettura a pipeline è dato dalle istruzioni 'condizionali' o di salto. Per velocizzare l'esecuzione di una sequenza di istruzioni, il p4 (e tutti i processori moderni) tenta di predire il flusso del programma in corrispondenza di condizioni di salto, tenta quindi di indovinare la porzione di codice che verrà eseguita dopo la condizione e quindi esegue quel codice portandosi avanti nell'elaborazione in attesa del risultato della condizione di salto.
Se sbaglia, questo si traduce in uno spreco di bandwidth (ha portato dalla ram delle porzioni di codice che non verranno mai eseguite).
Il p4 basa la sua architettura su questo sistema , parallelizzando l'esecuzione del processo in numerose pipeline.
Quindi se quella benedetta unita di branch predition non indovina, oltre alla perdita di tempo di dover riempire di nuovo tutte le pipeline, c'è anche lo spreco di banda causato dal caricamento di istruzioni inutili

Non credo di essere stato chiaro... cmq ci ho provato (nelle mie possibilità)!
Ciao

[SaMu]

Originariamente inviato da ftigli
[b]"Non ho capito Tigli, ma volevi parlare di RDRAM e bandwidth, oppure fare i consigli degli acquisti di questo mese?"ù

Sara' brutto ma dopo la teoria viene la pratica.. e' quello che mi domandano prima di spendere per i sistemi !!!!!!!!

E quindi l'argomento mi rientra sempre anche se volevo fareun post puramente tecnico...

Grazie per i link vado a studiare...


Bye

Beh, per la pratica non ci sarebbe nemmeno da aprirle le discussioni, XP 1500+ con ECS 735 e 256 di DDR.



Pipozzolo, il problema della branch prediction è connesso con la scelta di avere una pipeline a molti stadi, per cui un errore significa spreco di cicli di clock e di operazioni già in fase di esecuzione che vanno perse, non alla nadwidth della RAM.

L'uso della bandwitdth della RAM non è influenzato da questo, devi pensare al flusso di dati dalla RAM come ad un condotto di portata (quasi) costante, che l'utilizzatore la usi tutta, o ne sprechi una parte, il numero di dati in arrivo nell'unità di tempo non varia.


Kronos2000 lo saprà spiegare sicuramente meglio di me.

[Xtian]

Originariamente inviato da SaMu
[b]Pipozzolo, il problema della branch prediction è connesso con la scelta di avere una pipeline a molti stadi, per cui un errore significa spreco di cicli di clock e di operazioni già in fase di esecuzione che vanno perse, non alla nadwidth della RAM.

secondo me ha ragione pipozzolo,se c'e' un errore nella predizione dei salti la cpu si ferma e deve andare in cerca delle istruzioni necessare che cerca, prima nella cache istruzioni, altrimenti in memoria(quindi usando il bus)
Tanto per dare una spiegazione un po' "spannometrica"
In realta' il problema e' un attimino piu' complesso.
Mi piacerebbe sapere qual'e' la % dell'unita' BP del P4(tanto per comparazione l'unita' del tbird mi sembra abbia un 90%)

[b]
L'uso della bandwitdth della RAM non è influenzato da questo, devi pensare al flusso di dati dalla RAM come ad un condotto di portata (quasi) costante, che l'utilizzatore la usi tutta, o ne sprechi una parte, il numero di dati in arrivo nell'unità di tempo non varia.
Kronos2000 lo saprà spiegare sicuramente meglio di me.

non e' sempre cosi', dipende dalle operazioni che tipo di utilizzo del bus fanno, si puo' utilizzare in 2 modi:
-burst (si continua a richiedere l'uso del bus per piccoli periodi ma frequentemente)
-write/back (si usa il bus solo alla fine di determinate operazioni)

[SaMu]

Originariamente inviato da Xtian
[b]
secondo me ha ragione pipozzolo,se c'e' un errore nella predizione dei salti la cpu si ferma e deve andare in cerca delle istruzioni necessare che cerca, prima nella cache istruzioni, altrimenti in memoria(quindi usando il bus)
Mi piacerebbe sapere qual'e' la % dell'unita' BP del P4(tanto per comparazione l'unita' del tbird mi sembra abbia un 90%)

Xtian, correggimi se sbaglio, ma che la CPU vada a cercare, nella cache o nella RAM, nuove istruzioni in seguito ad un errore di branch prediction, oppure nuove istruzioni in seguito ad un successo di branch prediction, sempre le stesse istruzioni nell'unità di tempo andrà a pescare, e sempre lo stesso uso della bandwidth farà, o no?

[pipozzolo]

Mi sembra che stessi dicendo che il p4 non usa tutta la bandwidth a disposizione, o no?

[ftigli]

Samu , siamo d'accordo.

"Beh, per la pratica non ci sarebbe nemmeno da aprirle le discussioni, XP 1500+ con ECS 735 e 256 di DDR. "


Pressoche' impossibile derogare ora da quest'assioma..

Oggi pomeriggio ho comperato una ennesima ECS...

[Xtian]

Originariamente inviato da SaMu
[b]

Xtian, correggimi se sbaglio, ma che la CPU vada a cercare, nella cache o nella RAM, nuove istruzioni in seguito ad un errore di branch prediction, oppure nuove istruzioni in seguito ad un successo di branch prediction, sempre le stesse istruzioni nell'unità di tempo andrà a pescare, e sempre lo stesso uso della bandwidth farà, o no?

Si, hai ragione, in questo caso si'.
Per la cache nessun problema(il bus non viene usato)ma se il dato non viene trovato nella cache viene richiesto l'uso del bus.
Se l'unita' BP (insieme alla trace cache e alla cache vera e propria)non funzionano molto bene,o hanno a che fare con programmi che non riescono ad interpretare,l'uso del bus sara' molto maggiore che nel caso "va tutto bene".
Gia' che la cache abbia un hit rate basso porta ad un uso del bus elevato.Bisognerebbe sapere dei dati (cache hit rate e %BP)che al momento non conosco,con dei valori precisi si potrebbe dire qualcosa di piu'.
Cmq credo che alla intel,sapendo di mettere una pipeline da 20 stadi(anche se in realta' sono effettivamente 14, 6 servono di "assestamento" per i registri interni) abbiano tenuto ben conto di questo problema
Almeno lo spero per loro

[pipozzolo]

Originariamente inviato da SaMu
[b]

Xtian, correggimi se sbaglio, ma che la CPU vada a cercare, nella cache o nella RAM, nuove istruzioni in seguito ad un errore di branch prediction, oppure nuove istruzioni in seguito ad un successo di branch prediction, sempre le stesse istruzioni nell'unità di tempo andrà a pescare, e sempre lo stesso uso della bandwidth farà, o no?

Hai ragione. Per quello dico che se la branch prediction non funziona hai sprecato bandwidth, perchè invece di caricare le istruzioni giuste, hai caricato delle istruzioni che in realtà non ti servono. Non è uno spreco, secondo te?

[kronos2000]

Da quanto ho capito, il P4 è "nato" per macinare dati multimediali sotto forma di SSe2 . La sua unità in virgola mobile è anche meno potente di quella del P3, così come le unità di calcolo per gli interi(cioè le ALU).

L'Athlon non fa nulla di tutto questo. Ha una unità in virgola mobile potentissima e ALU più potenti . È stato però progettato per un FSB a 64 bit. pertanto della doppia banda messa a disposizione dall'nforce non se ne fa nulla. Diverso sarà il discorso per il futuro Hammer, che sfrutterà un fsb a 128 bit.

In applicazioni multimediali, dove non ci sono praticamente istruzioni di salto, il P4 se la cava egregiamente se le SSE2 vengono sfruttate dal programma.(a maggior ragione se ha un capiente dppio canale Rambus che rifornisca le sue pipeline di dati)

Totalemtne diverso il discorso per l'Athlon : va alla grande in applicazini sugli interi(office, compilazione dei sorgenti...)
ma viene sempre più staccato dal P4 mano a mano che si passerà ad applicazioni in virgola mobile multimediali che sfruttimo le SSE2 . Se però il confronto è sulle unità a virgola mobile, per il P4 non c'è storia.

Per dirla tutta, un athlon con le rambus farebbe pena al momento : non le sfrutterebbe in termini di banda e morirebbe dalla noia per le latenze.
Questo per rispindere a quelli che sognano un Athlon accoppiato con Rambus.