Confronto GPU ps3 Vs Xbox360

Al Game Developer Conference del 2006, in una slide della presentazione della NVIDIA, si faceva riferimento ad un "8 Ch Audio" collegato direttamente all'RSX.
E' molto probabile che la PS3 monti a bordo, dentro l'RSX, qualcosa di molto simile al "SoundStorm", progetto poi abbandonato dalla stessa NVIDIA.
In un articolo di The Tech Report viene anche ricordata una affermazione del CEO di NVIDIA, Jen-Hsun Huang, riguardo alla nuova generazione di chip audio SoundStorm - che non è mai stata presentata - che sarebbe arrivata "in un modo che nessuno si aspetta".


Se così non dovesse essere sarebbe un "carico" in più sulle spalle del Cell.

Resta il fatto che sono tutte supposizioni perchè NON ESISTE DOCUMENTAZIONE ufficiale su questo argomento.

L'audio sul 95% dei pc è sempre stato a carico di cpu monocore... e non è MAI stato un problema. Tutt'ora utilizzo una discreta cpu dual-core e scheda audio con compressione DTS software... figuriamoci il Cell... neanche lo "sente" l'audio...
Tutta la discussione poi sulla GPU è un po' parziale, perché come ha finalmente ricordato Contezero... il lato grafico è imprescindibile dal Cell, visto che le potenzialità del Cell vanno oltre le normali cpu x86/ppc. Oltretutto non è una normale cpu "Sony", ma è una cpu IBM con delle caratteristiche molto particolari e differenti da tutto ciò che c'è sul mercato... Quindi è naturale che inizialmente non si sfruttino a fondo le sue possibilità, come del resto accade perfino con cpu più semplici... Discorso a parte invece va fatto per l'X360 che è partita già con ottimi SDK e quindi spremuta quasi a fondo a 1 anno dal lancio...
Ritornando alla PS3, la sua potenza sta proprio nelle particolarità dell'accoppiata Cell + RSX... Oltretutto se andate bene a vedere, i giochi più scarsi e mal ottimizzati senza AA, spesso non fanno uso nemmeno dell'HDR... quindi non è neanche un problema di HDR + AA... Il che mi fa pensare che anche a livello di operazioni cpu utilizzino soltanto il core principale, uno solo!

p.s. Per chi parla di DirectX10: si vada a cercare i benchmark che ci sono in giro e si faccia 4 risate, al momento le DX10 vanno peggio a parità di grafica......

Quello che hai copiato ed incollato come fosse il Verbo è solo quello che un PR Microsoft, che allora si presentava come "sviluppatore" ha scritto approposito del Cell.
Stando così le cose devo mettermi di nuovo nei panni di fanatico di architetture e simili e farti un esame approfondito...

Qui si vede che Sony l'aveva sparata grossa, non sono 2 teraflops, ma 1/10 di tale potenza, 25 GFlops a SPE + 25 GFlops per il PPE (dati IBM).

Si ? E perchè ? Perchè ha il triplo dei processori PowerPC ?
Ti sei mai chiesto cos'è il "general purpose processing power" ?
E'rumenta, non è mai stato indicato un valore indicabile come "general purpose processing power", non c'è un tale indice per i PC, non c'è per i processori in genere e via dicendo.
In italiano suona come "potenza computazionale per scopi vari" e lì vai a metterci dentro di tutto!
Nel "general purpose" c'è anche il set SIMD (è potenza di calcolo ad uso generale, e comunque anche gli SPE possono lavorare in SISD), quindi anche gli SPE possono fornire "general purpose processing power".

E questa da dove esce ?
E'un dato acclarato da chi ?
La fonte ? Le prove ?

Ecco, poi qui sarà bene tornarci dopo, quando faremo le somme delle bandwidth.

Su sette processori SIMD, i DSP (Digital Signal Processor) sono processori SIMD specializzati.

Fonte ? Notizie ? Datasheet ?
Ad oggi non c'è uno straccio di documentazione ufficiale su RSX, eppure ogni giorno viene qualcuno a proporre la superiorità "indiscussa" (ed indiscussa è, perchè viene affermata senza prove a riguardo) di Xenos.

Vero, se facciamo le somme delle bande come gli idioti.
Da un lato abbiamo solo la somma della banda della GDDR3 e XDR (su PS3) e dall'altro abbiamo somme di tutte le bande...
Ma vogliamo guardare un attimo l'architettura ?


Secondo te ha importanza tenere conto dei 256GB/s della banda dell'eDRAM ?
No, perchè io la vedo un attimo una forzatura, se poi vogliamo farlo possiamo anche iniziare a contare anche la banda del BUS EIB (200+ GB/s) che collega i vari SPE.
La memoria, a quel che vedo dal disegno, ha una banda di 22,4 GB/s, e questa è la bandwidth a cui tutti si riferiscono... i 256 GB/s (che poi sono limitati a 32 GB/s dal bus di comunicazione) sono solo per texture e texture filtering.

