La CPU di PlayStation 3 impiegata seriamente con Folding@home

[^TiGeRShArK^]

Originariamente inviato da Criceto

Allo stesso tempo lo sbilanciamento per il calcolo vettoriale (e solo a singola precisione, perchè alla PS3 bastava) ha penalizzato l'utilizzo general-pourpose, tanto che un Cell in quest'ambito pare essere circa 4 volte più lento di uno Xenon dual core (il massimo della tecnologia Intel). Quindi Apple non ha ritenuto di impiegarlo (anche se sui test di Photoshop avrebbe comunque potuto dichiarare che il Mac con Cell era 5-10 volte più veloce di un PC) ed è passata ad Intel.

bhè....
la apple riesce sempre a dire che il suo nuovo prodotto è 5-10 volte + veloce di qualcos'altro

Certo rimangono molti ambiti dove il Cell eccelle, dove le CPU sono troppo generiche e le GPU troppo specializzate. Ma le GPU in particolare stanno sempre più andando a pestare i piedi dove il Cell è forte, quindi a questo punto la sua utilità inizia ad essere dubbia. Ma non credo lo sia ancora e penso che si ritaglierà il suo spazio come coprocessore o per oggetti multimediali da mettere sotto la TV o simili. Per esempio per l'iTV avrei visto 1000 volte meglio un Cell del centrino che hanno utilizzato.

infatti è + o - la mia idea.
Certo ancora non si può dire perchè le GPGPU sono ancora ad uno stato praticamente embrionale...
Però sembrano una tecnologia molto promettente.

[yossarian]

Originariamente inviato da Criceto

Sì ma non esageriamo con questa storia dell'in-order!!
Ok, è meno efficiente, ma mica il processore va 10 volte meno!!!
Ho visto dei test dove i Cell della PS3 vanno mediamente la metà di un G5 di pari frequenza. Ma quest'ultimo ha più cache e soprattutto il doppio delle unità intere e FP, quindi il fatto che sia in-order conta fino ad un certo punto!! E0 semplicemente un core semplificato. Se ne mettono 2 vedi che alla fine è simile al G5.
Inoltre se l'architettura è stabile, o con JIT tipo LLVM, si può spostare l'ottimizzazione in fase di compilazione ed avere praticamente le stesse prestazioni (almeno in teoria) di una ben più complessa architettura out-of-order. Che poi è l'approccio utilizzato da Intel su Itanium.

non sempre è possibile spostare l'ottimizzazione a livello di compilatore; quando lo si può fare, in teoria il gap viene annullato; nella realtà, però, i chip IO risultano molto meno flessibili rispetto a quelli OoO e questo, in applicazioni di tipo GP è un aspetto da non sottovalutare.

[Criceto]

Originariamente inviato da yossarian

non sempre è possibile spostare l'ottimizzazione a livello di compilatore; quando lo si può fare, in teoria il gap viene annullato; nella realtà, però, i chip IO risultano molto meno flessibili rispetto a quelli OoO e questo, in applicazioni di tipo GP è un aspetto da non sottovalutare.

E comunque quanto incide alla fine? Hai dei numeri?
Da quelli che ho visto io non molto, almeno non necessariamente tutti imputabili all'architettura in-order.

Se la semplificazione architetturale permette un innalzamento della frequenze (come nel caso del Cell) che colma il gap di prestazioni, semplicemente si è scelto un approccio diverso al problema, più efficiente dal punto di vista n. transistor/prestazioni, quindi più economico da produrre, ma ugualmente efficiente dal punto di vista prestazionale.

Credo che questa sia stata la filosofia di IBM per il Cell.

[^TiGeRShArK^]

Originariamente inviato da Criceto

Sì ma non esageriamo con questa storia dell'in-order!!
Ok, è meno efficiente, ma mica il processore va 10 volte meno!!!
Ho visto dei test dove i Cell della PS3 vanno mediamente la metà di un G5 di pari frequenza. Ma quest'ultimo ha più cache e soprattutto il doppio delle unità intere e FP, quindi il fatto che sia in-order conta fino ad un certo punto!! E0 semplicemente un core semplificato. Se ne mettono 2 vedi che alla fine è simile al G5.
Inoltre se l'architettura è stabile, o con JIT tipo LLVM, si può spostare l'ottimizzazione in fase di compilazione ed avere praticamente le stesse prestazioni (almeno in teoria) di una ben più complessa architettura out-of-order. Che poi è l'approccio utilizzato da Intel su Itanium.

