Una nuova dimostrazione della tecnologia Cell

[Fx]

allora

premesso che se ricordo bene c'era una demo fatta in assembler puro che in 64 KB di .exe faceva il ray tracing in tempo reale su pc di qualche generazione fa (mi sembra di averla vista su un 386 a 40 mhz) e quindi dire "ray tracing in tempo reale" è un po' vago

premesso questo, se secondo te il ray tracing è general purpose OPPURE è una cosa che normalmente ti fa una scheda video siamo a posto. ripeto, prova a seguire la distinzione CPU - VPU - GPU che forse le cose ti si chiariranno meglio

detto ciò, come ha consigliato fek faresti bene a cercare altri "fonti del sapere" perchè la parte che hai quotato tu tratta dalla wikipedia è una castroneria bella e buona.

[fantoibed]

Originariamente inviato da Fx

premesso che se ricordo bene c'era una demo fatta in assembler puro che in 64 KB di .exe faceva il ray tracing in tempo reale su pc di qualche generazione fa (mi sembra di averla vista su un 386 a 40 mhz) e quindi dire "ray tracing in tempo reale" è un po' vago

Ovviamente stiamo parlando del core di una console di videogiochi quindi il concetto non è per niente vago. Si parla del ray tracing in tempo reale di ogni singolo fotogramma di un videogioco alla risoluzione massima prevista per la console che penso sia quello della HDTV a 1080 linee.

Originariamente inviato da Fx

detto ciò, come ha consigliato fek faresti bene a cercare altri "fonti del sapere" perchè la parte che hai quotato tu tratta dalla wikipedia è una castroneria bella e buona.

Andate a correggerla, allora. Wikipedia è un'enciclopedia libera accessibile a tutti. Comunque molti concordano con la descrizione della wikipedia.
http://www.blachford.info/computer/Cells/Cell4.html
The PC does have a weapon with which to respond, the GPU (Graphics Processor Unit). On computational power GPUs will be the only real competitors to the Cell.

GPUs have always been massively more powerful than general purpose processors [PC + GPU][GPU] but since programmable shaders were introduced this power has become available to developers and although designed specifically for graphics some have been using it for other purposes. Future generations of shaders promise even more general purpose capabilities[DirectX Next].

GPUs operate in a similar manner to the Cell in that they contain a number of parallel vector processors called vertex or pixel shaders, these are designed to process a stream of vertices of 3D objects or pixels but many other compute heavy applications can be modified to run instead [EE-GPU].

With aggressive competition between ATI and Nvidia the GPUs are only going to get faster and now "SLI" technology is being used again to pair GPUs together to produce even more computational power.

GPUs will provide the only viable competition to the Cell but even then for a number of reasons I don't think they will be able to catch the Cell.

Cell is designed from the ground up to be more general purpose than GPUs, the APUs are not graphics specific so adapting non 3D algorithms will likely mean less work for developers.

Cell has the main general purpose PU sharing the same fast memory as the APUs. This is distinct from PCs where GPUs have their own high speed memory and can only access main system memory via the AGP bus. PCI Express should speed this up but even this will be limited due to the bus being shared with the CPU. Additionally vendors may not fully support the PCI Express specification, existing GPUs are very slow at moving data from GPU to main memory.

[fek]

Originariamente inviato da fantoibed

Ovviamente stiamo parlando del core di una console di videogiochi quindi il concetto non è per niente vago. Si parla del ray tracing in tempo reale di ogni singolo fotogramma di un videogioco alla risoluzione massima prevista per la console che penso sia quello della HDTV a 1080 linee.

Fantascienza.

Andate a correggerla, allora. Wikipedia è un'enciclopedia libera accessibile a tutti. Comunque molti concordano con la descrizione della wikipedia.

Hai letto quello che ho scritto sulle GPU moderne?

E' inutile che posti link se non riesci a capire quando dicono fesserie. Una cosa non diventa automaticamente vera "solo perche' e' scritta su internet".

Affermare che il Cell puo' svolgere i compiti di una GPU dello stesso periodo piu' velocemente vuol dire non sapere di che cosa si stia parlando, per i motivi che ho elencato in un post precedente. Ed anche chi ha scritto questo testo che hai postato non sa di che cosa sta parlando, perche' non sa come funziona internamente una GPU, altrimenti non scriverebbe cio' che ha scritto. In particolare quando parla di bus AGP e PCI-E dimostra di non aver mai scritto due righe di codice 3d in vita sua.

