A causa di alcuni importanti eventi accaduti nel corso della settimana, ho deciso di rinviare la conclusione della serie dedicata alle operazioni di texturing ad un prossimo articolo, per occuparmi, oggi, di un paio di eventi piuttosto rilevanti nel panorama informatico in generale e che riguardano, da vicino, il mondo delle gpu.
I due argomenti trattati sono arguibili dal titolo che contiene i nomi dei due chip protagonisti del post odierno. L’intenzione non è quella di scrivere un articolo di stampo tecnico, con un confronto tra le specifiche di una gpu ancora lontana dal debutto e una il cui debutto pare essere stato rinviato a data da destinarsi (Blizzard direbbe:”uscirà quando sarà pronto”). Si tratta, piuttosto, di un post in cui alternerò dati oggettivi a riflessioni personali, scrivendo le seconde in corsivo per distinguerle dai primi.
In questi mesi, sia su Larrabee che su Fermi, sono circolate tantissime voci, a volte contrastanti, sulle presunte specifiche e sulle date di presentazione e di lancio. Oggi abbiamo la certezza che Intel ha annullato l’uscita della prima serie di GPU basate su architettura di tipo terascale computing denominata Larrabee mentre nVidia ha rinviato definitivamente la presentazione dei chip basati su G100 all’anno venturo.
L’annuncio di Intel di voler rientrare nel mercato delle GPU discrete, dopo la non brillante esperienza nota col nome di i740, successiva all’acquisizione di Real3D, diede origine a molte aspettative dettate dalla curiosità di vedere come gli ingegneri dell colosso di Santa Clara avrebbero affrontato le difficoltà legate alla progettazione di un chip con architetture tanto diverse rispetto a quelle ben note, per loro, caratteristiche di una cpu.
La curiosità, fu soddisfatta, in parte, nel momento in cui Intel annunciò di voler progettare una GPU prendendo come base la ben nota architettura x86. Soddisfatta in parte, perchè quell’annuncio destò più di qualche perplessità legata soprattutto ai dubbi sul come Intel avrebbe adattato un modello che non brilla per efficienza, come quello x86 (pur con i successivi aggiustamenti), ad un paradigma architetturale come quello di una GPU. I dubbi crebbero all’annuncio che Larrabee non avrebbe implementato pipeline di tipo fixed function (ff) ma solo unità di tipo programmabile.
Questo perchè, come noto, le unità programmabili hanno il loro punto di forza nella flessibilità di adattamento, nella possibilità di svolgere tanti tipi di operazioni differenti, permettendo di concentrare la maggior potenza di calcolo, istante per istante, dove la stessa è necessaria. Ma certamente non sono veloci nell’eseguire uno specifico task rispetto ad unità di tipo ff dedicate a quel compito specifico.
Apro una brevissima parentesi per chiarire alcuni concetti: una cpu è strutturate per eseguire tante istruzioni con output di dati piuttosto basso mentre, al contrario, di una gpu si diceva che è un dispositivo capace di eseguire poche istruzioni ma di avere un data output molto elevato. Il modello SIMD è stato scelto proprio perché ad una gpu si chiede, essenzialmente, di fare tanti calcoli dello stesso tipo.
Con gli shader unificati qualcosa è, in parte, cambiata, ma solo in virtù del fatto che l’architettura interna è stata riordinata perchè si adattasse a questo nuovo modello. In questo modo, quelle che una volta erano note come unità di pixel e vertex shading sono state sostituite da un’unica unità programmabile in grado di eseguire sia operazioni geometriche che di pixel shading e queste unità sono state raggruppate in cluster e il numero di questi cluster, in breve tempo, è cresciuto notevolmente.
Ciò permette, oggi, di avere GPU in grado di esegiure molte più istruzioni di tipo differente all’interno dello stesso ciclo, che girano su differenti gruppi di alu. Inoltre è aumentato anche il numero di thread che ogni alu può gestire. Insomma, le gpu stanno evolvendo verso un modello che tende ad inglobare molte delle funzionalità tipiche delle cpu, pur continuando ad esistere, al momento, una linea di demarcazione piuttosto netta tra le due tipologie di architettura.
Mentre nel progettare una cpu si ha come obiettivo quello di minimizzare il più possibile le latenze della singola operazione, nel progettare una gpu si ha, di contro, la cerrtezza di avere a che fare con operazioni ad elevata latenza e, di conseguenza, si deve cercare di massimizzare il parallelismo interno. Questo significa che una gpu è concepita per avere una banda passante enorme verso le http://www.appuntidigitali.it/3887/grafica-una-questione-di-memoria/ e verso la vram, al fine di mascherare le latenze, inevitabili, di determinate operazioni (ad esempio quelle di texturing).
Se queste considerazioni non dovessero essere sufficienti a generare dubbi sulla possibilità di realizzare una gpu partendo dall’architettura di una cpu x86, ne aggiungo altre. Come detto, Intel ha affermato di non voler implementare unità di tipo ff all’interno di Larrabee,
posizione su cui ha, in un secondo momento, fatto parzialmente marcia indietro, dicendo che unità di tipo ff ci sarebbero state all’interno delle TMU, in quanto per le operazioni di texture sampling e texture fetching le unità programmabili impiegavano 16 cicli contro il singolo ciclo di un’unità dedicata. Anche nell’era della programmabilità, una gpu contiene, al suo interno, diversi stadi composti da unità di tipo ff alternati a stadi di unità programmabili, come mostrato in figura
questo perchè per determinate operazioni (oltre a quele relative alle texture, mi viene in mente, ad esempio la tessellation introdotta ufficialmente con le DX11, ma anche l’applicazione del MSAA box) le unità dedicate sono molto più veloci di quelle programmabili. Inoltre, le operazioni di shading presentano accessi alla memoria a granularità molto fino che possono essere gestiti solo in moaniera dinamica. Questo rende impossibile, ad esempio, la presenza di unità di prefetching all’interno degli stadi programmabili e la necessità di implementare le stesse entro le pipeline fixed function.
Una ulteriore fonte di dubbi riguarda l’adozione dell’architettura interna con ring bus; questo tipo di archietttura è di difficile ottimizzazione quando gli “utilizzatori” sono più di 4: il cell in cui bisogna fare molta attenzione alle modalità di trasferimento dati da una SPE all’altra per evitare di veder crollare le prestazioni a causa della cattiva gestione del traffico nel ring bus e l’esperienza di R600, in cui si è commesso l’errore di non dedicare un canale a parte alle operazioni non attinenti alla grafica, sono due esempi dei limiti intrinseci di un’architettura come quella ad anello. Intel ha pensato di risolvere il problema adottando la soluzione prospettata in figura
ovvero utilizando più ring bus, ciascuno dei quali serve un numero limitato di unità. Soluzione interessante che permette di superare i limiti del ring bus in “locale” ma che sposta il problema di come gestire le comunicazione attraverso un bus a come gestire le comunicazioni, qualora si rendesse necessario, tra più anelli.
Non mi dilungherò su aspetti inerenti l’architettura di Larrabee, poichè, come detto, questo è un post in cui mi sono ripromesso di partire da alcuni dati per fare delle consoderazioni personali sia sulla decisione di Intel di annullare la prima serie di gpu basate su questa architettura, sia sul ritardo, ormai ufficializzato, delle soluizoni basate su G100 di nVidia. Quindi i riferimenti fatti all’architettura di Larrabee sono funzionali non a farne un’analisi ma a specificare i motivi di perplessità su questo chip.
A tutto ciò, si aggiunge che, secondo le intenzioni di Intel, ogni core di Larrabee dovrebbe essere in grado, per ogni ciclo di clock, di eseguire due istruzioni e gestire fino a 4 thread in modalità in order. Ora, sappiamo che le attuali gpu sono in grado di gestire centinaia di thread per core, al fine di mascherare le latenze. Per quanto Larrabee possa essere ottimizzato per ridurre al minimo le latenze, nell’ambito delle elaborazioni tipiche di una gpu ci sono operazioni che, per forza di cose, presentano latenze elevate. Insomma, Larrabee non appare molto in grado di mascherare le latenze facendo ricorso al multithreading. Quindi deve essere strutturato in maniera tale da non avere operazioni che comportino latenze elevate (impresa difficile per una GPU).
Ultima fonte di dubbi era quella relativa al processo produttivo adottao; si è parlato di 45 nm mentre sappiamo che ATi è già passata ai 40 e nVidia lo ha fatto almeno con le gpu di fascia bassa. Questo, sommato alla voce che avrebbe voluto all’interno di Larrabee, almeno 16 o 32 core, avrebbero determinato un die di dimensioni enormi sia rispetto alla concorrenza che in assoluto.
Ciò nonostante, eravamo (e siamo ancora) in molti a pensare che Intel possa riuscire nell’impresa di realizzare una GPU competitiva nelle fasce media e alta del mercato, prima o poi. Certo, l’annuncio del mancato lancio di questa prima serie fa slittare l’ingresso questo ingresso, annunciato forse con un po’ troppo clamore, e rischia di dirottare, momentaneamente, questa archietttura, verso altri tipi di impiego in cui potrebbe, grazie alle 16 unità vettoriali per core, eccellere e mi riferisco, in particolare, al GPGPU. In questo campo, potrebbe entrare in diretta competizione con Fermi.
Già, Fermi………………….. Della nuova architettura di nVidia si sà, praticamente, quasi tutto; peccato che tra le poche cose ancora non rivelate ci siano quelle che sono di maggior interesse per le applicazioni 3D come, ad esmepio, la presenza di unità dedicate all’e operazioni di tessellation o le frequenze di funzionamento delle Geforce basate su G100.
La motivazione ufficiale è stata che, finora, è stata presentata solo la versione Tesla, dedicata al GPU compunting. C’è altresì da aggiungere che, per quanto visto finora, l’archietttura denominata Fermi pare molto orientata al GPU computing. L’adozione di pipeline di tipo FMA (le alu di G80 e quelle di tipo single precision di GT200 sono delle MADD), l’implementazione, per la prima volta su chip grafici nVidia, di cache vere e proprie (quelle presenti nei chip, fino a GT200 erano delle texture cache, mentre AMD è da RV770 che fa uso di cache di secondo livello di tipo cpu-like)
La cache L2 serve, tra le altre cose, per accelerare le atomic operation permettendo lo scambio di dati tra cluster on chip, mentre in precedenza, l’unico spazio di memoria visibile ed accessibile a tutti, era la global memory all’interno della vram. Un altro aspetto che fa somigliare Fermi molto più ad una cpu rispetto alle rpecedenti architetture nVidia è l’esecuzione condizionale delle istruzioni, gestita con un approccio che ricorda quello adottato sulle CPU ARM (per l’approfondimento delle quali rimando agli ottimi articoli di Cesare Di Mauro), per ridurre il rischio di stallo dovuto a predicazione sbagliata. Questo senza tener conto della miglior attitudine al thread switching ottenuta grazie all’adozione del DUAL WARP SCHEDULER
e delle due instruction dispatch unit che, raddoppiando di fatto, le medesime unità per cluster presenti su GT200, permette di operare su due thread in parallelo, uno per ogni gruppo di 16 alu, riducendo di un fattore di 10x la velocità di commutazione tra thread e la granularità degli stessi rispetto a GT200.
Fermi, contrariamente a GT200, ha anche una elevata capacità di calcolo in doppia precisione, ottenuta accoppiando due alu a 32 bit. Nettamente differente, rispetto al passato, anche l’organizzazione delle alu di Fermi
messe a confronto con quelle di GT200
Come si vede, la zeconda appare “incompleta”, mancando, come si è detto, di una cache interna in cui immazzinare i dati comuni; in Fermi, al contrario, c’è una cache di 1° lvello dedicata ad ogni cluster ed una di 2° livello comune a tuti i cluster. Inoltre, in GT200 si vede l’alu dedicata ai calcoli di tipo fp64 che in Fermi non c’è (si accoppiano due alu fp32). Infine, come detto, in Fermi sono stati raddoppiati sia la warp instruction queue che il warp scheduler.
Fin qui tutto molto interessante, ma anche tutto molto votato al GPGPU; ad esempio, come detto, non si hanno informazioni sull’implementazione del tessellator, sull’architettura e l’efficienza delle ROP’s o delle TMU (di cui si sa solo che le operazioni di texture blending saranno affidate allo shader core, come del resto fa anche RV870); né si conoscono le frequenze di funzionamento dei chip della famiglia Geforce. Inoltre, l’architettura delle alu vista sopra ha qualche limite, dovuto al fatto che ci sono delle risorse (registri in particolare) condivise tra le unità funzionali del chip. Per cui, ad esempio, un cluster esegue 32 operazioni fp32, o altrettante INT, oppure 4 SF ops o 16 fp64.
Se, quindi, G80 non era, di fatto, un chip votato al gpgpu e GT200 lo era solo parzialmente e con un supporto “posticcio”, G100 nasce come chip con un a spiccata vocazione al GPU computing e quanto rivelato finora lascia intendere che questo sia stato uno degli obiettiivi primari dei tecnici nVidia, se non addirittura il principale.
Non approfondisco ulteriormente il discorso di G100 per lo stesso motivo per cui non ho approfondito quello su Larrabee. Avremo modo di tornare sull’analisi delle architetture dei due chip per parlarne in maniera più diffusa. Queste motizie in “pillole” costituiscono solo lo spunto per alcune riflesisoni personali.
Partendo da Larrabee, tutte le perplessità espresse nella prima parte inducono a riflettere sull’approccio scelto da Intel, diamentralmente opposto a quello di nVidia: si è partiti da una CPU per arrivare a progettare una GPU. Quanto sia funzionale ed efficace questo tipo di approccio, al momento non ci è dato di sapere; di certo Intel ha incontrato grandi ostacoli che l’hanno convinta o costretta, per il momento, a defilarsi. Questo non vuol dire che in futuro non avremo una GPU basat sul progetto Larrabbe ma, semplicemente, che non l’avremo nel futuro prossimo. IMHO, Intel dovrà rivedere in parte i suoi piani relativi ad una GPU interamente programmabile. Al momento non c’è alcun vantaggio di tipo prestazionale a non implementare unità di tipo ff in alcuni blocchi funzionali di un processore grafico. Certo, un chip siffatto costituirebbe una piattaforma facilemnte aggiornabile al variare delle API di riferimento, ma questo vantaggio sarebbe bilanciato, in negativo, da un hit prestazionale molto elevato in determinati ambiti e con alcuni tipi di calcolo in particolare. Quando sentii parlare per la prima volta di Larrabee e ne lessi le specifiche, ebbi l’impressione di un chip molto votato al GPGPU ma che avrebbe avuto seri problemi ad imporsi come GPU di fascia alta. Oggi resto della setssa idea e vedo Larrabee più come un concorrente di Fermi in ambito GPGPU che come un terzo incomodo nel mercato delle GPU high end.
Dal canto sua, nVidia sta spingendo da tempo sul GPGPU. Dal momento in cui si è capito che si andava verso una convergenza CPU-GPU e verso la possibile integrazione di funzionalità tipiche delle cpu all’interno delle gpu, nVidia ha compreso l’importanza di avere un chip che fosse punto di riferimento in quest’ambito. Sicuramente si tratta di una nicchia, ma di una nicchia di importanza strategica vitale per chi non ha la possibilità di realizzare una piattaforma integrata cpu-gpu, contrariamente ai suoi due maggiori competitor (uno atuale l’altro in prospettiva futura). Lo strumento glilo hanno fornito le architetture a shader unificati, molto più programmabili e flessibili delle precedenti. Certo, le prime generazioni, quelle basate su G80, sono servite solo da apripista per la generazione di chip successiva che dovrebbe avere Fermi come punto di partenza.
E’ certo che, però, anche nVidia sta incontrando non poche difficoltà nella realizzazione del suo chip. Con G80 ha scelto la strada dell’architetura superscalare, il che comporta “chipponi” grandi, compkessi, con molto spazio occupato dai circuiti di controllo e poca possibilità di introdurre unità ridondanti per aumentare le rese (un cluster di 32 alu di G100 occupa, con “annessi e connessi”, almeno il doppio dello spazio di uno da 80 alu di RV870). Questo, con un chip di 3 miliardi di transistor, crea non pochi problemi a livello di progettazione e di ottimizzazione e, sull’onda dei problemi incontrati da TSMC con il porcesso a 40 nm, di cui si era a conoscenza da un pezzo, sta rendendo la realizzazione del chip e la sua commercializzazione ancora più complicata.
Con questo non intendo dire che il ritardo di Fermi sia colpa di TSMC. I problemi della fonderia taiwanese erano noti e derivano dal fatto che il processo a 40 nm non può considerarsi un mero shrink ottico di quello a 45 adottato da TSMC per dispositivi a basse prestazioni. Si tratta di un vero e proprio full node rispetto ai 55 nm adottati in precedenza per le gpu di ATi e nVidia. Questo lo si sapeva già diversi mesi prima che si iniziasse la sperimentazione sui 40 nm e qualche alto papavero di TSMC aveva minimizzato il problema.
In realtà, però, le difficoltà per TSMC, che stanno facendo andare a rilento anche le vendite delle GPU a 40 nm di ATi, rappresentano, a mio giudizio, solo una parte dei problemi incontrati da nVidia. Quella che lascia pensar male è la continua serie di maldestri tentativi di ricordare che deve uscire un chip DX11 compliant targato Santa Clara. “Maldestri” è l’unico termine che mi viene per definire una presentazione con una scheda video fake, fatta in un periodo in cui era lecito nutrire ragionevoli dubbi sull’esistenza di una piattaforma con Fermi funzionante, come pure un po’ di foto, lasciate “negligentemente sul comodino”, ovvero buttate qua e là in rete (fecebook, qualche forum, ma nulla di ufficiale) in cui si ritrare Fermi in azione.
Altra cosa che lascia perplessi è che sulla versione Tesla si sa pressochè tutto, comprese le frequenze e le prestazioni in rapporto a GT200 (ma il confronto, soprattutto in fp64, è impietoso) mentre della versione Geforce non si sa nulla neppure in rapporto allo stesso GT200. Come pure è sospetto che abbiano rilasciato le specifiche architetturali con dovizia di particolari, ma senza entrare nel merito di quelle feature che riguardano il gaming. Eppure non c’è rimasto nulla da tenere nascosto: ATi ha svelato le sue carte da un pezzo, rispettando, almeno stavolta, la roadmap; Intel sarà per un pezzo fuori dai giochi e sicuramente salterà questa e almeno un altro paio di generazioni. La domanda che mi pongo è: cosa c’è da tenere nascosto e a chi?
Le probabili risposte sono tante; una potrebbe essere che Fermi non è, nei giochi, così veloce come ci si aspetti che sia (questo non vuol dire meno veloce di RV870 ma potrebbe anche voler dire troppo poco più veloce). In tal caso ha senso non svelare le frequenze di funzionamento perchè, magari, si possono ancora incrementare le prestazioni lavorando su di esse. Una cosa analoga successe ai tempi di NV30 ma allora furono diffuse le specifiche, frequenze comprese, che risultarono modificate al momento del lancio del chip.
Un’altra spiegazione potrebbe essere che nVidia non voglia fare un paper launch con pochi esemplari funzionanti, facendo poi attendere mesi e la maturazione del pp a 40 nm per effettuare il vero lancio. Ma allora perchè continuare a bombardare il web con notizie e foto relative a Fermi? Ormai, immagino, tutti sapranno che deve uscire un chip grafico con quel nome in codice e con quelle caratteristiche architetturali.
Altra spiegazione è che, ad oggi, non esistono ancora prototipi funzionanti di Fermi e, in tal caso, la cola non è affatto imputabile ai problemi di TSMC ma a qualche bug non ancora individuato a causa dell’elevata complessità del chip.
Tra queste, al motivazione più debole mi sembra quella del paper launch; in fondo se si vuole limitare le vendite dei competitor (e qui parlo in linea generale e non con stretto riferimento ai chip grafici) non ci si limita a dire “stiamo arrivando” ma, se si ha la possibilità, si mostra anche ciò che si è in grado di fare, se questo può dissuadere gli acquireti a rivolgersi altrove; nVidia una cosa del genere la fece con la 7800 GTX 512 MB, prodotta in pochissimi esemplari, da chip selezionatissimi, con voltaggi e frequenze fuori specifica, per togliere lo scettro prestazionale a R520. Subito dopo le feste natalizie, nVidia lancio la 7900 GTX con pp inferiore e stesse frequenze della 7800 phantom edition. In quel caso, però, il mostrare le prestazioni unito alla promessa “stiamo arrivando” ebbe una certa efficacia a livello di immagine. In questo caso, IMHO, nVidia più che non volere, al momento, non può mostrare le potenzialità di Fermi.
I portagonisti di questo articolo sono dunque due chip che stanno vivendo storie piuttosto travagliate; ma se da un lato abbiamo un chip molto interessante e, sulla carta, estremamente innovativo (forse troppo) che, per ora, non vedrà la luce (ne si sa come e quando sarà commercializzato), dall’altra abbiamo un altro chip altrettanto interessante, magari meno innovativo per il settore, se visto in ottica GPU (Fermi ha, comunque, l’architettura di una GPU), ma che sicuramente uscirà e, stando alle specifiche su carta, dovrebbe rivelarsi un prodotto competitivo. Certo, nVidia dovrà cercare di stringere i tempi, non tanto per un discorso di vendite, quanto per il fatto che dopo aver, a costo di notevoli sacrifici, annullato il gap che la divideva da AMD sui processi produttivi adottati, il ritardo di Fermi rischia di riconsegnare ad AMd un certo margine di vantaggio, dato che ora può, contestualmente all’affinamneto dei 40 nm, iniziare a lavorare, in tutta tranquillità, sui 32 e sui 28 (o direttamente su questi ultimi), potendo contare anche su Global Foundry.
Non e’ una tragedia Larrabee prima o poi arrivera’, chi crede il contrario e’ un illuso.
Il problema fondamentale che riguarda Intel sopratutto se vorra’ fare di Larrabee un prodotto consumer competitivo e’ che ci vuole il supporto software adeguato come ATI e Nvidia insegnano. E quest’ultime pur con le ingenti risorse che investono sul versante software di tanto in tanto hanno comunque dei problemi coi loro drivers.
Certo il problema Intel lo puo’ sempre superare come ha fatto con Arrandale (inserendo un chip grafico cioefeca e non dando alcuna scelta ai consumatori) ^_^ , ma rischia di essere un boomerang sopratutto se AMD mette l’acceleratore sulla cpu.
Non mi stupirei di vedere il primo esemplare di larrabee integrato in qualche nuova cpu intel come gpu “discreta”.
Qualcosa con prestazioni non troppo male ma neanche da boom, sicuramente più potente (in modo propo0rzionale al tempo di lancio) rispetto alle attuali soluzioni integrate nel chipset ma non al livello delle GPU tradizionali.
L’unico vantaggio è che potrebbe essere impiegata in modo massiccio in un OS con supporto GPGPU lasciando alla sk video il ruolo di rendering grafico.
Non sarebbe male vedere in un futuro uno scenario che assomiglia a quello delle prime 3dfx: CPU che si occupa di setup e IA e fisica del gioco e sk video che fanno il resto. oppure avere uno scenario ibrido in cui… vabbè sto esagerando… buonagiornata
DIEGO
nell’articolo si fa accenno al processore CELL che di fatto è una cpu con integrate moltissime funzioni presenti nel GPGPU computing..
quindi possiamo dire che Intel ha copiato in un certo senso quanto di buono fatto da Sony IBM TOSHIBA con il processore che tante soddisfazioni ha dato e sta dando…ricordo la capacita di questa cpu(gpgpu) di elaborare decine di flussi mpeg2 senza rallentamenti…
tenendo conto che l’architettura cell ha 4 anni circa, è evidente di quanto sia avanti rispetto alle presenti GPU(CPU).
intel vuol vincolare larrabbe al microcode x86 per avere un vantaggio di brevetti e non certo per l’efficenza che questa architettura si porta dietro…
resta il problema non da poco che passare attraverso il BUS PCI-E per i calcoli GPGPU risulta vincolante per la maggior parte delle applicazioni multitreanding, chi ha programmato in CUDA sa benissimo degli incubi che si hanno quando bisogna fare il debugging…e quanti problemi sorgono quando si passa dalla modalità GPU a quella GPGPU in un sistema con molte applicazioni aperte contemporaneamente…
in definitiva, l’articolo parla di una tecnologia di calcolo che è del tutto immatura e che necessita di essere integrata meglio nelle attuali architetture per personal computer…
reputo che la soluzione CELL ossia di integrare all’interno del CPU anche la GPGPU sia la soluzione migliore proprio per una efficente gestione del sistema…
@homero:
Io li chiamerei DSP, più che altro.
Cell è una CPU orientata allo stream processing. Sicuramente basandoci soltanto su questo termine possiamo considerarla simile alle GPU, ma come avrai letto dall’articolo, le GPU sono molto diverse. Per cui per Cell non parlerei di GPGPU.
Intel non ha copiato Cell, perché Larrabee architetturalmente è abbastanza diversa, ed è votata realmente al GPGPU computing.
E’ un progetto a sé stante che rimarrà tale proprio per le sue peculiarità. Difatti a 4 anni di distanza non mi sembra di aver visto dilagare la sua adozione.
Concordo, e mi sembra anche evidente: ha in mano la gallina dalle uova d’oro e la vuole sfruttare il più possibile.
Questo mi sembra ovvio. Ma la tendenza è quella di delegare alla GPU i calcoli “massicci” (ove possibile / applicabile).
Per quanto già detto, assolutamente no. Cell va bene (e neanche tanto, se pensiamo alla PS3) nella nicchia che s’è creato.
Per quanto riguarda il futuro, non lo vedo prospero per Larrabee nel campo delle GPU, dove continuerà a essere surclassata dalle “classiche” GPU: oggetti che sono nati per fare bene questo lavoro.
Se l’obiettivo di Intel è quello di spingerla nel mercato delle GPU, farà un enorme buco nell’acqua, similmente a Itanium che avrebbe dovuto prendere il posto di x86 anche nei comuni PC. Nel GPGPU computing ha sicuramente delle buone carte da giocarsi, invece.
Idem per Fermi. Se nVidia pensa di assaltare il mercato delle CPU (non avendo licenze x86 e con la prossima integrazione di CPU e GPU nello stesso chip, avrà per forza poco spazio in futuro) con una GPU “pompata” con funzionalità da CPU, farà anche lei un buco nell’acqua. A maggior ragione se, per fare questo, sacrificherà le prestazioni nel suo dominio d’eccellenza: i giochi.
CPU e GPU sono troppo diverse per poter pensare a una soluzione unica che possa inglobare entrambe le funzionalità.
Certamente la notevole capacità di calcolo parallelo / massivo delle GPU è allettante per chi ha bisogno di macinare grandi quantità di numeri.
Personalmente ho in mente soluzioni radicalmente diverse per il futuro delle CPU in particolare, alla luce delle tendenze in atto. Più che un omogeneizzazione “tutto fare” vedrei bene una specializzazione; un parziale ritorno al passato in cui abbiamo elementi, CPU e GPU, che integrino e facciano bene soltanto ciò per cui sono nate e per cui presentano prestazioni elevate.
Per il momento è soltanto un pensiero. Vedremo se si concretizzerà.
il cell paragonato ad un DSP!! o santa apollonia!!!
ad ogni modo considererei l’autore dell’articolo di evidenziare le differenze tra la gestione dei BUS che sono presenti nel processore CELL, e la gestione dei BUS che sono presenti in un sistema GPGPU-CPU….giusto per far comprendere quanto IBM sia stata avanti 4 anni fa nella progettazione di questa CPU…
per quanto riguarda NVIDIA…..no comment!!!
programmare in CUDA è semplicemente un incubo…
@homero:
No, mi riferivo alle SPE, che sono le unità funzionali deputate al calcolo “streaming”, appunto.
La PPE come modello rappresenta la classica CPU.
Di quali bus parli? Non è chiaro (e a volte nemmeno di bus si può parlare, ma di collegamenti punto-punto).
[quote]
Personalmente ho in mente soluzioni radicalmente diverse per il futuro delle CPU in particolare, alla luce delle tendenze in atto. Più che un omogeneizzazione “tutto fare” vedrei bene una specializzazione; un parziale ritorno al passato in cui abbiamo elementi, CPU e GPU, che integrino e facciano bene soltanto ciò per cui sono nate e per cui presentano prestazioni elevate.
Per il momento è soltanto un pensiero. Vedremo se si concretizzerà.
[/quote]
Credo che bulldozer di AMD sarà uno step in avantiin questo senso. Due “core” (come li chiama AMD) integer e una sola FPU, con un arbitro che ne gestisce dinamicamente l’allocazione.
Penso di sì, anche se io ho in mente soluzioni più estreme. :D
Mettiamo un po’ di carne sul fuoco: http://www.pc.sk/obr/GTX_300_specs.png :D
@ homero
cell è una cpu, anzi uno stream processor e non una gpu, quindi non si può parlare di gpgpu o di funzionalità di tipo gpgpu. Tra l’altro, cell non è affatto indicato per fungere da cpu proprio perchè in grado di gestire solo due thread (uno per pipeline) e in order. Questo significa che, ad esmepio, le operazioni di texturing che presentano latenze elevate, paralizzerebbero l’elaborazione; è lo stesso appunto che nell’articolo muovo a larrabee che, rispetto alle tipiche gpu, gestisce troppo pochi thread per core (solo 4). Quelli che cell può fare, relativamente alle operazioni 3d, sono i calcoli di tipo geometrico o alcune operazioni di post processing.
In quanto ai limiti imposti dal bus pci-e siamo d’accordo; si tratta di uno dei peggiori colli di bottiglia da aggirare e il modo migliore per minimizzarne l’impatto negativo è effettuare il minor numero di accessi e, per ogni accesso, trasferire il maggior numero di dati (se si riesce a saturare la banda passante tanto di guadagnato). Per questo si preferisce effettuare il trasferimento di vertici, texture, ecc, in batch di dimensioni sempre maggiori. Addirittura, la soluzione ideale, nonostante l’ampia bandwidth, sarebbe quella di ridurre al minimo anche gli accessi alla vram.
Purtroppo con il gpgpu questo non è sempre possibile e non si riesce ad evitare il continuo andirivieni attraverso il pci-e o verso la vram.
Sul discorso interconnessioni; su console posso fare come mi pare poichè devo interfacciare dispositivi ben determinati tra di loro: quindi nessuno mi impedisce, ad esempio, di fare una connessione punto punto invece di una a bus. Su un pc è completamente diverso: devo riuscire ad interfacciare tra di loro tanti dispositivi differenti (un phenom o un i7 hanno interfaccia diversa con la scheda madre, come pure un rv870 ed un gt200 ne hanno due differenti con il pcb della scheda video). Di conseguenza, ho bisogno di avere degli standard sia a livello hw che sw. La sinistra caratteristica degli standard è che, se da un lato permettono di interfacciare tra di loro dispositivi molto diversi, dall’altro ti costringono a scendere a compromessi e uno di questi riguarda proprio la velocità di trasferimento dati.
@The3D
in effetti, è più un’esigenza di nVidia quella di spingere il calcolo gp su gpu, proprio perchè Intel e, soprattutto, AMD, hanno al momento, la possibilità di progettare SoC con core asimmetrici specializzati che svolgano i compiti, rispettivamente, di cpu e gpu.
@ Cesare
che intendi con soluzioni più estreme? :D
Eliminare la sezione SIMD e lasciare che sia la GPU integrata nel core (perché questa è la strada che si seguirà a breve) a occuparsene.
Grazie al fatto che CPU e GPU saranno a pochi millimetri di distanza ed è possibile eliminare il collo di bottiglia di PCI-Express & co..
L’obiettivo è quello di lasciare che CPU e GPU facciano bene quello per cui sono nate, evitando quelle che, per me, sono inutili sovrapposizioni.
Di questa semplificazioni ne trarranno entrambe vantaggio, ma in particolare la CPU (e la sua sezione di decodifica).
@ Cesare
Ok, pensavo a qualcosa di più……….estremo :D
In effetti è quello che succederà; anzi, molto probabilmente, si andrà verso chip con unità centrale costituita da una cpu di tipo “tradizionale” (multicore) e gpu di tipo “distribuito” con core asimmetrici. In questo modo, sarà possibile utilizzare, ad esempio, uno o più core della gpu per il redering, un core per la fisica, uno per la gestione dei flussi audio, ecc (ovviamente parlo delle situazioni in game).
Un po’ sul modello di alcuni supercomputer che utilizzano cpu tradizionali per pilotare chip cpn unità di calcolo di tipo SIMD (mi viene in mente la soluzione ocn opteron dual core con ciascun core che pilota un cell con PPE disabilitato).
Di estremo pensavo allo smistamento delle istruzioni SIMD delle CPU verso la GPU, ma credo che porterebbe più problemi che benefici.
Sì, il modello è quello: CPU tradizionale senza SIMD, e tutto il resto sulle spalle della GPU. :-P
Rimarrebbe comunque un grosso problema: la programmazione.
Oggi un’unità SIMD è abbastanza semplice da programmare. Una GPU no (se prendiamo CUDA, preferirei andare a zappare piuttosto che scrivere codice così contorto).
un chip multicore con core asimmetrici, dal’esterno è visto come un unico dispositivo. Ci sono da risolvere due problemi: il bilanciamento dei carichi di lavoro (e io propenderei per un bilanciamento di tipo dinamico, anzi affiderei all’hw anche la gestione dell’ILP) e il tipo di device visto dall’esterno.
Per ipotesi, si può fare in modo che tu, dall’esterno, veda una cpu a cui affidare sia calcoli di tipo gp che relativi alla grafica e che sia il chip stesso a “decidere” come allocare le risorse e come ripartire i task. Questo complicherebbe molto le cose a livello hw ma semplificherebbe la vita a voi coder :D
per intenderci, qualcosa del genere
http://www.hwupgrade.it/news/business/cpu-e-gpu-per-un-nuovo-supercomputer-australiano_31019.html
con le dovute proporzioni, integrate in un solo chip e con un unico thread processor a gestire il tutto. O, al massimo, un modello di programmazione tipo quello delle attuali cpu multicore. Nel primo caso, che è quello che preferisco di gran lunga, nonostante le complicazioni dell’hw, l’ILP sarebbe gestito interamente in hw
Indovina quale preferisco io. :D
Il massimo per me sarebbe poter vedere le GPU come coprocessori a cui delegare compiti. Al limite, e meglio ancora, il solo arbiter che si occuperebbe poi di smistare le richieste alle varie GPU, bilanciando il carico.
@ all
CUDA e’ un gran casino… ma non e’ che scrivere codice MPI per un cluster sia una gioia :) e anche il codice multithreaded puo’ essere facile da scazzare alla grande. Insomma: il paradigma di programmazione parallelo e’ difficile per gli umani :) non importa in che linguaggio. Per questo si sta facendo molta ricerca su nuovi paradigmi di programmazione parallela che permettano di scrivere codice piu’ semplice ed intuitivo.
@ Cesare & Yossarian
Affidare tutta la schedulazione dei carichi all’hardware puo’ essere problematico: l’hardware non ha visibilita’ di quello che succede ad alto livello, quella ce l’ha solo il sistema operativo. Probabilmente la scelta migliore sara’ avere una API tra SO e hardware che permetta al SO di pilotare le risorse ad alto livello. Ad esempio: l’utente comincia a vedere un film, il SO lo capisce (perche’ il software avra’ qualche meccanismo di registrazione, ad esempio), una la API per dire all’hardware che “ora si va di audio-video!”. L’hardware attivera’ le sezioni opportune, dando corrente al decoder H264, alzandogli la frequenza, eccetera. Una volta finito, l’hardware puo’ scollegare l’unita’ e metterla a riposo.
L’hardware da solo non riucirebbe a capire bene cosa sta succedendo ad alto livello semplicemente analizzando il flusso di istruzioni.
@ Yossarian
Rispetto al numero di thread di Larrabee, non penso sia un problema sostanziale: Larrabee e’ un multicore vettoriale. Alla fin fine, l’approccio super-multithreaded come quello di NVidia non e’ poi cosi’ diverso da un approccio vettoriale.
NVidia usa tutti quei thread per mascherare le latenze di accesso alla memoria, ma in realta’ i singoli thread non possono essere schedulati individualmente: come sai (meglio di me :) i thread vengono schedulati in warp, quindi o i warp vanno tutti insieme giu’ per lo stesso execution path (e allora si comportano grossomodo come un singolo stream di operazioni vettoriali), o i singoli thread vengono serializzati (e le prestazioni crollano di 1–2 ordini di grandezza).
Ti puo’ dare qualcosa in termini di flessibilita’, ma non i due approcci non li vedo cosi’ diversi.
PS: quando ci metto troppo a scrivere… perdo tutto! Mi viene una schermata che dice di reinserire il codice antispam, solo che quando clicco non succede nulla, e il commento e’ perso. Ormai ho imparato e scrivo sul blocco note, e poi copio incollo qua dentro, ma e’ estremamente sconveniente. E’ un problema di Firefox?
calma ragazzi!!!
programmare i cluster non è un incubo…esistono librerie ed algoritmi che permettono con un po’ di impegno di scalare linearmente rispetto al numero di CPU…
programmare CUDA è un incubo perche’ quando hai scritto il tuo bel codice, a volte le prestazioni sono inferiori di gran lunga alle aspettative o altre volte ci sono dei loop infiniti che ti lasciano perplesso di fronte al monitor….e ora cosa faccio???!?!?!?
inoltre i sistemi di programmazione tesla devono essere considerati separati dal resto del sistema…ossia se per qualche ragione due tread sfruttano la medesima GPU ci sono molte probabilità che il sistema vada in crash o abbia comportamenti anomali e la GPU essendo anche la scheda video è sempre impegnata dai driver e quindi è una condizione tutt’altro che remota.
quindi attualmente quando si programma con CUDA non soltanto bisogna tener conto del singolo codice che gira sulla GPGPU e del codice che carica le istruzioni sulla scheda video, ma anche degli altri tread che girano sul sistema che possono interferire con le risorse condivisa dai driver NVIDIA e vi assicuro che questi creano dei grossi mal di pancia!!!
allora se parliamo di un server dedicato con un singolo software che gira su CUDA allora abbiamo qualche vantaggio sempre che il software sia ottimizzato per GPGPU computing ossia istruzioni FP32 perche’ almeno attualmente le istruzioni in doppia precisione danno un vantaggio reale quasi nullo rispetto al cpu di ultima generazione…
per quanto riguarda il CELL, questo processore E’ UNA CPU ossia è possibile eseguire un debug come si è abituati a fare con i sistemi di sviluppo classici, questo per voi sembra cosa da poco, ma in realtà è importantissimo per ottimizzare il codice, valutarne l’efficacia…etc etc, per quanto riguarda la gestione dei TEXEL questo non credo che c’entri molto con GPGPU, per la semplice ragione che i calcoli svolti dalle GPGPU sono essenzialmente calcoli su matrici, o su serie numeriche, in definitiva si tratta di eseguire contemporaneamente su un vettore moltiplicazioni/divisioni e somme/sottrazioni, questo tipo di calcoli sono implementati egregiamente nel processore CELL e sono quelli per i quali le GPGPU sono utilizzate in alcuni algortimi scientifici, ovviamente la precisione utilizzata attualmente FP32 è quella che permette un burst prestazionale reale, infatti quando sono rischiesti calcoli in doppia precisione purtroppo le prestazioni calano terribilmente…questo vale sia per il CELL che per le GPGPU..
in quanto tutti gli algoritmi percettivi non hanno la necessità di essere eseguiti in doppia precisione come quelli in ambito medico…
per quanto mi riguarda continuero’ a sviluppare algoritmi per CPU in quanto odio avere i mal di pancia e perdere tempo per comprendere le ragioni per le quali la GPU non ne vuole sapere di fare il suo dovere…
leggevo un articolo su un processore intel sperimentale con 48 core, bene questo sicuramente è il futuro rispetto al GPGPU, in quanto con una CPU con 48 core sono sicuro di poter riutilizzare comodamente il mio codice che scalerà linearmente senza problemi…quindi quando nvidia farà una CPU con molti core o un coprocessore molti core da affiancare alla cpu con un directBUS allora ne riparliamo…
@ homero
Il fatto di avere 48 core cosa c’entra col fatto di scalare linearmente? Cmq, se riesci a far scalare linearmente qualsiasi algoritmo, allora mi sa che ti danno una cattedra in una qualsiasi $megauniversita’, o $cifrone in qualsiasi compagnia.
BTW, quel processore che Intel ha mostrato non ha coerenza della cache. Quindi torniamo da shared memory a MPI…
Concordo sul fatto che CUDA ha dei grossi problemi di debuggabilita’. Con le nuove versioni (e con la nuova architettura) dovrebbero aver migliorato un po’ le cose, vedremo.
@pleg: se non ricordo male POWER 6 e 7 di IBM espongono delle funzionalità (e istruzioni) per controllare i thread che girano nei core, quindi dando la possibilità di innalzare o abbassare la “priorità” a specifici task da eseguire.
Potrebbe essere una strada da seguire anche per i carichi di lavoro affidati a un cluster di GPU.
Concordo con l’ultimo commento: scalare linearmente all’aumentare dei core per qualunque pezzo di codice è impossibile (c’è una legge, di cui sistematicamente dimentico il nome :D, che si applica).
P.S. Non è un problema tuo o di FireFox. Credo sia il plugin antispam di WordPress che fa i capricci ogni tanto. :|
@homero: nessuno qui ha negato che Cell sia una CPU. :D
Per quanto riguarda il GPGPU, è vero che le SPE di Cell concettualmente sono in grado di eseguirli, ma sono unità molto limitate ed è abbastanza incasinato sfruttarle per benino fra la dimensione ridotta del loro Local Storage e il dover programmare a manina il memory controller per andare a recuperare (o scrivere) dati dalla memoria centrale.
@ Cesare
Ti riferisci alla legge di Amdahl?
Se la usi per il parallelismo, in effetti, ti dice che prima o poi la parte sequenziale del codice viene a morderti le chiappe (scusate il tecnicismo :)
E’ lei! Grazie. :D
“e riesci a far scalare linearmente qualsiasi algoritmo”
scusa dove ho scritto questa frase?!!?
ho scritto invece
“sono sicuro di poter riutilizzare comodamente il mio codice che scalerà linearmente senza problemi”
questo perche’ il mio codice già gira comodamente su cluster e scala linearmente aumentando i core…
ossia passando da dual core a dual processor x 4 core scala linearmente…e analogamente quando si va in cluster con 20 processori…..
questo con la GPGPU semplicemente non è possibile perche’ richiede una riscrittura completa del codice!!!
e ancor di piu’ se si utilizzano multi-GPGPU…..
forse per voi riscrivere il codice è cosa da poco, ma in genere richiede tempo, e un lungo lavoro di affinamento e debugging…
Veramente l’obiezione è proprio quella: con lo stesso algoritmo, all’aumentare dei core non si scala linearmente. Non è che passi da 2 a 4 core e le prestazioni sono esattamente raddoppiate (o i tempi dimezzati). Ma proprio no. ;)
@ homero
Sorry colpa mia, avevo capito che parlavi in generale.
Comunque l’affermazione e’ un po’ forte, c’e’ sempre un limite oltre il quale non riesci piu’ a scalare linearmente. Per curiosita’, che algoritmo e’? Che problemi risolve? E che problemi incontravi sulla GPU? Circa un anno fa avevo sviluppato qualcosa per CUDA, e non aveva funzionato una cippa, ma era stato molto utile fare l’analisi del PERCHE’ non aveva funzionato (e sono stato contento nel vedere che buona parte dei punti deboli che avevo identificato sono stati migliorati nella nuova architettura Tesla — NVidia li conosceva gia’ da 4 anni :)
@ pleg #18
di fatto, quello che avviene oggi, relativamente all’ottimizzazione delle gpu, è che si cerca di ottimizzare tutto ciò che si può a livello di compilazione, ma si lascia alla gpu il compito di gestire in hardware il bilanciamento dei carichi di lavoro e, nel caso di chip superscalari come quelli di nVidia, anche l’ILP. Questo perchè, di fatto, su una gpu non è possibile agire in maniera diversa in quanto gli stadi, per così dire, programmabili, effettuano una serie di operazioni i cui risultati obbligano al riordino delle istruzioni in coda. Per questo motivo, lo scheduling avviene del tutto (nVidia) o in parte (ATi) in hardware. Questo tipo di approccio, nonostante non sia perfetto (come dici giustamentel il thread processor può operare solo sulla porzione di codice che gli è visibile), rispetto ad una schedulazione di tipo statico, permette, statisticamente, guadagni prestazionali non inferiori al 30-40%.
Un chip che integrasse al suo interno cpu e gpu, ad alto livello dovrebbe essere visto come una cpu di cui la gpu diventi un coprocessore o, ribaltando il concetto e, a seconda del tipo di elaborazione, una gpu di cui la cpu sia coprocessore (occupandosi di fornire alla gpu il codice di cui ha bisogno nella forma che le è più congeniale); una cosa del genere avviene, ad esmepio, su x360 che è un disosititvo gpu-centric mentre, al contrario, ps3 è cpu-centric.
Veniamo a larrabee. Il suo modello è quello di un processore vettoriale di tipo 16-way per core. Questo apparentemente, poichè, di fatto, si comporta in maniera non molto dissimile da G80. Infatti, i 16 dati che carica per ciclo, non sono “strettamente” di tipo vettoriale o, quanto meno, non del tipo del vettore classico a cui possiamo pensare (ad esempio il classico vettore completo a 4 componenti). Si tratta, ad esmepio, di 16 pixel le cui componenti vengono processate, per ogni alu del vettore, in serie; quindi, ad esempio, 16 pixel dotati di componenti RGB e alpha saranno processati in parallelo (e le rispettive componenti in serie, esattamente come avviene su processori superscalari). Ogni gruppo di pixel (che viene raggruppato in forma di vettore in un’apposito buffer) forma un thread; questo significa che larrabee può gestire l’equivalente di 8 warp per core. Un chip come GT200, invece, gestisce fino a 1024 thread per alu (che in questo caso equivalgono ad una singola istruzione scalare), che significa 32 warp per alu (ossia 768 warp per cluster). Vero che la cache L1 di larrabee è strutturate per essere veloce quasi quanto un registro (intel parla di 12-14 cicli per accesso contro, ad esempio, gli 11 cicli per l’accesso ad un registro di GT200) e questo permette di mascherare meglio le latenze almeno relativamente all’accesso ai dati contenuti in L1. Però è anche vero che le attuali gpu fanno un uso molto più spinto del multithreading di quanto non faccia larrabee. Considerando che il thread processor gestisce la istruzioni OoO ma i buffer dei cluster di alu sono FIFO, avere più thread (o warp) in circolazione può costituire un vantaggio non indifferente in determinate situazioni.
x dimauro
confondi calcolo parallelo con calcolo distribuito…
sui cluster si eseguono generalmente algoritmi di calcolo distribuito che possono anzi devono scalare linearmente…
x peg
gli algoritmi utilizzati sono volti all’analisi delle differenze/convergenze su larghe basi di dati, nella pratica sono calcoli di matrici e serie numeriche….
x yossarian
l’analisi dell’architettura fatta è sicuramente interessante, ma le GPGPU si utilizzano mediante le librerie o le classi C/C++ e non certo utlizzando direttamente l’hardware, purtroppo/perfortuna bisogna affidarsi al compilatore in tutto e per tutto oltre che ai driver della scheda
pertanto riuscire a fornire un ambiente di sviluppo/debugging adeguato è fondamentale per sfruttare la “potenza” di questi processori, in caso contrario i dati prestazionali forniti restano puramente teorici.
posso affermare che in alcuni ristretti campi come i calcoli in singola precisione di algoritmi estremamente semplici e che non richiedo codice molto lungo(poche decine di righe di codice), il vantaggio prestazionale puo’ essere tangibile, al contrario per algoritmi complessi e che richiedono calcoli in doppia precisione purtroppo il vantaggio prestazionale diminuisce sensibilmente, fino ad annullarsi.
a parte questo il vero problema è che attualmente l’esecuzione degli algoritmi è alla cieca….ossia si carica tutto sulla scheda si da il via e poi non resta che incrociare le dita….
riuscire ad analizzare il proprio algoritmo ai fini di ottimizzarlo o semplicemente di scovare qualche bugs è impresa ardua se non proprio disperata…
questo grosso limite credo resterà presente ancora nelle prossime architetture previste per il 2010 essenzialmente perche’ i tempi non sono del tutto maturi per questi sistemi di calcolo, infatti queste schede GPGPU vengono usati per risolvere calcoli relativi ad algoritmi percettivi come l’analisi di flussi audio/video, come il riconoscimento facciale o di anomalie nelle immagini, o riconoscimento di timbri sonori, l’analisi di dati forniti da strumentazioni analogiche etc etc, ambiti di sicuro interesse ma certo non proprio generali…
in definitiva schede come TESLA di Nvidia faranno la fine delle schede transputer dei primi anni ’90…ossia finiranno a prendere la polvere da qualche parte, surclassate dall’avanzare inesorabile delle nuove CPU….(leggi CELL)
@ homero
sul fatto che le attuali gpu non siano dei rpocessori di tipo GP e siano indicati solo per svolgere determinati tipi di calcoli tra quelli oggi affidatin alle cpu, siamo tutti d’accordo,almeno credo.
L’ipotesi che io prospetto, però, è differente; prevede, infatti, l’utilizzo di una cpu come……cpu e di una gpu come coprocessore. Quello che oggi si fa usando il cell, in poche parole. Infatti neppure il celle è una cpu di tipo gp; al di là delle considerazioni tecniche (i SPE sono dei quasi DSP e l’unico elemento GP è il PPE che,però, rispetto alle cpu classiche, presenta diverse carenze architetturali), la dimostrazione pratica di ciò che dico è data dal fatto che da nessuna parte io cell è adoperato come cpu GP. Non lo è su PS3, non lo è quqando viene utilizzato come scaler all’interno dei televisori e non lo è in supercomputer, come roadrunner,dove funge da unità di calcolo di tipo SP e coadiuva le cpu GP di tipo opteron. E sia in roadrunner che nello spursengine di toshiba, il PPE è disattivato ed è sostituito da un core di un opteron e da un processore esterno che pilota i SPE, rispettivamente. In tutti questi contesti, il cell funge da coprocessore, sostituendo o affiancando le unità vettoriali del nchip che funge da cpu vera e propria. In tutti questi ambiti, i compiti svolti dal cell non sono dissimili da quelli che svolge o potrebbe svolgere una gpu.
Sicuramente cell è un progetto interessante, come lo è l’architettura “manycore” di Intel, ma, intanto, non è una gpu e quindi è improprio parlare di gpgpu riferendosi al cell; inoltre, anche come unitàcentrale, non lo vedo come cpu di tipo gp e pare non ce lo veda neppure IBM stessa, visto che le dimostrazioni fatte finora relative alle potenzialità del cell, riguardano simulazioni fisiche come simulazionji dei tessuti, dei terreni, oppure il cellè usato nel blade server per accelerare i MMORPG che hanno problemi di rallentamenti a causqa della gestione della fisica, oppure viene utilizzato per accelerare i flussi audio e video. Ma finora, a 4 anni dalla sua uscita, non ha ancora tr4ovato impiego come cpu gp su un qualsivoglia sistema.
E non lo troverai mai: Cell come CPU GP è troppo scarso. :D
@homero: quel che dici è vero nell’ipotesi che ogni cluster abbia esattamente le stesse risorse e non ci sia nessuna contesa fra i vari cluster. Altrimenti non puoi scalare linearmente.
@ Homero
Allora stai parlando di problemi “banalmente parallelizzabili”. Purtroppo quelli sono pochi (e “banali”, appunto :) , la maggior parte dei problemi interessanti sono difficili da parallelizzare (o da distribuire, che e’ lo stesso).
E continuo a non capire questa fissa col Cell. E’ un esempio di architettura eterogenea, coi suoi pregi e difetti. Non ha fatto molta piu’ strada di Itanium, fuori dal suo ambito. Non ha cambiato il mondo. Non si e’ sostituita a nulla. Ha dei campi di applicazione molto interessanti — esattamente come li ha il GPGPU. Il fatto che ultimamente si sentano parecchi annunci di supercomputer che integrano GPU al loro interno (quello cinese con schede ATI, il Livermore e quello australiano con schede NVidia) dovrebbe far riflettere.