E infatti si è visto il grossissimo successo di Itanium
scherzi a parte.
Per quanto si possa anche utilizzare l'approccio EPIC di Itanium (cosa di cui dubito fortemente sul cell) dovresti sapere che una CPU Out of Order è inerentemente + efficiente, per quante ottimizzazioni possa fare un compilatore.
Ora, che tu mi dica che esistano applicazioni in cui una cpu in order e out of order abbiano prestazioni del tutto comparabile nessuno lo mette in dubbio.
Ma immagina una situazione magari pesantemente multi-threaded con molteplici accessi alla memoria.
In quel caso semplicemente le prestazioni di una CPU in-oder crolleranno, perchè appena trova una banalissima istruzione che richiede accesso alla memoria (una semplice MOV che carichi un registro ad esempio) e il dato non si trova nè nella L1 nè nella L2, allora la CPU si ritroverà a perdere un centinaio di cicli di clock nell'attesa del dato, perchè NON può in nessun modo eseguire le istruzioni successive.
Una CPU out of order invece, a meno di problemi di dipendenze, può tranquillamente continuare il suo lavoro mentre attende che il dato venga caricato dalla memoria.
Da notare come il modello in-order si adatti particolarmente ad elaborazioni di flussi di dati, ed è principalmente per questo motivo che è stato adottato nel cell (Oltre ovviamente al risparmio derivato dall'architettura è semplificata).

[Marko91]

Originariamente inviato da ^TiGeRShArK^

Nessuno lo mette in dubbio.
Non certo in real-time però

http://www.multiplayer.it/forum/show...postcount=3474

Qualcuno usera' certamente in futuro (e qualcuno lo fa gia' ora..) le SPUs per rimuovere triangoli non visti, per fare progressive mesh, displacent mapping, etc.. e certamente daranno una bella mano a RSX ,ma gli SPE sono cosi' stupidamente veloci che probabilmente una singola SPU potrebbe tranquillamente macinare qualche milione di triangoli per frame senza neanche sbattersi piu' di tanto

nAo è uno sviluppatore italiano che lavora nei Ninja Theory, il team di Heavenly Sword.

Sul forum di Beyond3D ci sono tonnellate di informazioni su Ps3, scritte da svariati programmatori di Ps3 e Xbox360.
http://forum.beyond3d.com/forumdisplay.php?f=15

Questo thread è particolarmente interessante e non ci sono numeri teorici ma numeri reali. La tech demo a cui mi riferivo prima è stata realizzata in sole 2 settimane da 2 programmatori attraverso questo nuovo tool di sviluppo chiamato Edge.
http://forum.beyond3d.com/showthread.php?t=39185&page=4

[^TiGeRShArK^]

Originariamente inviato da Criceto

E comunque quanto incide alla fine? Hai dei numeri?
Da quelli che ho visto io non molto, almeno non necessariamente tutti imputabili all'architettura in-order.

Se la semplificazione architetturale permette un innalzamento della frequenze (come nel caso del Cell) che colma il gap di prestazioni, semplicemente si è scelto un approccio diverso al problema, più efficiente dal punto di vista n. transistor/prestazioni, quindi più economico da produrre, ma ugualmente efficiente dal punto di vista prestazionale.

Credo che questa sia stata la filosofia di IBM per il Cell.

Che tipo di applicazione hai visto che si comportava in maniera pressochè equivalente tra Cell e Power PC?
Perchè, come ho detto prima, tale modello è utile soprattutto se utilizzato nell'analisi di flussi di dati (che è proprio l'utilizzo PRINCIPE del cell e per questo IBM ha scelto il modello in-order consentendo una maggiore frequenza per via della maggiore semplicità architetturale).

[Criceto]

Originariamente inviato da yossarian

non sempre è possibile spostare l'ottimizzazione a livello di compilatore; quando lo si può fare, in teoria il gap viene annullato; nella realtà, però, i chip IO risultano molto meno flessibili rispetto a quelli OoO e questo, in applicazioni di tipo GP è un aspetto da non sottovalutare.

Le architetture ooo sono necessarie sui PC perchè le implementazioni sono estremamente eterogenee e quindi chi fa il compilatore comunque non saprebbe per chi ottimizzare (Pentium III? Pentium IV? CoreDuo? Amd? Ecc). Ma di Cell ce n'è uno solo... almeno per ora e sicuramente per la PS3, quindi il lavoro dovrebbe essere più semplice e le differenze prestazionali minori.

[^TiGeRShArK^]

Originariamente inviato da Marko91

http://www.multiplayer.it/forum/show...postcount=3474

mi sfugge l'attinenza del post che hai linkato con quello che ti chiedevo sul radiosity in real-time

nAo è uno sviluppatore italiano che lavora nei Ninja Theory, il team di Heavenly Sword.

Lo so
Partecipò lungamente anke lui alla discussione di diverso tempo fa sul Cell, insieme a me, Yossarian, Cdimauro, Fek (programmatore della LionHead) e tanti altri che non ti sto a nominare che non finiamo +