[jappilas]

Originariamente inviato da Fx

allora

premesso che se ricordo bene c'era una demo fatta in assembler puro che in 64 KB di .exe faceva il ray tracing in tempo reale su pc di qualche generazione fa (mi sembra di averla vista su un 386 a 40 mhz) e quindi dire "ray tracing in tempo reale" è un po' vago

premesso questo, se secondo te il ray tracing è general purpose OPPURE è una cosa che normalmente ti fa una scheda video siamo a posto. ripeto, prova a seguire la distinzione CPU - VPU - GPU che forse le cose ti si chiariranno meglio

tieni conto che già dire "raytracing" in realtà è vago, in quanto l' algoritmo basilare che emette un raggio dall' osservatore verso gli oggetti 3d presenti nella scena è semplice e codificabile in un listato piuttosto breve...
il RT ha lo svantaggio di essere ricorsivo (quando un raggio primario colpisce un oggetto, dal punto di intersezione si dipartiranno vari altri raggi, alcuni diretti verso le sorgenti di luce presenti per determinarne l' influenza o meno), e quindi, scarsamente deterministico (non so a priori quanto tempo richiederà il rendering di un frame di un' animazione, a meno di non fissare dei limiti al numero di iterazioni e raggi secondari), ma il vantaggio di inglobare le funzioni di "ordinamento" della geometria (i raggi primari intersecheranno gli oggetti più vicini all' osservatore, che saranno quindi quelli di cui verrà calcolato il colore per il pixel corrente... a meno di trasparenze, nel qual caso genererò dei raggi secondari per il calcolo dell' effetto rifrattivo, ecc ecc)

questo per dire che, per pochi raggi (a che risoluzione andava la demo all' epoca, 320x200? quanti oggetti e fonti di luce c' erano ? io ricordo solo un toroide e uno spot..), nessuna iterazione secondaria, un po' di assembly 386 ben fatto, non trovo così eclatante che quella demo funzionasse su 386 o 486...

invece, se un algoritmo RT, "esteso" ai canoni odierni ( dotato magari di caratteristiche come la global illumination, oltre alle ormai "banali" ombre portate, riflessioni e trasparenze) riuscisse a girare in tempo reale per una scena tridimensionale generica (invece di una situazione perettamente nota a priori) , lo troverei assai eclatante

[Fx]

a) si parla di 1080i per il cell quando non si ha la più pallida idea di quale sarà la risoluzione "standard" della ps3, mentre si sa già che l'xbox 360 avrà come standard il 720i - che voglio dire, è già un'esagerazione per il mercato a cui si rivolge
b) le cazzate che si sono sparate e si sparano attorno al cell sono incredibili e hanno come unica spiegazione che dietro ci sono IBM e Sony, due colossi indiscussi del vaporware dapprima si diceva che avrebbero soppiantato gli x86, ora sento che invece soppianteranno le schede video... fatemi indovinare, ora ci diranno che soppianteranno gli hard disk e i monitor, e poi... TOMBOLAAAA
c) fantoibed, come giustamente dice fek, non è che se trovi scritta una cosa in giro per internet allora questa è vera, anzi, bisogna stare particolarmente attenti: perchè al posto di cercare in giro (facci caso, troverai scritto DI TUTTO e IL CONTRARIO DI TUTTO) non provi a pensare che magari anche quello che scrive fek (io mi tiro fuori) può essere autorevole (e forse di più di quello che trovi scritto in giro) e che quindi vale la pena di essere ascoltato? hai pure l'occasione di CHIEDERE se qualcosa non ti è chiaro, se ciò che fek dice non si regge in piedi lo scopri subito, se invece ne sa per davvero il suo discorso non farà una grinza, come mi pare sia

[Fx]

Originariamente inviato da jappilas

tieni conto che già dire "raytracing" in realtà è vago, in quanto l' algoritmo basilare che emette un raggio dall' osservatore verso gli oggetti 3d presenti nella scena è semplice e codificabile in un listato piuttosto breve...

sono assolutamente d'accordo, infatti quando dicevo:

Originariamente inviato da Fx

quindi dire "ray tracing in tempo reale" è un po' vago

intendevo esattamente questo

Originariamente inviato da jappilas

