Muttley
06/12/2006, 09:52
Mai come in questa generazione di console, la lotta tra le due fazioni (Sony e Microsoft) è stata così agguerrita. Sia da una parte che dall’altra abbiamo assistito ad una campagna pubblicitaria atta a promuovere la propria console next-gen e a distruggere l’immagine dell’altra demistificandone pregi e funzionalità. Senza dubbio uno degli argomenti più utilizzati per far leva sulle coscienze dei videogiocatori è stata la presunta superiorità di una dotazione hardware rispetto all’altra. In particolar modo le due console Xbox 360 e Ps3 sono state sommariamente confrontate sulla base della potenza dei rispettivi processori, intesa come frequenza di clock. Abitudine malsana e sbagliata ma che ahimè trova nell’ignoranza di parecchi utenti terreno fertile per diffondersi e mietere vittime.
In ambito PC per anni abbiamo assisitito allo scontro, commercialmente parlando, tra Intel e AMD dove i processori della casa di Cupertino venivano preferiti dalla cieca massa a quelli della rivale di Sunnyvale per una semplice questione di clock. AMD tuttavia ha dimostrato nel corso della storia recente che l’architettura di un processore e l’ottimizzazione dell’ instruction sets hanno voce in capitolo tanto quanto la frequenza di funzionamento ai fini della potenza di calcolo.
In tal proposito vi sottoponiamo la traduzione in italiano di un articolo scritto da mterzich, utente del forum AVS:
Proverò ad essere imparziale. Non sono un videogiocatore e non ho interesse di alcun tipo nell’acquistare una console, ma in quanto programmatore sia PS3 sia Xbox 360 mi intrigano.
Quando all’inizio ho dato una prima lettura alle specifiche del processore Cell di PS3 e a quelle di Xenos di Xbox 360 mi è sembrato che il primo avesse un grosso vantaggio sul secondo considerando la possibilità di raggiungere la massima potenza erogabile. Tuttavia dopo un’analisi più approfondita sono giunto alla conclusione opposta, ovvero che il processore Xenos è in grado di esprimersi meglio del Cell in quasi tutte le situazioni.
Entrambi processori derivano dall’IBM 970 PowerPC, ma ciascun core di Cell e Xenos ha una velocità di esecuzione che si attesta attorno alla metà della velocità di esecuzione di un IBM 970 a parità di frequenza di clock. Ciò è dovuto al fatto che mentre l’IBM 970 ha più unità di esecuzione che hanno la possibilità di lavorare in OOO Out-Of-Order (ovvero in parallelo), Cell e Xenos hanno una sola unità di esecuzione che processa i dati in modo sequenziale.
A testimonianza di quanto detto visitate il link seguente, dove viene riportata l’analisi prestazionale di una PS3 a 3.2 GHz e di un Power Mac G5 a 1.6 GHz sotto ambiente Linux:
http://www.geekpatrol.ca/2006/11/pla...3-performance/
Linux utilizza il core PPE (Power Processing Element) del Cell quindi i risultati dovrebbero essere simili a quelli ottenibili con uno dei tre core PPE dello Xenos visto che entrambe le CPU sono bloccate a 3.2 GHz.
Le somiglianze dei due processori finiscono però qui, visto che Xenos è dotato di 3 core PPE identici mentre Cell si avvale di un solo core PPE e di ben 7 core SPE
Programmare su piattaforma Xbox 360
Il sistema operativo non utilizza il core ‘0’, ma usa circa il 3% della potenza del core ‘1’ e il 3% del core ‘2’, quindi il 98% della potenza dei tre core rimane libera e utilizzabile dalle applicazioni videoludiche. Programmare per 360 è abbastanza semplice e diretto grazie alla quantità di memoria principale condivisa, alla dimensione della cache L2 e al fatto che le informazioni passano molto facilmente e velocemente attraverso i differenti threads dell’applicazione con l’uso dei puntatori.
Tipicamente un’applicazione viene inizialmente sviluppata utilizzando un solo thread di un core, poi, una volta sviluppata l’appz, il tutto viene segmentato per utilizzare più core e possibilmente anche più threads hardware per ogni core. Il modo più semplice per operare questa segmentazione è quello di assegnare il codice di controllo del gioco e l’AI ad un core e il codce di rendering grafico ad un altro core. Non appena il codice dell’AI è stato eseguito vengono inviate al core di rendering grafico e informazioni per processare il frame successivo. Quindi il codice di rendering grafico eseguito sul secondo core va a creare il frame corrente mentre simultaneamente l’AI esegue il codice necessario al frame successivo.
Segmentare il codice ulteriormente comincia ad essere molto più difficile. Lo sviluppatore deve anzitutto determinare dove potrebbero formarsi dei colli di bottiglia. Se questi si verificano all’interno del codice AI, dovrà accertarsi che possa essere attuata una processazione parallela (per esempio in un gioco racing, potrebbe essere possibile che il programma principale processi l’AI di 5 auto e un altro core processi l’AI di altre 5 auto sula tracciato contemporaneamnte). Se il collo di bottiglia si verifica invece nel codice della grafica, allora è possibile assegnare parte del codice di rendering in parallelo ad un altro core.
Quando un programma è suddiviso su tre core, uno dei core è attivo per il 100% del tempo mentre gli altri due possono risultare attivi per poco tempo (10%, 20%, 50%, etc.). In tal caso è richiesta maggior segmentazione sul core occupato al 100%, quindi può essere aggiunto un nuovo thread hardware a uno dei core meno attivi per gestire 2 processi allo stesso tempo. Una volta saturati tutti i threads hardware disponibili, se è necessaria una ulteriore segmentazione, possono essere istanziati dei threads software (che sono comunque meno efficienti di quelli hardware) fino a che anche quel core non raggiunge il 100% dell’occupazione.
Una volta che tutti e 3 i core hanno un’utilizo prossimo al 100% saranno stati raggiunti il massimo frame rate, la massima sofisticatezza e dettaglio grafico. Se l’AI propone frames più velocemente di quanto la GPU non possa processarne (massimo 60 fps a 720p o 30 fps a 1080i), possono essere aggiunti ulteriori dettagli.
Programmare su piattaforma PS3
Programmare per PS3 è molto più difficile di quanto non lo sia su Xbox 360. In un certo senso PS3 è stata progettata in modo simile ai sistemi multi processore utilizzati in ambiti specifici, per esempio al NASA Ames Research Center. Il concetto si basa sul principio che vede un enorme quantità di dati matematici che si ripetono e che possono essere processati in parallelo o sequenzialmente ma spezzettati (per esempio un core moltiplica due array di 10000 numeri e poi passa l’array risultante a un altro core che opera divisioni sui singoli elementi dell’array e ne passa il risultato a un altro core che provvederà ad atre operazioni sui dati e così via; dopo che il primo core ha terminato l’operazione, acquisisce nuovi dati e prosegue su questi con la stessa operazione.
Così come avviene per Xbox 360, anche qui l’applicazione viene inizialmente sviluppata utilizzando il core PPE. A questo punto sarebbe lecito pensare che la PS3 (come la 360) sia in grado di segmentare il codice assegnando a un core il codice di controllo dell’AI e ad un altro il codice di rendering grafico. Questo non è possibile! Dal momento che il codice vero e proprio di un’applicazione si attesta sui 100 MB e che la memoria di ciascun SPE è di soli 256KB solo 1/400 del codice totale può essere depositato nella memoria di uno SPE. Inoltre poiché in uno SPE non c’è capacità di branch prediction (Predizi...le diramazioni - Wikipedia (http://it.wikipedia.org/wiki/Predizi...le_diramazioni)) , le diramazioni andrebbero fatte il più piccole possibili. Pertanto il programmatore deve trovare codice che sia inferiore ai 256KB (incluso lo spazio necessario per i dati) prchè questo possa essere eseguito in parallelo.
Se assumiamo che lo sviluppatore sia in grado di individuare sufficienti segmenti di codice tali per cui tutti e 6 i core SPE vengano utilizzati, adesso dovrà prodigarsi per bilanciare il carico di lavoro tra i cores. Come con Xbox 360, non è detto che i core siano sempre occupati ma è possibile che alcuni o tutti vengano utilizzati solo in minima parte. Aggiungere nuovi thread hardware non è possibile dal momento che ciascun core dispone di un solo thread hardware e agiungere threads software sarebbe probabilmente controproducente vista la memoria limitata. A questo punto l’unica opzione possibile è quella di uno schema che vede il core PPE trasferire nuovo codice agli SPE attraverso DMA, una volta terminate le operazioni sulla tranche di dati precedenti. Questa è ovviamente una procedura che richiede parecchio tempo.
Conclusioni
Ho seri dubbi sul fatto che molti sviluppatori programmeranno sui core SPEs della PS3: la complessità è enorme, i tempi di sviluppo sono molto lunghi e c’è un’elevata probabilità di sviluppare software buggato. Sospetto che Gears of War stia già sfruttando le potenzialità del sistema multiprocessore ma che stia solo usando il 50% della potenza realmente disponibile. Alla luce di ciò e di quanto detto sopra mi riesce difficile immaginare che un gioco PS3 possa risultare migliore di uno per Xbox 360.
Anche in questo caso, non abbiamo affatto certezza che si tratti di una testimonianza super partes. Possiamo però constatare che chi ha scritto questo articolo è comunque persona competente in materia e che ha portato a sostegno della propria tesi dati tecnici documentati. Il tempo darà ragione a Sony o a Microsoft.
In ambito PC per anni abbiamo assisitito allo scontro, commercialmente parlando, tra Intel e AMD dove i processori della casa di Cupertino venivano preferiti dalla cieca massa a quelli della rivale di Sunnyvale per una semplice questione di clock. AMD tuttavia ha dimostrato nel corso della storia recente che l’architettura di un processore e l’ottimizzazione dell’ instruction sets hanno voce in capitolo tanto quanto la frequenza di funzionamento ai fini della potenza di calcolo.
In tal proposito vi sottoponiamo la traduzione in italiano di un articolo scritto da mterzich, utente del forum AVS:
Proverò ad essere imparziale. Non sono un videogiocatore e non ho interesse di alcun tipo nell’acquistare una console, ma in quanto programmatore sia PS3 sia Xbox 360 mi intrigano.
Quando all’inizio ho dato una prima lettura alle specifiche del processore Cell di PS3 e a quelle di Xenos di Xbox 360 mi è sembrato che il primo avesse un grosso vantaggio sul secondo considerando la possibilità di raggiungere la massima potenza erogabile. Tuttavia dopo un’analisi più approfondita sono giunto alla conclusione opposta, ovvero che il processore Xenos è in grado di esprimersi meglio del Cell in quasi tutte le situazioni.
Entrambi processori derivano dall’IBM 970 PowerPC, ma ciascun core di Cell e Xenos ha una velocità di esecuzione che si attesta attorno alla metà della velocità di esecuzione di un IBM 970 a parità di frequenza di clock. Ciò è dovuto al fatto che mentre l’IBM 970 ha più unità di esecuzione che hanno la possibilità di lavorare in OOO Out-Of-Order (ovvero in parallelo), Cell e Xenos hanno una sola unità di esecuzione che processa i dati in modo sequenziale.
A testimonianza di quanto detto visitate il link seguente, dove viene riportata l’analisi prestazionale di una PS3 a 3.2 GHz e di un Power Mac G5 a 1.6 GHz sotto ambiente Linux:
http://www.geekpatrol.ca/2006/11/pla...3-performance/
Linux utilizza il core PPE (Power Processing Element) del Cell quindi i risultati dovrebbero essere simili a quelli ottenibili con uno dei tre core PPE dello Xenos visto che entrambe le CPU sono bloccate a 3.2 GHz.
Le somiglianze dei due processori finiscono però qui, visto che Xenos è dotato di 3 core PPE identici mentre Cell si avvale di un solo core PPE e di ben 7 core SPE
Programmare su piattaforma Xbox 360
Il sistema operativo non utilizza il core ‘0’, ma usa circa il 3% della potenza del core ‘1’ e il 3% del core ‘2’, quindi il 98% della potenza dei tre core rimane libera e utilizzabile dalle applicazioni videoludiche. Programmare per 360 è abbastanza semplice e diretto grazie alla quantità di memoria principale condivisa, alla dimensione della cache L2 e al fatto che le informazioni passano molto facilmente e velocemente attraverso i differenti threads dell’applicazione con l’uso dei puntatori.
Tipicamente un’applicazione viene inizialmente sviluppata utilizzando un solo thread di un core, poi, una volta sviluppata l’appz, il tutto viene segmentato per utilizzare più core e possibilmente anche più threads hardware per ogni core. Il modo più semplice per operare questa segmentazione è quello di assegnare il codice di controllo del gioco e l’AI ad un core e il codce di rendering grafico ad un altro core. Non appena il codice dell’AI è stato eseguito vengono inviate al core di rendering grafico e informazioni per processare il frame successivo. Quindi il codice di rendering grafico eseguito sul secondo core va a creare il frame corrente mentre simultaneamente l’AI esegue il codice necessario al frame successivo.
Segmentare il codice ulteriormente comincia ad essere molto più difficile. Lo sviluppatore deve anzitutto determinare dove potrebbero formarsi dei colli di bottiglia. Se questi si verificano all’interno del codice AI, dovrà accertarsi che possa essere attuata una processazione parallela (per esempio in un gioco racing, potrebbe essere possibile che il programma principale processi l’AI di 5 auto e un altro core processi l’AI di altre 5 auto sula tracciato contemporaneamnte). Se il collo di bottiglia si verifica invece nel codice della grafica, allora è possibile assegnare parte del codice di rendering in parallelo ad un altro core.
Quando un programma è suddiviso su tre core, uno dei core è attivo per il 100% del tempo mentre gli altri due possono risultare attivi per poco tempo (10%, 20%, 50%, etc.). In tal caso è richiesta maggior segmentazione sul core occupato al 100%, quindi può essere aggiunto un nuovo thread hardware a uno dei core meno attivi per gestire 2 processi allo stesso tempo. Una volta saturati tutti i threads hardware disponibili, se è necessaria una ulteriore segmentazione, possono essere istanziati dei threads software (che sono comunque meno efficienti di quelli hardware) fino a che anche quel core non raggiunge il 100% dell’occupazione.
Una volta che tutti e 3 i core hanno un’utilizo prossimo al 100% saranno stati raggiunti il massimo frame rate, la massima sofisticatezza e dettaglio grafico. Se l’AI propone frames più velocemente di quanto la GPU non possa processarne (massimo 60 fps a 720p o 30 fps a 1080i), possono essere aggiunti ulteriori dettagli.
Programmare su piattaforma PS3
Programmare per PS3 è molto più difficile di quanto non lo sia su Xbox 360. In un certo senso PS3 è stata progettata in modo simile ai sistemi multi processore utilizzati in ambiti specifici, per esempio al NASA Ames Research Center. Il concetto si basa sul principio che vede un enorme quantità di dati matematici che si ripetono e che possono essere processati in parallelo o sequenzialmente ma spezzettati (per esempio un core moltiplica due array di 10000 numeri e poi passa l’array risultante a un altro core che opera divisioni sui singoli elementi dell’array e ne passa il risultato a un altro core che provvederà ad atre operazioni sui dati e così via; dopo che il primo core ha terminato l’operazione, acquisisce nuovi dati e prosegue su questi con la stessa operazione.
Così come avviene per Xbox 360, anche qui l’applicazione viene inizialmente sviluppata utilizzando il core PPE. A questo punto sarebbe lecito pensare che la PS3 (come la 360) sia in grado di segmentare il codice assegnando a un core il codice di controllo dell’AI e ad un altro il codice di rendering grafico. Questo non è possibile! Dal momento che il codice vero e proprio di un’applicazione si attesta sui 100 MB e che la memoria di ciascun SPE è di soli 256KB solo 1/400 del codice totale può essere depositato nella memoria di uno SPE. Inoltre poiché in uno SPE non c’è capacità di branch prediction (Predizi...le diramazioni - Wikipedia (http://it.wikipedia.org/wiki/Predizi...le_diramazioni)) , le diramazioni andrebbero fatte il più piccole possibili. Pertanto il programmatore deve trovare codice che sia inferiore ai 256KB (incluso lo spazio necessario per i dati) prchè questo possa essere eseguito in parallelo.
Se assumiamo che lo sviluppatore sia in grado di individuare sufficienti segmenti di codice tali per cui tutti e 6 i core SPE vengano utilizzati, adesso dovrà prodigarsi per bilanciare il carico di lavoro tra i cores. Come con Xbox 360, non è detto che i core siano sempre occupati ma è possibile che alcuni o tutti vengano utilizzati solo in minima parte. Aggiungere nuovi thread hardware non è possibile dal momento che ciascun core dispone di un solo thread hardware e agiungere threads software sarebbe probabilmente controproducente vista la memoria limitata. A questo punto l’unica opzione possibile è quella di uno schema che vede il core PPE trasferire nuovo codice agli SPE attraverso DMA, una volta terminate le operazioni sulla tranche di dati precedenti. Questa è ovviamente una procedura che richiede parecchio tempo.
Conclusioni
Ho seri dubbi sul fatto che molti sviluppatori programmeranno sui core SPEs della PS3: la complessità è enorme, i tempi di sviluppo sono molto lunghi e c’è un’elevata probabilità di sviluppare software buggato. Sospetto che Gears of War stia già sfruttando le potenzialità del sistema multiprocessore ma che stia solo usando il 50% della potenza realmente disponibile. Alla luce di ciò e di quanto detto sopra mi riesce difficile immaginare che un gioco PS3 possa risultare migliore di uno per Xbox 360.
Anche in questo caso, non abbiamo affatto certezza che si tratti di una testimonianza super partes. Possiamo però constatare che chi ha scritto questo articolo è comunque persona competente in materia e che ha portato a sostegno della propria tesi dati tecnici documentati. Il tempo darà ragione a Sony o a Microsoft.