Sul forum di Beyond3D ci sono tonnellate di informazioni su Ps3, scritte da svariati programmatori di Ps3 e Xbox360.
http://forum.beyond3d.com/forumdisplay.php?f=15

Questo thread è particolarmente interessante e non ci sono numeri teorici ma numeri reali. La tech demo a cui mi riferivo prima è stata realizzata in sole 2 settimane da 2 programmatori attraverso questo nuovo tool di sviluppo chiamato Edge.
http://forum.beyond3d.com/showthread.php?t=39185&page=4

tnx x i link
ora gli do un'okkiata

[yossarian]

Originariamente inviato da ^TiGeRShArK^

Le latenze del Cell, se confrontate con quelle di una GPU hanno latenze + elevate dato che il Cell non è affatto pensato per essere utilizzato come una pipeline grafica, e infatti è strutturalmente poco adatto.
Ma qui non so precisamente tutti i dettagli di una pipeline grafica e immagino che yossarian ci potrà illuminare molto di +.. io dal canto mio immagino che manchino registri temporanei in maniera sufficiente e che soprattutto la quantità di unità di calcolo del Cell è molto inferiore rispetto a quella delle moderne GPU.
(Basti pensare all'elevatissimo numero di pixel pipeline presenti nelle schede odierne..mi pare che siano in un numero BEN superiore a 7 )

un chip multithreaded prevede non solo più unità di immagazzinamento dati (registri e cache interne), ma anche circuiti logici di trasmissione e di controllo più complessi. In ogni momento, il controller deve essere "informato" della situazione dell'elaborazione per ogni singola alu, in modo da poter intervenire in caso di rischi di stallo (quindi deve esserci un continuo scambio di informazioni tra alu e controller).

[^TiGeRShArK^]

Originariamente inviato da yossarian

un chip multithreaded prevede non solo più unità di immagazzinamento dati (registri e cache interne), ma anche circuiti logici di trasmissione e di controllo più complessi. In ogni momento, il controller deve essere "informato" della situazione dell'elaborazione per ogni singola alu, in modo da poter intervenire in caso di rischi di stallo (quindi deve esserci un continuo scambio di informazioni tra alu e controller).

mmmm..
questo mi ricorda il ring-bus di R520.... o sbaglio?

[Criceto]

Originariamente inviato da ^TiGeRShArK^

Che tipo di applicazione hai visto che si comportava in maniera pressochè equivalente tra Cell e Power PC?
Perchè, come ho detto prima, tale modello è utile soprattutto se utilizzato nell'analisi di flussi di dati (che è proprio l'utilizzo PRINCIPE del cell e per questo IBM ha scelto il modello in-order consentendo una maggiore frequenza per via della maggiore semplicità architetturale).

La metà di un G5 a parità di frequenza, non proprio equivalente.

Questo: http://www.geekpatrol.ca/2006/11/pla...3-performance/
Ma ora non funziona.
E' un benchmark sotto Linux con decine di test...
Le differenze sono molte in un verso o nell'altro a seconda del test, ma il risultato è quello...
Lo stesso bench su un MacPro (Xeon 2.66 Ghz, credo) dava risultati circa 4 volte superiori, da cui è evidente perchè Apple è passata a quelli...
Ovviamente testa solo la PPE del Cell, visto che non include codice per le SPE.

[^TiGeRShArK^]

Originariamente inviato da Criceto

Le architetture ooo sono necessarie sui PC perchè le implementazioni sono estremamente eterogenee e quindi chi fa il compilatore comunque non saprebbe per chi ottimizzare (Pentium III? Pentium IV? CoreDuo? Amd? Ecc). Ma di Cell ce n'è uno solo... almeno per ora e sicuramente per la PS3, quindi il lavoro dovrebbe essere più semplice e le differenze prestazionali minori.

NO.
Il problema non dipende dall'architettura utilizzata.
Itanium per limitare in parte il problema utilizzava gli accessi alla memoria in maniera predicativa a livello di codice sorgente, in pratica il programmatore e il compilatore potevano dire quando pensavano che sarebbe avvenuto un accesso alla memoria e il codice sarebbe stato genereato con le istruzioni nell'ordine giusto per limitare i danni.
Il problema è però ke quest'approccio statico è molto meno efficiente di quello dinamico calcolato dallo scheduler del processore.
E, come ho detto prima, in applicazioni che richiedono molteplicic accessi alla memoria e che siano magari anche multi-threaded la differenza è evidente.

[^TiGeRShArK^]

Originariamente inviato da Criceto

La metà di un G5 a parità di frequenza, non proprio equivalente.

