Vettori SoA su SPU

Ho letto molto sui vantaggi dell'organizzazione dei dati in "Struct of Arrays" (SoA) anziché nel tipico "Array of Structs" (AoS) per ottenere un throughput migliore quando si utilizzano le istruzioni SIMD . Mentre il "perché" ha un senso totale per me, non sono sicuro di quanto fare quando si lavora con cose come i vettori.

I vettori stessi possono essere considerati come una struttura di una matrice di dati (dimensioni fisse), quindi è possibile convertire una matrice di questi in una struttura di matrici X, Y e Z. Attraverso questo, puoi lavorare su 4 vettori contemporaneamente anziché uno alla volta.

Ora, per il motivo specifico, sto pubblicando questo su GameDev:

Ha senso lavorare con i vettori sulla SPU? Più specificamente, ha senso eseguire il DMA su più array solo per un singolo vettore? O sarebbe meglio attenersi al DMAing della matrice di vettori e srotolarli nei diversi componenti con cui lavorare?

Potrei vedere il vantaggio di eliminare lo srotolamento (se lo facessi "AoS"), ma sembra che potresti esaurire rapidamente i canali DMA se prendessi questa strada e lavorassi con più set di vettori contemporaneamente.

(Nota: nessuna esperienza professionale con Cell ancora, ma sono stato in giro in OtherOS per un po ')

Un approccio consiste nell'utilizzare un approccio AoSoA (leggi: Array of Struct of Array) che è un ibrido di AoS e SoA. L'idea è quella di archiviare N strutture di valore di dati in un blocco contiguo in forma SoA, quindi le successive N strutture in valore SoA.

Il modulo AoS per 16 vettori (etichettato 0,1,2 ... F), ruotato alla granularità di 4 strutture è:

000111222333444555666777888999AAABBBCCCDDDEEEFFF
XYZXYZXYZXYZXYZXYZXYZXYZXYZXYZXYZXYZXYZXYZXYZXYZ

per SoA, questo è:

0123456789ABCDEF
xXXXXXXXXXXXXXXX

0123456789ABCDEF
YYYYYYYYYYYYYYYY

0123456789ABCDEF
ZZZZZZZZZZZZZZZZ

per AoSoA, questo diventa:

01230123012345674567456789AB89AB89ABCDEFCDEFCDEF
XXXXYYYYZZZZXXXXYYYYZZZZXXXXYYYYZZZZXXXXYYYYZZZZ

L'approccio AoSoA ha i seguenti vantaggi di AoS:

• È necessario un solo trasferimento DMA per trasferire un blocco di strutture nella memoria locale SPU.
• le strutture hanno ancora la possibilità che tutti i dati vengano inseriti in una cache.
• Il prefetch dei blocchi è ancora molto semplice.

L'approccio AoSoA ha anche questi vantaggi del modulo SoA:

• È possibile caricare i dati dalla memoria locale SPU direttamente nei registri vettoriali a 128 bit senza scorrere i dati.
• Puoi ancora operare su 4 strutture contemporaneamente.
• Puoi utilizzare appieno la SIMD'ness del tuo processore vettoriale se non vi sono ramificazioni di base (ad es. Corsie non utilizzate nell'aritmetica vettoriale)

L'approccio AoSoA presenta ancora alcuni di questi svantaggi del modulo SoA:

• la gestione degli oggetti deve essere fatta con granularità frizzante.
• le scritture ad accesso casuale di una struttura completa ora devono toccare la memoria sparsa.
• (questi possono rivelarsi non problematici a seconda di come organizzi / gestisci le tue strutture e la loro durata)

A proposito, questi concetti di AoSoA si applicano molto bene a SSE / AVX / LRBni, nonché alle GPU che possono essere paragonate a processori SIMD molto ampi, ad es. 32/48/64 di larghezza a seconda del fornitore / architettura.

Le SPU sono in realtà un caso speciale interessante quando si tratta di vettorializzare il codice. Le istruzioni sono divise in famiglie "aritmetiche" e "carico / deposito" e le due famiglie funzionano su condotte separate. L'SPU può emettere uno di ciascun tipo per ciclo.