il RT ha lo svantaggio di essere ricorsivo (quando un raggio primario colpisce un oggetto, dal punto di intersezione si dipartiranno vari altri raggi, alcuni diretti verso le sorgenti di luce presenti per determinarne l' influenza o meno), e quindi, scarsamente deterministico (non so a priori quanto tempo richiederà il rendering di un frame di un' animazione, a meno di non fissare dei limiti al numero di iterazioni e raggi secondari), ma il vantaggio di inglobare le funzioni di "ordinamento" della geometria (i raggi primari intersecheranno gli oggetti più vicini all' osservatore, che saranno quindi quelli di cui verrà calcolato il colore per il pixel corrente... a meno di trasparenze, nel qual caso genererò dei raggi secondari per il calcolo dell' effetto rifrattivo, ecc ecc)

questo per dire che, per pochi raggi (a che risoluzione andava la demo all' epoca, 320x200? quanti oggetti e fonti di luce c' erano ? io ricordo solo un toroide e uno spot..), nessuna iterazione secondaria, un po' di assembly 386 ben fatto, non trovo così eclatante che quella demo funzionasse su 386 o 486...

no, non era solo un toroide e uno spot, c'erano anche altri oggetti, mi sembra delle sfere... ovvio: era molto semplice, però ti garantisco che per i tempi eclatante lo era comunque... non avevi VPU eh

Originariamente inviato da jappilas

invece, se un algoritmo RT, "esteso" ai canoni odierni ( dotato magari di caratteristiche come la global illumination, oltre alle ormai "banali" ombre portate, riflessioni e trasparenze) riuscisse a girare in tempo reale per una scena tridimensionale generica (invece di una situazione perettamente nota a priori) , lo troverei assai eclatante

certamente, anche se comunque avendo a disposizione gflop nell'ordine delle centinaia se non addirittura del migliaio non me la sentirei comunque di definire la cosa "eclatante"... se vai a vedere il link che ha postato Banus (http://openrt.de/) troverai che con cluster di una decina di athlon 1800+ (mi sembra la versione di q3 in openrt) lo fanno già... e vedendo il tipo di progetto, non penso sia estremamente ottimizzato - senza nulla togliere eh =)

è ovvio che se l'algoritmo RT ha la complessità di quello di un motore di rendering 3d di - che so - un 3d studio max il discorso cambia. però personalmente ho dubbi, anche perchè non ha nessuna utilità: dato che per tutta una serie di effetti puoi usare dei "trucchetti" (guarda ad es. la demo sul sito della ATI delle sfere che riflettono / distorcono) che ottengono effetti analoghi ad un costo computazionale estremamente ridotto, è meglio abbondare con questi e ridurre algoritmi particolarmente onerosi (anche perchè come giustamente sottolineavi sono del peggior tipo: non hanno un tempo di esecuzione determinato a priori) come questi solo laddove dove veramente non se ne può fare a meno...

[fantoibed]