Eccoci, fonti ? approfondimenti ? storie ?
I processori dell'XBox360 e quello della PS3 sono ambedue progettati dalla stessa società, IBM.
La differenza è che Sony ha investito budget incredibili nella progettazione di Cell, tant'è che i Cell vengono usati anche fuori dalla PS3, mentre Xenon se lo fila solo la XBox360.
In ogni caso avessi un minimo di conoscenza sulla grafica 3D e sui giochi in generale sapresti che l' 80% dei calcoli di un videogioco (la parte della grafica, dei modelli, dei calcoli e via dicendo) è rappresentato da matematica in virgola mobile.

I "vettori matematici" sono in floating point o interi, e gli SPE lavorano su vettori floating point ed interi, per questo vengono chiamati, oltre che unità SIMD (Single Instruction, Multiple Data) anche Vector Processor (processori vettoriali) ed i vari "branches" e "accessi casuali alla memoria" sono presenti ovunque, uno SPE è in grado di effettuare branch ed accessi alla memoria, le performance in quel caso sono comparabili a quelle di un processore classico.

I sette vector processor del Cell non hanno bisogno di cache, la cache è un blocco di memoria intermedio che serve a lenire le penalità di accesso alla RAM, essendo la RAM degli SPE on chip (vogliamo considerare anche la bandwidth della RAM degli SPE ? siamo sui 256GB/s se non oltre, dovrebbe essere eDRAM pure quella) la "penalità" per accedere alla RAM degli SPE è di uno/due cicli a 3,2GHz... che cosa vuoi mettere in cache quando la cache ha una latenza di uno/due cicli a 3,2GHz (no, beh, su Xenon la cache "viaggia" a 1,6GHz anzichè a 3,2GHz, ma quella è un altra storia).
Quanto al branch prediction non c'è bisogno, stando al Cell Handbook (manuale IBM) gli SPE considerano i salti come se NON venissero eseguiti.
Esiste però un istruzione che dice, esplicitamente, "fai conto che il prossimo salto venga eseguito", in pratica un branch hinting, in questo modo non c'è bisogno di un unità di branch prediction, è il programmatore (o il compilatore) ad indicare se i salti avverranno o meno quando scrive il codice, snellendo l'hardware e migliorando l'efficienza del codice.

E'vero che i VMX128 di Xenon sono molto più potenti del VMX del PPE, però anche il PPE ha un VMX, ed in ogni caso non ci vedo niente di male ad avere sette unità SIMD indipendenti anzichè un unità SIMD "appiccicata" ai processori, direi che in questo campo... su floating point e vector processing, non c'è proprio storia indipendentemente da come la giri.

No, ha un operazione simile, solo che non si chiama "dot product", questo è uno spin.

Questo non ha senso, anche perchè se tale problema (che non è neanche chiaro) esistesse ci sarebbe, identicamente, anche in Xenon.