Questo: http://www.geekpatrol.ca/2006/11/pla...3-performance/
Ma ora non funziona.
E' un benchmark sotto Linux con decine di test...
Le differenze sono molte in un verso o nell'altro a seconda del test, ma il risultato è quello...
Lo stesso bench su un MacPro (Xeon 2.66 Ghz, credo) dava risultati circa 4 volte superiori, da cui è evidente perchè Apple è passata a quelli...
Ovviamente testa solo la PPE del Cell, visto che non include codice per le SPE.

ehm...
se non sappiamo che genere di test sono mi pare difficile analizzare alcunchè

[yossarian]

Originariamente inviato da Criceto

Le architetture ooo sono necessarie sui PC perchè le implementazioni sono estremamente eterogenee e quindi chi fa il compilatore comunque non saprebbe per chi ottimizzare (Pentium III? Pentium IV? CoreDuo? Amd? Ecc). Ma di Cell ce n'è uno solo... almeno per ora e sicuramente per la PS3, quindi il lavoro dovrebbe essere più semplice e le differenze prestazionali minori.

su una unica piattaforma le ottimizzazioni sono sicuramente più semplici; questo però non significa che ps3 o xbox360 non si sarebbero giovate dell'adozione di una cpu OoO; quando si fa un progetto si deve scendere a tanti compromessi: un progetto relativo ad una console impone più compromessi rispetto a molti altri. Questo perchè si hanno problemi di spazio, di raffreddamento, di contenimento dei costi. Il cell in particolare, poi, è pensato anche per applicativi che non necessitano di elaborazione OoO (al contrario di xenon che non credo si vedrà mai al di fuori di una console)

[yossarian]

Originariamente inviato da ^TiGeRShArK^

mmmm..
questo mi ricorda il ring-bus di R520.... o sbaglio?

no, il ring bus serve ad ottimizzare il trasferimento dati da e verso la ram e tra unità di calcolo; è la soluzione più efficiente tra quelle a buon mercato (non a caso è stata adottata sia da IBM sul cell che da ATi sulle sue gpu).
Il principio su cui si basa il ring bus è molto semplice: su un crossbar tradizionale, ogni braccio serve un certo numero di chip di ram. Nel momento in cui una unità di calcolo ha bisogno di accedere alla ram, l'arbiter riceve la richiesta di accesso, ne valuta la priorità (insieme alle altre richieste pervenute), la invia al chip a cui è stato chiesto di accedere e quindi procede all'evasione della richiesta. In pratica, segue tutto il processo, ad esempio, di trasferimento dati da e verso la ram (che si può dividere in 4 fasi).
Con il ring bus, invece, una volta che il controller ha ricevuto la richiesta e l'ha inoltrata viene reso libero di passare ad elaborare altre richieste; supponiamo che si debba trasferire dei dati da un chip di ram verso un'unità di calcolo, questi sono messi in circolo all'interno del ring (ovviamente il pacchetto contiene anche l'informazione relativa alla alu o pipeline che deve farne uso); una volta che il pacchetto arriva in corrispondenza dell'unità che ne ha fatto richiesta, viene automaticamente smistato senza ulteriori interventi da parte del controller.
Ovvio che anche una struttura ad anello presenta dei punti deboli e, all'aumentare del numero di unità di calcolo o di chip di ram, rischia di perdere efficienza (questo è uno dei motivi per cui nei chip ATi, le unità sono sempre raggruppate in cluster di 12, 16, ecc, alu).

Invece, ad essere multithreaded è la singola pipeline (o la singola alu)

[R@nda]

E dimmi quando pensate di farci vedere l'R600?( )

[yossarian]

siamo pericolosamente OT

[R@nda]

Ops ( ) hai ragione, mi spiace.

[tDx3]

ottima novità, perché non partecipano anche le altre consolle al progetto? sarebbe bellissimo, immaginate come si accorcerebbero i tempi di ricerca.


p.s. comunque volendo butterei dentro anche i comunic pc.

[blackshard]

Originariamente inviato da Matrixbob

Ti auguro di non ammalarti mai delle seguenti malattie:
morbo di Parkinson o di Alzheimer, la fibrosi cistica e altri cancri.
Perchè la tua idea d'andarci CONTRO avrà rallentato le rispettive ricerche.

In conclusione ricordiamo che la maggior parte dei risultati sono di dominio pubblico e quindi consultabili da chi na ha bisogno.

Tu sei completamente pazzo! E non capisci una ceppa di quello che leggi.
Come al solito c'è sempre chi legge una cosa e poi parte per la tangente facendo connessioni in lungo e in largo.
Ti rendi conto di quello che TU pensi che IO sia contro la ricerca? Dov'è che ho scritto "sono contro la ricerca"? Trovamelo dai, ti do' 1000 euro.
Ti rendi conto che io stavo commentando solo e soltanto la notizia e i riflessi pubblicitari per sony, e non ho mai detto nulla sulla bontà di folding@home?

Bah... probabilmente sono solo parole sprecate...