La CPU di PlayStation 3 impiegata seriamente con Folding@home

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.

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).

http://www.multiplayer.it/forum/sho...;postcount=3474



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/showthrea...9185&page=4

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).

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.

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

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 +

tnx x i link
ora gli do un'okkiata

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?

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.