Sono sicuro che fek sa tutto di Cell, ma se in moltissimi siti si paragona il Cell ad una GPU (come anche qui:http://www.igeek.com/CellProcessor.pdf), uno è portato a crederci. E' ovvio che le attuali GPU possono effettuare operazioni dedicate più complesse, ma è anche vero che sono stati introdotti shader programmabili e che quindi esiste uno sforzo per renderle più versatili e pensavo a Cell come ad una sorta di "estremizzazione" di questo concetto.
Comunque prendo atto che ho preso una cantonata.

[Fx]

no, non è che hai preso una cantonata, è solo che c'è molta confusione in merito al cell... le GPU come giustamente dici si sono spostate un po', con gli shader programmabili, verso il general purpose (da prendersi con le pinze eh non è che adesso SONO general purpose, sono solo più flessibili rispetto a un tempo)... tuttavia non solo questo sono, e per il resto sono altamente ottimizzate per il loro campo. il cell invece è più flessibile, e farà bene più cose, anche se non sarà così bravo come le gpu a fare ciò per cui esse sono progettate, il che tuttavia non esclude che in alcuni aspetti specifici le possa battere.

comunque il concetto è chiaro: da una parte hai la flessibilità e dall'altra parte hai le performance assolute, più hai un hardware specifico più sarà bravo a fare quello per cui è progettato (e più sarà un disastro a fare il resto ) - ad esempio una GPU - più invece hai un hardware flessibile più questo offrirà performance ridotte (rispetto a un hardware specifico, non in assoluto) ma a 360° - le CPU. il cell si colloca nel mezzo, da come lo vedo io anzi più tendente ad un hardware specifico e più precisamente nella categoria VPU / stream processor / DSP... come ho già detto il cell io lo vederei particolarmente bene dentro a un pc, ma non in sostituzione della cpu o della gpu, bensì in COMPLETAMENTO alle due... anche se sono dell'opinione che difficilmente lo vedremo mai nei pc, più facilmente vedremo processori con caratteristiche analoghe: il prossimo passo, imho, è quello

[Banus]

Originariamente inviato da Fx

se vai a vedere il link che ha postato Banus (http://openrt.de/) troverai che con cluster di una decina di athlon 1800+ (mi sembra la versione di q3 in openrt) lo fanno già... e vedendo il tipo di progetto, non penso sia estremamente ottimizzato - senza nulla togliere eh =)

E già in quel caso sono usate ottimizzazioni abbastanza sofisticate, che sfruttano ad esempio la coerenza tra frames
Se si dovesse disegnare una scena usando uno degli ultimi renderizzatori (esempio, Mental Ray o Messiah), considerando che su un PC normale impiegano 20 minuti per oggetti semplici, servirebbero circa 30 Tflops per un'animazione realtime
Può darsi che nelle nuove console, grazie al quantitativo generoso di Gflops, qualche parte della scena sia disegnata con raytracing o raycasting (esempio, superficie dell'acqua), ma difficilmente tutta la scena sarà in raytracing, anche perchè costringerebbe a ripensare completamente la pipeline di rendering.

[fantoibed]

E' un po' OOT (out of thread), ma siccome se ne parlava, vi segnalo questo link:
http://www.gpgpu.org/
dedicato all'utilizzo General Purpose delle GPU.

[Fx]

non mi sembra sia ot, ti segnalo anche questo (mi sembra sia già stato postato in questo topic):

http://graphics.stanford.edu/project...gpu/index.html

il problema è che ovviamente se le usi davvero per impieghi general purpose (che so, office) fanno schifo: la cosa diventa interessante invece se le sfrutti per fare operazioni in cui sono brave, quindi ad esempio alcuni casi di calcolo vettoriale... la chiave è sfruttare sempre l'hardware specifico a fare ciò che è bravo a fare =)

Banus: si, ma mental ray o messiah danno anche una qualità diversa dell'immagine =) ripeto, con tutto rispetto per il progetto eh, ma l'idea che mi sono fatto è che più che avere ottimizzazioni spinte abbiano ridotto una serie di parametri e una serie di feature rispetto a un motore di rendering di ultima generazione... imho se ci si mettono le software house grosse, soprattutto se si parla di console, si vedrà spremere per benino l'hardware

ps: per curiosità, hai visto le demo della ATI?

[fek]

Originariamente inviato da fantoibed

Sono sicuro che fek sa tutto di Cell, ma se in moltissimi siti si paragona il Cell ad una GPU (come anche qui:http://www.igeek.com/CellProcessor.pdf), uno è portato a crederci.

In realta' so' davvero poco sul Cell, sono decisamente piu' ferrato sulle GPU. E capisco che sia facile confondere il Cell con una GPU, soprattutto per le innumerevoli errate informazioni che si trovano in giro per la rete.

E' molto bello invece che si sia potuto sviscerare l'argomento qui con molta calma, nonostante la mia indefessa vis polemica che un bel giorno imparero' a tener fuori dalle discussioni , ed e' molto bello che tu ti possa essere chiarito le idee proprio per mezzo di questa discussione.

E' anche molto bello che nessuno si sia accorto di un paio di idiozie che ho scritto

Originariamente inviato da Fx

il problema è che ovviamente se le usi davvero per impieghi general purpose (che so, office) fanno schifo: la cosa diventa interessante invece se le sfrutti per fare operazioni in cui sono brave, quindi ad esempio alcuni casi di calcolo vettoriale... la chiave è sfruttare sempre l'hardware specifico a fare ciò che è bravo a fare =)

Sull'ultimo GPU Gems di NVIDIA (http://developer.nvidia.com/object/gpu_gems_2_home.html) c'e' un intero capitolo dedicato all'uso della GPU per calcoli general puropose.

Questi sono alcuni esempi, che spaziano dalla fisica al campo finanziario:

Options Pricing on the GPU
Craig Kolb and Matt Pharr (NVIDIA Corporation)

Improved GPU Sorting
Peter Kipfer and Rüdiger Westermann (Technische Universität München)

Flow Simulation with Complex Boundaries
Wei Li (Siemens Corporate Research), Zhe Fan, Xiaoming Wei, and Arie Kaufman (Stony Brook University)

Medical Image Reconstruction with the FFT
Thilaka Sumanaweera and Donald Liu (Siemens Medical Solutions USA, Inc.)

[fantoibed]

Sarebbe bello però sviscerare un po' anche la tecnologia Altivec (ed il SIMD in genere).
Qui ho trovato l' AltiVec Technology Programming Interface Manual :
http://www.freescale.com/files/32bit...ALTIVECPIM.pdf.

Prendiamo ad esempio un'istruzione come vec_msum:

- For Multiply Sum of Sixteen 8-bit elements
do i=0 to 3
di <- (a4i * b4i) + (a4i+1 * b4i+1) + (a4i+2 * b4i+2) + (a4i+3 * b4i+3) +ci
end
- For Multiply Sum of Eight 16-bit elements
do i=0 to 3
di <- (a2i * b2i) + (a2i+1 * b2i+1) +ci
end

In pratica viene effettuata con un'unica istruzione Altivec una lunghissima serie di moltiplicazioni e somme che in un'unità SISD impiegherebbe decine e decine di cicli di clock!
Le GPU saranno in grado di eseguire molti più calcoli in un colpo di clock, ma rispetto ad un core x86 liscio (trascurando MMX,SSE,3DNow, ecc..) la differenza è sostanziale. Non dico che sia meglio o peggio, ma semplicemente diverso come concezione. Se non è simile alle GPU (per concezione, non per prestazioni), si potrà dire che è simile ad un DSP almeno, o no?
Almeno da quanto si legge (e fin qui pare che tutti i siti siano concordi) le unità SPE dovrebbero eseguire esclusivamente operazioni vettoriali e quindi non sono paragonabili certo ad una CPU tradizionale. Il paragone con i DSP, almeno, è calzante oppure no?
Le SPE, poi, non si sa nemmeno esattamente se utilizzeranno un'evoluzione delle Altivec o un'ISA ancora diversa (e più complessa)...

[fek]

Originariamente inviato da fantoibed

Le GPU saranno in grado di eseguire molti più calcoli in un colpo di clock, ma rispetto ad un core x86 liscio (trascurando MMX,SSE,3DNow, ecc..) la differenza è sostanziale. Non dico che sia meglio o peggio, ma semplicemente diverso come concezione. Se non è simile alle GPU (per concezione, non per prestazioni), si potrà dire che è simile ad un DSP almeno, o no?

Beh, l'Altivec e' l'equivalente delle istruzioni SSE.

Almeno da quanto si legge (e fin qui pare che tutti i siti siano concordi) le unità SPE dovrebbero eseguire esclusivamente operazioni vettoriali e quindi non sono paragonabili certo ad una CPU tradizionale. Il paragone con i DSP, almeno, è calzante oppure no?

E' molto calzante. L'SPE e' di fatto uno DSP.

[Criceto]

Originariamente inviato da Fx

non mi sembra sia ot, ti segnalo anche questo (mi sembra sia già stato postato in questo topic):

http://graphics.stanford.edu/project...gpu/index.html

il problema è che ovviamente se le usi davvero per impieghi general purpose (che so, office) fanno schifo: la cosa diventa interessante invece se le sfrutti per fare operazioni in cui sono brave, quindi ad esempio alcuni casi di calcolo vettoriale... la chiave è sfruttare sempre l'hardware specifico a fare ciò che è bravo a fare =)

Beh il nuovo Tiger di Apple usa la GPU per il nuovo core-graphics e core-video. Non ho capito bene se la usa anche per il decoding dell'H264 in Quicktime e in core-audio, ma insomma le potenzialità sono impressionanti.

E' però interessante il fatto che quei frameworks non sono mappati ad una singola GPU o addirittura tecnologia: se non non si dispone di GPU programmabile quegli algoritmi vengono svolti da Altivec, certo con una velocità molto inferiore... ma insomma: l'effetto "goccia nello stagno" che era un classico dei demo del core-graphics, riesce a farlo anche il mio iBook G4 che non dispone di una GPU programmabile...

Portare queste tecnologie anche su Cell non sembrerebbe quindi difficile per Apple, anzi sembrano già predisposte...

[Criceto]

Originariamente inviato da fantoibed

Le SPE, poi, non si sa nemmeno esattamente se utilizzeranno un'evoluzione delle Altivec o un'ISA ancora diversa (e più complessa)...

A quanto pare un superset di Altivec. Ma attenzione, le SPE sono veri e propri processori indipendenti, completi anche di memoria locale, non sono solo unità vettoriali come Altivec o le MMX.

[fek]

Originariamente inviato da Criceto

A quanto pare un superset di Altivec. Ma attenzione, le SPE sono veri e propri processori indipendenti, completi anche di memoria locale, non sono solo unità vettoriali come Altivec o le MMX.

No, le SPE non sono processori indipendenti, non hanno alcuna interfaccia verso l'esterno (e' una scelta), la memoria locale dev'essere riempita in DMA dal coordinatore. L'SPE non e' in grado di interfacciarsi al mondo esterno e prelevare istruzioni e dati, senza un coordinatore siederebbe all'infinito senza fare nulla, infatti non e' indipendente, per scelta e' una semplice unita' vettoriale in grado di processare molto velocemente stream di dati.

[fantoibed]

Originariamente inviato da fek

No, le SPE non sono processori indipendenti, non hanno alcuna interfaccia verso l'esterno (e' una scelta), la memoria locale dev'essere riempita in DMA dal coordinatore.
L'SPE non e' in grado di interfacciarsi al mondo esterno e prelevare istruzioni e dati, senza un coordinatore siederebbe all'infinito senza fare nulla, infatti non e' indipendente, per scelta e' una semplice unita' vettoriale in grado di processare molto velocemente stream di dati.

Sicuro che non hanno un'interfaccia verso l'esterno?
Io ho letto che ogni SPE può accedere all'EIB (Element Interconnect Bus) e scambiare dati con le unità SPE adiacenti (per accedere a quelle non adiacenti bisogna impostare le SPE intermedie in modalità "ripetitore"). Uno dei vantaggi accreditati alle SPE è quello di poter essere utilizzate in parallelo o in serie.

[fek]

Originariamente inviato da fantoibed

Sicuro che non hanno un'interfaccia verso l'esterno?

Se non ho detto una scemenza, si', non hanno interfaccia verso la memoria centrale per prelevare dati e istruzioni, e questo fa parte del design, di modo da avere un modello di latenze costante per semplificare il progetto.

In pratica non posso teoricamente prendere un SPE, attaccarlo ad un bus e fargli fare il fetch di dati e istruzioni dalla memoria centrale, perche' non ha alcuna logica per questo compito, puo' solo prelevare dalla sua memoria privata che viene riempita dal controllore via DMA.

[Fx]

Originariamente inviato da Criceto

Beh il nuovo Tiger di Apple usa la GPU per il nuovo core-graphics e core-video. Non ho capito bene se la usa anche per il decoding dell'H264 in Quicktime e in core-audio, ma insomma le potenzialità sono impressionanti.

E' però interessante il fatto che quei frameworks non sono mappati ad una singola GPU o addirittura tecnologia: se non non si dispone di GPU programmabile quegli algoritmi vengono svolti da Altivec, certo con una velocità molto inferiore... ma insomma: l'effetto "goccia nello stagno" che era un classico dei demo del core-graphics, riesce a farlo anche il mio iBook G4 che non dispone di una GPU programmabile...

Portare queste tecnologie anche su Cell non sembrerebbe quindi difficile per Apple, anzi sembrano già predisposte...

criceto, sei un confusionario esagerato

core video e core image sono un framework che sfrutta la scheda video a far cosa? indovina un po'? a elaborare immagini. gli "effetti" che vengono applicati sono la stessa cosa di ciò che si vedeva da tempo in una serie di giochi, di bench, di demo ma portato su un uso completamente diverso.

di fatto core video e image usano la GPU a far quello in cui è brava, per questo il risultato è proficuo: lo stesso effetto elaborato dalla CPU (tra l'altro: si parla di cpu che hanno altivec) impiega più tempo.

premesso questo non capisco:
a) perchè sono "predisposte" per il porting su cell? sono più "predisposte" per un porting su x86, se per quello, le gpu sono le stesse =)
b) perchè mai dovrebbero usare il cell e non la gpu a fianco al cell?