Quote:
Originariamente inviato da carlottoIIx6
per me hsa è un mix tra hardware dedicato e no.
ovvero, è vero che il dedicato va veloce, ma fa solo una cosa.
che succede se metto più cose non dedicate a fare una cosa sola?
che una parte di queste più cose si avvicina megli a quello che sarebbe l'hardware dedicato, pur rimandendo programmabile.
morale: hsa permette di mantenere la programmabilità e grazie all'adattabilità si avvicina al dedicato senza mai raggiungerlo (ovviamente).
|
Sì certo , ma tutto dipende da quello che è la tua prospettiva.
L'HW ad hoc fa una cosa sola ma è piccolo. Quindi in teoria puoi avere più unità per calcoli ad hoc che in totale rimangono sempre più piccoli di una GPU da mille e rotti ALU con tutto il nesso e connesso.
Poi l'HW ad hoc può essere anche 100 volte più efficiente del miglior algoritmo scritto per GPU.
Quindi se il tuo scopo è avere 4 algoritmi in croce accelerabili in maniera proficua con una architettura programmabile allora la GPU ha il suo perché. Se vuoi realizzare la vera efficienza, il GPGPU (o l'HSA che propone AMD che è la stessa cosa) non basta.
Chiediti perché sia AMD che nvidia mettono un decoder a funzione fissa nelle proprie GPU anche se queste in realtà potrebbero benissimo macinare così tanti calcoli a decomprimere al volo qualsiasi cosa senza l'ausilio di nessun HW ad hoc. Forse per riuscire a consumare 12W (ovvero 10 di idle + 2 del decoder a funzione fissa) invece dei 200W se faccero fare tutto alle ALU general purpose?
Quindi HSA significa dotare la macchina dei migliori strumenti HW per fare un determinato compito. Che comprende anche avere una CPU ridicola in termini di pura capacità di calcolo ma avere a disposizione coprocessori potentissimi in grado di sopperire là dove serve (sentito parlare del Cell? Quello è HSA vero, 8 anni prima che AMD inventasse la fuffaword HSA. E il Cell ha unità general purpose, non a funzione fissa).
Ritenere che le ALU della GPU, per quante siano siano e quanto potenti possano sembrare sia la panacea di tutti gli algoritmi è fare lo stesso identico errore che è stato fatto 30 anni fa quando Intel ha fatto credere che un core monolitico di dimensioni extra e velocità pazzesche sarebbe stato in grado di fare tutto al meglio. O quello che ancora viene marketizzato come il metodo di aumentare la potenza di calcolo a costo zero: i multicore.
In verità il modello assoluto di massima efficienza è quello che vuole unità di calcolo specifiche per specifici tipi di calcolo. Più complessi di una CPU che invia un flusso di istruzioni ad una o più ALU, ma al contempo più semplici perché non necessitano dell'overhead che le CPU normali si portano dietro (fetcher, decoder, esecuzioni tutto come in una catena di montaggio).
La massima summa è una CPU per il calcolo GP di tipo seriale affiancata ad una FPGA o similia per eseguire un algoritmo non maniera puramente sequenziale come lo svolgerebbe al CPU anche quando quello non è il metodo più efficiente. Il vantaggio dell'FPGA è che una volta che l'unità di calcolo non serve più la si cancella e se ne crea un'altra diversa più efficiente per il calcolo successivo.
Siccome è evidente che non è così facile la cosa né tecnicamente né economicamente, si scende di uno scalino di mettere quante più unità a funzione fissa per i più disparati calcoli si possa pensare. Siccome ancora non è possibile usare centinaia di mm^2 di silicio per unità che non servono quasi mai (se non davvero mai), si scende ancora un gradino e si mettono le unità di calcolo che sono in grado di accelerare gli algoritmi più comuni. Questo è l'HSA (o come si è sempre chiamato, architettura ibrida). Il livello di AMD è ancora un gradino (o anche due) più in basso perché dice che invece di usare unità ottimizzate per un determinato calcolo (che è lo scopo di avere unità di calcolo diverse da quelle general purpose della CPU) bisogna usare un nugolo di unità di calcolo diversamente ottimizzate ma sempre general purpose che talvolta superano in efficienza quelle della CPU ma per la maggior parte delle volte non lo sono.
Io, sinceramente non lo vedo un gran passo in avanti, almeno fino a che le unità di calcolo general purpose delle GPU non smetteranno di avere tutte le limitazioni che hanno oggi, tipo avere difficoltà con i salti condizionati o essere in grado di eseguire uno stream di istruzioni in maniera isolata invece di andare di brute force in esecuzione su centinaia o migliaia di unità che devono eseguire necessariamente lo stesso insieme di istruzioni.
Detto tra noi, le SPU del Cell che hanno 8 anni sono più avanti di quanto non lo siano le ALU delle GPU odierne. ALU che sono semplici e fantasticamente super ideali per il calcolo grafico, ma completamente inadatte per quello GP, in cui come detto compensa la questione brute force se ci sono abbastanza dati su cui operare in parallelo (che nasconde l'estrema inefficienza delle singole ALU).
Più si aumenta la capacità di fare GPGPU, minore è l'efficienza in campo prettamente grafico, come ha ben dimostrato nvidia dal G200 in poi e anche AMD con l'arrivo di GCN.
Forse, nella mia ignoranza, trovo l'approccio più corretto quello alla Cell, dove di fianco alle migliaia di semplici ALU che fanno grafica (e che lascerei semplicissime per occupare meno silicio possibile) si affiancano delle unità più general purpose (come gli SPU o meglio core ARM visto che oggi la loro dimensione non pone problemi con la nanometria a disposizione) per gestire i flussi di codice più complesso (nel flow chart) e meno parallelizzabile (che sono la stra grande maggioranza degli algoritmi pensabili dall'uomo). Certo, si usa più silicio in assoluto, ma si migliora notevolmente l'efficienza del codice eseguito (a discapito del rapporto superficie/calcoli grafici realizzati).
Ripeto, così come AMD propone il suo HSA non si va da nessuna parte nel mondo reale (ma solo in quello dei benchmark o nelle 2 o 3 applicazioni di nicchia che sole si adattano all'uso dei core grafici per come sono pensati oggi).