Che cosa comporta la programmazione per il processore per PC di PS3?

Question

In che modo la programmazione per l'elaboratore di celle su PS3 è diversa dalla programmazione per qualsiasi altro processore trovato su un normale desktop?

Che tipo di paradigmi di programmazione, tecniche e pratiche vengono utilizzate per sfruttare appieno il potenziale dei processori di celle?

Tutti gli articoli che ho sentito riguardo lo sviluppo di PS3 discutono di "Imparare a programmare sull'elaboratore di celle". Cosa significa veramente al di là della mano che saluta?

Answer 1

Oltre a tutto ciò che George menziona, le SPU vengono pensate molto meglio come processori vettoriali in streaming. Funzionano meglio quando si ha un algoritmo che lavora su lunghe sequenze di dati numerici, che possono essere alimentati attraverso la memoria limitata della SPU tramite DMA, piuttosto che avere la SPU caricare un blocco di memoria, provare a operare su di essa, scoprire che è necessario per seguire un puntatore da qualche parte al di fuori della sua memoria, carica che, continua, trova un altro e così via.

Quindi, programmare per loro non è un semplice modello di concorrenza e thread; è più simile al calcolo numerico o scientifico ad alte prestazioni. È anche l'accesso alla memoria non uniforme portato all'estremo.

Inoltre, ogni processore è in ordine con condutture profonde, quindi il programmatore deve essere molto più consapevole dei pericoli di dati e delle bolle di istruzioni e di tutte le numerose micro-ottimizzazioni che ci viene detto che il compilatore "dovrebbe" occuparsi di per noi (ma in realtà non lo è). Cose come dirette errate, load-hit-stores, cache cache, ecc. Fanno molto più male di quanto farebbero su un processore out-of-order che potrebbe manipolare l'ordine delle operazioni in giro per nascondere tali latenze.

Per esempi concreti, controlla il blog di Mike Acton CellPerformance. Mike è il mio assemblee della vecchia scuola preferito, un perfetto screziatore del mondo degli affari, e si è davvero guadagnato le sue costolette su questo argomento.

Answer 2

La parte cellulare di PS3 è composta da 6 processori SPU. Ognuno di essi ha 256 KB di memoria non condivisa e sono collegati tramite un anello ad alta velocità che consente il DMA tra l'altro e il processore host PowerPC. Non sono pipeline o cache. Ciò lo rende piuttosto diverso da un multi-core x86 con memoria condivisa, pipelining e caching. Inoltre, i processori SPU non usano lo stesso set di istruzioni del PowerPC, quindi hai una certa asimmetria lì.

In breve, il tipico programma multithread condiviso a memoria condivisa non si limiterà a cadere nella cella senza alcuno sforzo (con l'avvertenza che l'informatica lavora sodo per far sì che macchine diverse sembrino uguali, così alcuni implementatori si sforzano di automatizzare il processo).

Ad un livello elevato il programma dovrà essere suddiviso in attività che rientrano nel limite di memoria rigida della cella. Quelli possono essere eseguiti in parallelo e ogni sotto-attività può essere sequenziata a un processore Cell disponibile. A un livello basso, il compilatore (o il programmatore dell'assemblaggio) dovrà lavorare di più per generare codice che funzioni rapidamente su un processore - nessun trucco in fase di esecuzione per rendere le cose più veloci è disponibile. La teoria è che quelle caratteristiche del programmatore/compilatore sono costose per il silicio e la velocità che può essere spesa meglio per fornire SPU sempre più veloci. Ovviamente, non si ottengono più SPU sulla PS3, ma nel caso generale si ottengono più SPU per numero di transistor disponibili su chip.

Answer 3

Completamente d'accordo con George Philips e Crashworks. L'unica cosa che aggiungerei è che la programmazione delle SPU riguarda fondamentalmente la gestione del lavoro. Per ottenere il massimo dalle SPU è necessario tenerle sotto controllo e restituire i risultati. Non ha senso fare in modo che una SPU mastichi un po 'di complessa post-elaborazione se ti trovi a dover aspettare i risultati per un frame e il resto delle tue SPU sono inattivi.Quindi il modo in cui distribuisci i tuoi lavori richiede un sacco di riflessioni e questo ha un grande impatto sul modo in cui hai ridotto i tuoi dati.

Answer 4

"Tutti gli articoli che ho sentito riguardo allo sviluppo di PS3 discutono di" Imparare a programmare sul processore della cella ". Cosa significa questo al di là di qualche mano che saluta? "

Beh, roba che ha a che fare con lo SPU ...

• operazioni atomiche (senza blocchi try-stile di scarto).
• Forte distinzione tra aree di memoria. Devi sapere quale puntatore punta a quale area di memoria vuoi sventrare tutto.
• Nessuna distinzione hardware forzata tra dati e codice. Questa è in realtà una cosa divertente, è possibile impostare il caricamento dinamico del codice e essenzialmente eseguire lo streaming delle subroutine. Il codice auto-modificante è possibile ma non necessariamente pratico su SPU.
• Mancanza di strumenti di debug hardware.
• Dimensioni di memoria limitate.
• Accesso rapido alla memoria.
• Set di istruzioni bilanciato verso operazioni SIMD.
• Punto mobile "trucchi".

Idealmente si desidera mantenere le SPU facendo un lavoro utile tutto il tempo, ma è davvero una sfida. Non solo non sono adatti per gestire alcuni tipi di problemi, ma spesso spostare un sistema per essere efficiente su SPU può comportare una riprogettazione completa. I problemi di debugging che potrebbero essere facilmente individuati nella PPU possono talvolta richiedere giorni in SPU.

Penso che quando le persone usano la frase "imparare a programmare la cella" sono per lo più mano che saluta. Puoi imparare le basi in una settimana, la sfida arriva nel provare ad applicare quella conoscenza al codice reale ... che spesso esiste già e non è in una forma ben adatta per l'uso su SPU.