Il Cell ha la cache L2 per il PPE, 512K di cache L2 (considerando che c'è un solo core anzichè tre è già sufficiente), e come ho già detto gli SPE non hanno bisogno di cache.

Toh, fatto con la calcolatrice... 100 / 8 x 1.
A parte che poteva usare SIMD calculations (ed allora avrebbe avuto ragione, ma avrebbe dovuto ammettere che l'80% del codice dei giochi è, in genere, SIMD) il discorso è che stà girando in tondo.

Questa è nuova, in ogni caso il problema, e qui ci tengo a sottolinearlo, non è quanta parte del codice è floating point, ma quanta parte del codice ESEGUITO è floating point sull'insieme.
Mi spiego meglio, l'IA non è quasi mai SIMD, è molto scalare ed occupa una percentuale rilevante del codice, ma il codice per l'IA viene eseguito pochissimo se lo mettiamo in relazione con il codice floating point che si occupa delle trasformazioni tridimensionali, del calcolo delle normali, del collision detection e via dicendo.
Questo è il solito giocare con le parole.

Ecco, questa mi mancava... floating point per l'IA e per il path finding...
In ogni caso, ci tengo a ricordarlo, gli SPE, che sono SIMD, possono funzionare come SISD e svolgere lavori con accessi non localizzati alla memoria e branch, in quel caso le loro performance calano a quelle... di un processore general purpose standard, ma quella è.

I branch ed i load/store sono tipici di tutti i processori, siano essi SIMD o SISD, questo è un altro spin.

Cioè, 'sto tizio dice che gli SPE fanno cagare anche per i load/store...
Ecco un altro spin.

Il resto è solo roba messa lì a casaccio.


Andando ai fatti, caro Raffa, posso sì giudicare l'architettura, ho studiato le architetture degli elaboratori all'università ed ho abbastanza conoscenze in materia per dire che il 99% di quello che c'è in quel testo è propaganda, ed il restante 1% è "informazione" cucinata per far sembrare il restante 99% vero.

Tu invece posti inesattezze e propaganda senza capire cosa dici, e poi dici che non possiamo confutare nulla perchè l'ha detto questo o quello, la tua è una posizione indifendibile perchè si limita a prendere in esame solo le fonti (fonti questionabili) che tornano utili al TUO ragionamento.
A questo punto se ritieni ancora di aver ragione ti chiedo di parlare con un altro qualsiasi op relativamente a quanto ho scritto io ed a come ho ribattuto il testo che hai copiato qui; se, come credo, ti diranno che hai torto, sei pregato di smetterla di fare queste uscite da fanboy.
Considerati avvertito, questa disinformazione inquina qualsiasi discorso serio... non possiamo costruire una discussione seria se spunta sempre qualcuno ad incollare propaganda.

Contezero è inutile che fai il professore..stava scritto di postare notizie sul confronto delle due console,non facendo il programmatore, ho cercato e ho messo l'unico articolo che c'era inerente al confronto..

Infatti quando inizio a scrivere, lo dico ecco cosa ho trovato..ma quale fanboy..a me che me ne frega di chi è piu' potente l'unica cosa importante sono i giochi non la potenza..percio' cerca di fare meno il professore..forse il fanboy lo sei tu...io non dico che le tue cose sono cavolate, in quanto non ho la conoscenza per poterlo fare..Pero' visto la tua bravura smonta questa notizia del tribe di un programmatore e argomentala cosi ci fai piu' felici tutti

http://ps3.console-tribe.com/news/2...-ps3-cell-processori-console-a-confronto.html

QUesta è la notizia che diceva secondo questo prog che un gioco ps3 difficilmente poteva venire come quello 360..

Secondo me non è vero un gioco ps3 puo' venire piu' in la anche molto meglio di uno 360, ma non sono in condizioni di poter ribattere quelo che dice questo tipo..tu sei in grado??

Già siamo scesi molto sotto tono rispetto a prima, in ogni caso quella che viene tirata fuori è l'affermazione di un tale che ha scritto su AVSforum... non un programmatore (o meglio, non c'è modo di sapere se lo è, ma da quello che dice direi di no), andiamo a smontare le sue uscite...

Questa è la traduzione in italiano di un articolo scritto da mterzich, utente del forum AVS:

Qui c'è la prima imprecisione, GROSSA imprecisione.
La cache è solo per il PPE, gli SPE non hanno accesso alla cache L2 del PPE, il calcolo di 512K / 7 non ha senso.
Tra l'altro viene omesso che anche il PPE è multithreading, come i core di Xenon.

Andiamo alla parte relativa alla PS3.

Questo è un quote un pochino così, la PS3 è stata progettata per i giochi, come tutte le console.

Questa è una ipersemplificazione, gli SPE sono progettati per funzionare su compiti molto ristretti a velocità tremendamente elevate rispetto ad un normale processore, nulla vieta ad uno SPE di svolgere diversi compiti, di avere codice con molti branch o non tipicamente computazionali, è solo che il massimo delle performance si ha con l'elaborazione SIMD in streaming, ma... nuovamente, non è che gli SPE possono fare solo quella.

Qui si suppone che il modello per sviluppare giochi sulla PS3 sia lo stesso dell'XBox360.
Non è così e questo rende quello che segue solo un opinione.

Se è per quello ci sono molti giochi, su PC, che hanno eseguibili ben al di sotto dei 100 Mb, gli SPE devono tenere nella loro memoria interna solo il codice che svolge alcuni frammenti d'elaborazione, frammenti che verranno eseguiti ad una velocità superiore rispetto a quella ottenibile su un processore SISD classico.
Ovvio che non ha molto senso eseguire un programma intero in uno SPE, però è anche vero che se il 70% del tempo in un programma viene speso nel calcolare le normali ad un triangolo allora il codice che calcola le normali può essere messo in uno SPE che eseguirà il compito molto più velocemente di una CPU classica.

Questo dimostra che non è un programmatore.
Senza Branch Prediction le diramazioni non dovrebbero esserci, perchè piccole o grandi che siano provocano sempre lo stesso fault.
In ogni caso s'è già detto (andatevi a leggere il Cell/B.E. Handbook) che gli SPE non hanno Branch Prediction perchè hanno un sistema di branch hinting esplicito, e quindi l'intero argomento perde di significato.

Solo il frammento di codice che svolge determinate funzioni dev'essere contenibile in 256K, i dati possono essere caricati e scaricati dal codice stesso via DMA ed anche gli SPE possono essere "resettati" e riprogrammati a runtime.

Gli SPE possono essere programmati per avere parte del lavoro tipicamente svolto dalla GPU, in ogni caso è da oramai cinque mesi che Sony ha distribuito ai programmatori gli SPURS, codici ottimizzati da caricare sugli SPE per fargli svolgere operazioni di prerendering e simili, se un programmatore non si vuole "sbattere" ha solo che usare gli SPURS di Sony.

Infatti i programmatori sono pagati per usarli al meglio.
In ogni caso se giochi a Galaga non puoi aspettarti di trovare un codice che usi tutti gli SPE, usi solo quelli che ti servono.

Cioè, due secondi prima si lamenta che è difficile riempire sei processori, ed ora dice che è un casino farci stare più roba ?
Gli SPE possono essere sprogrammati e riprogrammati, in modo da poter usare "thread software" e la PPE funziona in multitasking come ogni CPU general purpose.

Non è esatto, un codice SPE occupa al max 256K ma considerando che all'interno ci sono anche i dati è facile che l'intero upload di un codice sia 64K, e questo ammesso di dover schedulare più di sei processi SPE in unità di tempo (già ora gli SPURS hanno diverse funzioni interne e sono in grado di svolgerne diverse senza riprogrammarsi), inoltre i programmatori di Resistance hanno mostrato com'è possibile realizzare una procedura che effettua lo scheduling del codice (dove necessario) dall'interno dello SPE stesso, in pratica lo SPE può "caricarsi" il nuovo codice senza aver bisogno del PPE.
Non lo dico io, lo dicono gli Insomniac, leggere per credere: http://www.insomniacgames.com/tech/articles/0807/files/dynamic_spu_code.txt

Altre frecce al tuo arco ?

Quello che non è emerso in maniera chiara ,
è che ogni SPE ha una sua memoria di 256K
e possono elaborare senza interferire minimamente con il resto dei core ,
questo abbassa in maniera impressionante la richiesta di banda sulla ram di sistema,

il Cell non è un processore singolo
l'elaborazione non è SIMMETRICA

è nato per l'elaborazione REAL-TIME

Faccio un esempio terra-terra

alla partenza del gioco carico i singoli SPE con le funzioni/procedure
più utilizzate nel programma

il PPE non farà altro che distribuire i dati alle spe
e passerà a raccoglierli quando avranno finito.

A condizione che i dati e il codice funzione/procedura possano stare in 256k
della LS dello SPE (posso assicurarvi che 256k sono molti per delle librerie ottimizzate)

la banda occupata sulla ram di sistema sarà solo quello dei dati da elaborare
signori questo approccio alla programmazione è RIVOLUZIONARIO

Se domani Sony/IBM/nvidia vendessero una board microatx
basata su PS3 con 1 Giga di ram o più , potremmo avere delle workstation/SERVER Linux con prestazioni STELLARI

Credo che un immaginina aiuti:

Salve ragazzi, tempo fà avevo letto un post con interessanti confronti tra le GPU della PS3 e della 360 ed in particolare all'utilizzo dei tool EDGE e quindi della possibilità di utilizzare le SPE per aiutare la GPU nel calcolo dei Vertex shader.

"Just a follow up on SPE's power as vertex shader
A lot of people especially PC base tech people said Xeno in 360 is more powerful then RSX.
Which is nonsense and don't meant much at all, simpliy due to the fact how PS3 works.

The main reason why most said Xeno is more powerful is due to it's unify shader, then is the larger video RAM due to the share RAM system.
Frankly this is a pure bias comment from a PC view of angle.

Unify shader don't meant anything, frankly it will be a waste of die size for PS3.
Simpliy because PS3 already have 6 super fast all purpose stream engine.
If you don't know a shader is only a type of stream engine.
So you can consider PS3 has 6 unify programmable game engine running at 3.2 GHz, which runs over 6 times faster compare to Xeno's slow 0.5GHz.

Let's look at the numbers:

RSX
24x27FLOPSx500MHz=324GFLOPS =>Pixel Only
8x10FLOPSx500MHz=40GFLOPS =>Vertex Only

Xeno
48x10FLOPSx500MHz=240GFLOPS =>Pixel or Vertex

The usual arragement is 2:1 for pixel to vertex, unless you try to make games like dead rising when Capcom used 1:1, to make as many on screen character as possible.
So usually you can consider Xeno as a 160GFlops Pixel and 80GFlops non-unify GPU.
Now you can start to see really how power full Xeno is, very much a 7900 GT.

SPE due to it's more complex intruction set it can run as a vertex shader at 50~100GFlops.
Depending on culling rate and skin layers, 1 SPE can run approx 144 million vertex with fully shaded.
800,000 polygon in 60 fps (take one polygon as 3 vertex smallest polygon posibble)=> 800,000x60x3=144million vertex per second.
This has been show in GDC07 by PS Edge show case.
So simply directing 2 SPE to give RSX a hand on vertex will already kick Xeno out of the window.
And 360's CPU is only equal to PPE + 3 SPE, consider both have their pros and cons.
PS3 still have 1 extra SPE to kick around for other stuff like physic or AI.

Xeno in 360 can go up to 500 million vertex per second when all pipeline is used for vertex, and that will never happen unless you want a game with just lines flying around on screen.
So in reality Xeno only can do 170~250 million vertex per second.
In dead rising the game that has top vertex count in 360 run at 200 million vertex per second.

Where RSX's own vertex shader can perform around 100~140 million vertex per second.
With just one extra SPE running the special SPUP instruction for vertex processing, you are already looking at 250 million vertex per second minimum with hipes pixel power to spare.

With 2 SPE the number goes on a amazing 400 million vertex per second, that's double of dead rising, still with a lot of pixel processing power to spare.
People just don't realise how important and powerfull PS Edge is."

Veramente uno SPE offre 25GFlops, non 50-100GFlops.

In ogni caso ha senso il discorso che pone RSX e Xenos sullo stesso piano, magari RSX è leggermente superiore, magari è leggermente inferiore, ma è lì.
Invece si fa presto a dire che il Cell è scarso come CPU e come GPU e ci si scorda che la PS3 una GPU per i fatti suoi ce l'ha già.

OT

Oè... la vogliamo smettere di fare i sapientoni?
Dai, cambia atteggiamento o passi dalla parte del torto, anche se quello che dici è esatto.

L'atteggiamento "io ho sempre ragione" non t'aiuta a conversare ma solo ad autocelebrarti! Se è quello che vuoi fai pure, ma non t'aspettare conversazioni costruttive.



IT

Si, infatti è quello che penso anche io, a livello di potenza sono abbastanza simili, ma un vantaggio lo Xenos c'è l'ha ed è l'architettura degli shader unificati che gli permette di avere una maggiore flessibilità ma dall'altro lato la perdita delle unità specializzate genera un trade-off con la potenza.

Ma l'informazione più interessante di quel post, era quella relativa ai tool di EDGE, e al fatto che adoperando una sola spe si potessero calcolare la bellezza di 800.000 poligoni a 60flps o 1.600.000 poligoni a 30flps senza prendere in considerazione l'RSX.

E quindi sommando per esempio i poligoni generati da 2 spe e dall'unità vertex dell'RSX si arriverebbe a delle cifre veramente notevoli e tutto questo senza ridurre la potenza delle unità pixel shader dell'RSX.

Sono decisamente stufo di chi posta propaganda presa in giro come verità universali, forse stò andando un pochino fuori di testa, lo ammetto, ma ammetterai che in una sezione del forum PS3 è quantomeno strano che ci sia ancora gente che passa per veri libelli anti-PS3 del 2005.
Il problema non è neanche tanto quello, il problema è chi pur senza capire cosa si dice è sempre pronto a copiare & incollare quel che legge in giro, e magari poi s'ostina a dire al prossimo "tu non puoi sei nella condizione di commentare..." (cfr. qui: http://forum.console-tribe.com/ps3-...onto-gpu-ps3-vs-xbox360-35108.html#post282407 ).
Io non ho la scienza infusa, e le cappellate le faccio anch'io, ma almeno non sono sempre lì ad incollare qualcosa che non ho potuto verificare, non ho l'ardire di prendere discorsi recuperati in chissà quale anfratto della rete e farmi grosso dicendo "eh beh, ma qui uno ha detto che".
Ci sono prove sulla PS3 che non è un buon pezzo d'hardware ?
Ok, parliamone... ma "parliamone", non stiamo qui a fare i megafoni di chissà quale PR.

Al tipo in questione (raffa1986) era stato detto che quello era semplicemente propaganda e che non era il caso che postasse più di queste cose (cfr. qui: http://forum.console-tribe.com/ps3-...onto-gpu-ps3-vs-xbox360-35108.html#post282157 ) se poi lui non s'accontenta dell'avviso non ho altro da fare che smentire le fesserie accluse.

Non ti incazzare Conte ....
io in pochi mesi che frequento il forum , ho visto notevoli progressi .
di pappagalli è pieno il modo , di persone che SANNO qualcosa, poche ...
(forse sempre meno)
mancano poche settimane per togliere gli ultimi veli al potenziale del "ferro" PS3,
così anche chi di hardware non capisce una cippa , dovrà/potrà avere un'idea chiara.

"La punizione è necessaria solo quando il reo la esige" - Casata Atreides.

Allora, stando ai dati che circolano ci si aggira sui 200 GFlops complessivi (204.8 per la precisione).
In ogni caso quello è il teorico massimo, in pratica si arriverà ai 100 GFlops in applicazioni tipiche (il resto sono branch, load/store e simili), già così siamo comunque ben al di sopra di quello che potrebbe fare un sistema "classico".

Ti rimando a Wikipedia per una trattazione leggermente più complessa:
http://it.wikipedia.org/wiki/Cell_(processore)

Ma la cifra sparata dalla Sony all'e3 del 2005 non si riferiva alla cpu ma alla somma cpu+gpu:http://ps3.ign.com/articles/614/614682p1.html

Era la gpu che era accreditata di 1,8 Tflops, mentre la cpu la davano a 216 Gflops.

E questo perché prima la MS la aveva sparata bella grossa anche lei dicendo che la 360 arrivava a 1 Tflops: http://www.betanews.com/article/Microsoft_Reveals_Xbox_360_Specs/1115954701

Mah, i FLOPS della GPU non hanno molto senso (hanno qualche senso -ma non troppo- su Xenon perchè tramite memexport puoi usare gli shader come processori SIMD sulla memoria) in ogni caso se il conto è giusto...

RSX:

24 Pixel Pipelines x 27 FLOPS x cycle = 648 FLOPS x ciclo
8 Vertex Pipelines x 10 FLOPS x cycle = 80 FLOPS x ciclo
-> 728 FLOPS x ciclo
728 x 550 = 400400 MFLOPS -> 400.4 GFlops (ora non ricordo esattamente, mi pare che RSX sia clockato 550 MHz)

Ma tieni conto che sono tutti, tuttosommato, "cucinati" per la grafica.
ATi, che ha fatto un client Folding@Home per schede ATi x19X0 ha ammesso, ad esempio, che metà delle operazioni (dei FLOPS) è buttato via a causa del modello delle GPU che rende molto difficile usare in modo pratico quei calcoli al di fuori del rendering.
Invece i FLOPS di Cell (e di Xenon) sono "reali", nel senso che sono operazioni che è possibile utilizzare in modo abbastanza flessibile dal punto di vista computazionale.

A conti fatti siamo a 400 + 200 ~ 600 GFlops totali, contro i 240 + 116 ~ 356 GFlops della XBox360, ma nella pratica questi numeri hanno ben poco a che fare (se usati in questa maniera) con l'effettiva potenza offerta.

La cosa che cambia, è importante capirlo, è la potenza offerta realmente.
I Pentium4 offrivano potenze di calcolo impressionanti, ma alla fine non andavano quando gli AMD che erano più lenti e meno performanti sulla carta (alla fine Intel ha aggiunto l'hyperthreading per migliorare l'efficienza interna... infatti nei Core, che sono molto più efficienti, l'hyperthreading è scomparso), e la ragione era che il collo di bottiglia era (ed è) la memoria.
Cioè, puoi avere 600 GFlops sulla CPU da sola, ma se le ALU stanno ferme in starvation (a morire di fame) perchè non ci sono dati in ingresso alla fine i GFlops reali sono quelli che macina.
Il vantaggio del Cell è tutto lì, visto che il codice degli SPE è "dentro" alla CPU e visto che non utilizzano cache i trasferimenti sono solo per caricare e scaricare, ordinatamente, i dati o per l'upload di blocchi di codice.
Un processore classico ha swap-in e swap-out di cache, accessi alla memoria più disordinati ed in generale meno efficienza... Cell con il suo modello riesce ad avvicinarsi di più alla potenza di calcolo teorica mentre una CPU normale perde buona parte della sua potenza teorica nel collo di bottiglia dovuto alla memoria.

Se il clock fosse 550 si, se invece siamo a 500 allora un pò di meno e cioè 364 Gflops.

I 116 Gflops mi sembrano una grandissima sparata della MS, con tutti i colli di bottiglia che si ritrova mi sembra francamente impossibile che arrivi a più della metà della potenza del Cell.

E' chiaro che i flops delle gpu non possono essere paragonati a quelle delle cpu viste che le prime sono specificatamente rivolte all'ambito grafico e quindi poco flessibili, ma sono utili per poter fare un confronto tra le varie schede grafiche.


Sulla capacità teorica di raggiungere e mantenere il picco dichiarato dai produttori mi vedi perfettamente d'accordo, il cell con le spe dotate di LM e grazie all'EIB e soprattutto al bus di 26Gb/s verso la memoria RB con la sua bassa latenza può veramente raggiungere delle potenze vicine a quelle di picco.

I 116 GFlops sono teorici, esattamente come lo sono i 200+ del Cell, la differenza è che il Cell se lavora bene a 150 c'arriva, Xenon è tanto se arriva a 50 reali.

OFF TOPIC

Oh, giusto per chiudere tutti i discorsi che ci sono di mezzo, il primo post può essere tracciato fino a:

http://www.majornelson.com/archive/2005/05/20/xbox-360-vs-ps3-part-1-of-4.aspx

Ora date un occhiata a quel sito e ditemi se vi sembra una fonte attendibile, l'about dice:

Non che chi ha postato doveva saperlo, ma averci qualche dubbio prima di riportare la cosa (considerando anche che non è difficile vedere che per lo più sono fesserie) non sarebbe stato male.

/OFF TOPIC

Salve in questo topic farò un solo ed unico post dato che mi sono un pò stufato di questo discorso e dato che cmq i numeri restano tali senza che qualche talentuoso team di programmatori convertano questi in un bel mondo virtuale bello da guardare da sentire e da vivere.
Detto questo ho selezionato una sfilza di articoli un pò semplificati atti a far comprendere anche sommariamente le potenzialità (perchè di questo si tratta, se non ci fai il software l'hw non serve a una cippa!!!) a chi normalmente non mastica numeri ed informatica in generale.

Ecco le specifiche dal comunicato ufficiale Sony riguardanti la GPU di PS3:

GPU RSX
• 550 MHz
• vertex/pixel shaders indipendenti
• 51*10^9 prodotti scalari al secondo (performance totali del sistema)
• 300*10^6 transistor
• 136 “shader operations” per clock


I numeri interessanti riguardo alle performance dell’ALU sono i 51*10^9 prodotti scalari al secondo ed i 300*10^6 transistor. Più del doppio di una 6800 Ultra.

I 51*10^9 prodotti scalari al secondo sono elencati in una slide per le performance totali, che includono anche il processore Cell. I calcoli di Sony fanno pensare che il Cell può eseguire un prodotto vettoriale a ciclo per DSP, nonostante questi non abbiano istruzioni apposite per questa operazione.

Comunque, usando le affermazioni di Sony, 7 prodotti scalari a ciclo * 3.2 Ghz fanno 22.4*10^9 prodotti scalari al secondo solo per la CPU, che lascia 51 – 22.4 = 28.6*10^9 prodotti scalari al secondo per la sola GPU. Questo implica che 28.6*10^9 / 550 Mhz = 52 operazioni GPU ALU per ciclo di clock.

È importante notare che se le ALU dell’RSX sono simili a quelle della Geforce 6800, lavorano sui vector4, mentre le ALU della GPU di Xbox 360 lavorano sui vector5. Le performance totali in Floating Point della GPU di PS3 dovrebbero essere: 52 operazioni ALU * 4 float per operazione * 2 (madd) * 550 MHz = 228.8 GFLOPS, che sono meno di quelle di Xbox 360: 48 operazioni ALU * 5 float per operazione * 2 (madd) * 500 MHz= 240 GFLOPS.

Nella GPU di Xbox 360, con un numero di transistor di poco superiore (330*10^6 contro 300*10^6), non è sorprendente che il numero totale di GFLOPS programmabili sia molto simile.


GPU : Programable Shader GFLOPS(IMMAGINE)



PS3 ha i 7 DSP addizionali sul Cell per eseguire più operazioni in Floating Point per il rendering, ma Xbox 360 ha 3 Core General Purpose con istruzioni Direct3D e prodotti vettoriali che sono più adatte nei veri calcoli relativi alla grafica.

La 6800 Ultra ha 16 Pixel Shading Pipe, 6 Vertex Shading Pipes e viaggia a 400 MHz. Si può stimare all’incirca che l’RSX abbia 24 Pixel Shading Pipes e 4 Vertex Shading Pipes (sono di meno perché i DSP del Cell ne hanno già qualcuna). Se PS3 mantiene l’architettura della 6800 (ed è ciò che si evince dalle press release), questo significa che ha 24 Pixel Pipes * 2 impiegate per pipe + 4 vertex pipes = 52 prodotti vettoriali per clock nella GPU.

Riguardo le Shader Operation per clock, Sony conta di far eseguire ad ogni Pixel Pipe 4 Operazioni ALU e una di Texture, 4 operazioni scalari per ogni Vector Pipe, per un totale di 24 * (4 + 1) + (4*4) = 136 operazioni a ciclo o 136 * 550 = 74.8 giga-operazioni al secondo.


GPU: Shader Operations per Second(IMMAGINE)


Avendo la GPU di Xbox 360 un design multithreading e bilanciato, non è possibile comparare i due sistemi in termini di Shading Operations per Clock. Comunque, la GPU di Xbox 360 è in grado di generare 160 Operazioni per ciclo o 160 * 500 = 80 giga-operazioni al secondo, calcolate così:

48 operazioni ALU (ognuna delle quali fa operazioni vector4 e scalari per clock)
16 texture fetches
32 operazioni di controllo di flusso
16 operazioni programmabili di vertex fetch con tessellazione per clock
48*2 + 16 + 32 + 16 = 160

Comunque, il bilanciamento automatico del carico degli shader, le features di esportazione della memoria, i vertex feching, i trangle tesselator programmabili e altre caratteristiche innovative della GPU di Xbox 360 “ben al di là dello Shader Model 3.0”, dovrebbero contribuire alle performance generiche di rendering.

Larghezza di banda della Memoria
PS3 ha 22.4 GB/s per le memorie GDDR3 (256 Mb) e 25.6 GB/s per le RDRAM (256 Mb)
Xbox 360 ha 22.4 GB/s per le memorie GDDR3 (512 Mb) e 256 GB/s per la EDRAM (10 Mb)


Total Memory System Bandwidth(IMMAGINE)


Gran parte della larghezza di banda è consumata dal Frame Buffer. Per esempio con un semplice Color Rendering e uno Z testing, a 550 MHz, il frame buffer richiede da solo 52.8 Gb/s in 8 pixel per Clock. La larghezza di banda di PS3 è insufficiente per mantenere questa velocità, anche senza texture e vertex fetches.

PS3 usa una compressione per cercare di compensare questa mancanza di larghezza di banda, il problema è che questa compressione non funziona molto bene quando si renderizzano delle scene 3D complesse.

L’High Dinamic Range, l’Alpha blending e l’antialiasing richiedono ancora più banda. È per questo che Xbox 360 ha 256 Gb/s di banda riservata solo per il frame buffer. Questo permette alla GPU di fare Z testing, HDR e alpha blended color rendering, con Antialiasing 4x alla massima velocità, disponendo ancora di 22.4 Gb/s di banda per texture e calcolo dei vertici. Ciò implica avere attivato l’antialiasing in tutti i giochi perché disponibile a costo zero.

Conclusioni
Se guardiamo solo i numeri, Xbox 360 è probabilmente più potente di PS3. Tenete inoltre presente che Sony ha la fama di promettere e non mantenere le specifiche tecniche dei loro prodotti. La verità è che entrambi i sistemi hanno un sacco di potenza per giochi e divertimento in alta definizione.

di questo articolo censuro una parte delle conslusioni perchè altamente di parte ed amio avviso fanboistica(lol ho coniato un nuovo vocabolo ) con un commento spudoratamente a vantaggio della xbox360 ^^

inoltre se avete la pazienza e la curiosità ci sono una serie di articoli abbastanza interessanti, che mostrano i pro ed i contro di entrambe le architetture:

http://www.xbox360-tribe.org/news/4...ca-per-la-velocita-massima-in-rettilineo.html


http://www.hwupgrade.it/news/videog...nzialita-hardware-di-playstation-3_17622.html


http://www.hwupgrade.it/news/skvideo/g70-alla-base-del-chip-video-playstation-3_16900.html


http://www.hwupgrade.it/articoli/vi...ystation-3-la-next-gen-e-adesso-part-1_5.html


http://www.tomshw.it/game.php?guide=20060208


detto questo mi sa che si puo chiudere il discorso, la mia oponione personale dopo aver letto centinaia di pagine di forum tech, data-sheet ecc è che la ps3 in linea teorica punta sulla simulazione di una fisica realistica impiegando la potenza del cell con i calcoli in virgola mobile, mentre la xbox 360 ha dalla sua parte una gpu secondo me piu prestante e cmq piu all'avanguardia in grado di usufruire parzialmente di effetti delle nuove directx 10 e con ha un hw sempre a mio avviso piu equilibrato, anche perchè i 3 core dello xenon a 3.2ghz fanno il loro sporco lavoro.... quando anche su ps3 vedrò un gioco con una grafica che si avvicina a quella di gears of war(non mi dite kz2 perchè secondo me è nettamente inferiore, e secondo me sta sullo stesso livello di fear non che sia brutto, ma non all'altezza, aspetto di vedere ut3 sulla ps3 ^^) vi dirò che la scelta di sony è stata azzeccata, ma per il momento sono in disaccordo con tutte le scelte di sony, con le smentite, e con le false promesse... e ci tengo a precisare per l'ennesima volta che non ce l'ho con la ps3 in quanto console e quindi mezzo d'intrattenimento, ma ce l'ho con le politiche tutt'altro che felici.