Il codice matematico è ovviamente fortemente vincolato dalle istruzioni matematiche, quindi di solito i loop di matematica su SPU avranno un sacco di cicli aperti sul tubo di carico / deposito. Dato che si verificano shuffle sul tubo di carico / deposito, spesso si hanno sufficienti istruzioni di carico / deposito gratuite per far girare la forma xyzxyzxyzxyz nella forma xxxxyyyyzzzz senza alcun sovraccarico.

Questa tecnica è in uso almeno su Naughty Dog - vedi le loro presentazioni di assemblaggio SPU ( parte 1 e parte 2 ) per i dettagli.

Sfortunatamente il compilatore spesso non è abbastanza intelligente da farlo automaticamente - se decidi di seguire questa strada dovrai scrivere tu stesso l'assemblaggio o srotolare i tuoi loop usando intrinseci e controllare l'assemblatore per assicurarti che sia quello che vuoi. Quindi, se stai cercando di scrivere codice multipiattaforma generale che funziona bene su SPU, potresti voler andare con SoA o AoSoA (come suggerisce jpaver.)

Come con qualsiasi ottimizzazione, profilo! La leggibilità viene prima di tutto e dovrebbe essere sacrificata solo quando la profilazione identifica un particolare collo di bottiglia e hai esaurito tutte le opzioni per ottimizzare l'algoritmo di alto livello (il modo più veloce per fare il lavoro è non dover fare il lavoro!) Dovresti sempre riprofilare seguendo qualsiasi ottimizzazione di basso livello per confermare che hai davvero reso le cose più veloci piuttosto che il contrario, specialmente con condutture bizzarre come quelle di Cell.

Quali tecniche userete allora dipenderanno dai dettagli del collo di bottiglia. In generale, quando si lavora con tipi di vettore, un componente vettoriale che si ignora in un risultato rappresenta spreco di lavoro. Cambiare SoA / AoS non ha senso a meno che non ti consenta di fare un lavoro più utile riempiendo tali componenti inutilizzati (ad esempio un prodotto a punti sulla PPU della PS3 contro quattro prodotti a punti in parallelo nello stesso periodo di tempo). Per rispondere alla tua domanda, passare il tempo a mescolare i componenti solo per eseguire un'operazione su un singolo vettore mi sembra una pessimizzazione!

Il rovescio della medaglia sulle SPU è che la maggior parte del costo dei piccoli trasferimenti DMA è in fase di configurazione; qualsiasi cosa inferiore a 128 byte richiederà lo stesso numero di cicli per il trasferimento e qualsiasi cosa inferiore a un kilobyte solo pochi cicli in più. Quindi non preoccuparti di DMAing di più dati di quelli strettamente necessari; ridurre il numero di trasferimenti DMA sequenziali attivati ​​e svolgere attività mentre si stanno verificando trasferimenti DMA - e quindi sviluppare prologhi ed epiloghi di loop per formare pipeline di software - è la chiave per buone prestazioni SPU ed è più facile gestire casi angolari recuperando dati extra / scartando i risultati parzialmente calcolati che saltare attraverso i cerchi per cercare di organizzare l'esatta quantità di dati necessari per essere letti ed elaborati.

No, non avrebbe molto senso in generale poiché la maggior parte dei codici operativi vettoriali operano su un vettore nel suo insieme e non su componenti separati. Quindi puoi già moltiplicare un vettore in 1 istruzione, mentre con la suddivisione dei componenti separati passeresti 4 istruzioni su di esso. Quindi, dal momento che praticamente fai molte operazioni in generale su una struttura, è meglio imballarle in un array, ma non fai quasi mai cose solo su un componente di un vettore, o selvaggiamente diverso su ciascun componente, quindi spezzandole fuori non avrebbe funzionato.
Naturalmente, se trovi una situazione in cui devi fare qualcosa solo per i componenti (diciamo) x dei vettori, potrebbe funzionare, tuttavia la pena di far tornare indietro tutto quando hai bisogno del vettore reale non sarebbe economica, quindi potresti mi chiedo se non dovresti usare i vettori per cominciare, ma solo una serie di float che accadono per consentire ai codici operativi vettoriali di fare i loro calcoli specifici.