Newsgroup: it.comp.hardware.cpu
Titolo: Aprite la mente

Purtroppo l'articolo è in inglese ma non posso resistere dal non postarlo! 
Sembra di rileggermi ahahah!! :-)))
http://www.blachford.info/computer/Cells/Cell4.html

 
http://www.blachford.info/computer/Cells/Cell4.html
L'intero articolo può essere letto da quà: 
http://www.blachford.info/computer/Cells/Cell1.html
Che dire a me sembra l'uovo di Colombo! Una specie di TCP/IP ad altissima 
velocità tra singole unità vettoriali che si possono agiungere e rimuovere, 
il massimo della flessibilità con il minimo sforzo, IMHO la semplicità del 
design delle APU e l'alta velocità del bus sono il suo vero punto di forza, 
il tutto governato da un simil PowerPC G5 ;-))) 



ha l'aria di essere un incubo per i programmatori...
-- 
    (iao!!oai)                                    (ICQ: 10860566)
    //.aurizio
[WARNING!: togliete _nessuno_ per rispondere]
    Coloro che sono disposti a farsi togliere alcune liberta' 
essenziali per ottenere un piccolo, temporaneo senso di sicurezza
non meritano ne liberta' ne sicurezza. [B. Franklin]

 ha l'aria di essere un incubo per i programmatori...
Guarda credo ci girino benissimo anche i programmi compilati 
tradizionalmente, alla fine c'è un PowerPC da controllore.. ovvio che per 
sfruttare bene le varie APU ed ottenere il boost devo vettorializzare al 
massimo il codice ;-)
Calcola che a parte l'uso intensivo di database  tutti i problemi possono 
essere vettorializzati, a partire dai codec audio/video passando per i 
programmi di grafica 2d tipo photoshop per l'applicazione di filtri ed 
effetti in realtime e quelli 3d per il raytracing, arrivando fino a problemi 
di natura scientifica e ricerca in generale, per esempio lo studio di 
particolari forme d'onda, etc etc...
Anche i motori dei videogiochi se opportunamente studiati possono trarre un 
enorme beneficio da questo approccio e già con le prox cpu dual core di 
intel/amd ce ne accorgeremo ;-) ormai il dado è tratto e non sarà solo per 
la comparsa di 'Cell' che si standardizeranno le nuove metodoligie di 
programmazione.
Nell'ambito dei supercomputer per esempio tali tecniche sono standard da 
anni e i programmi sono in grado da soli di trarre ventaggio dall'aggiunta 
di una o più unità di calcolo ;-)


la questione non e' il parallelismo, ma quello che l'articolista
chiama "concrete processing" - ogni cella software deve essere scritta
a bassissimo livello e bisogna studiarla perfettamente per ottimizzare
la suddivisione in blocchi di 128kb - dato l'approccio a memoria fissa
non virtualizzata le apu non possono uscire dalla propria memoria
residente ed accedere alla memoria del computer.
insomma, un approccio molto contorto e complesso da gestire, per
quanto estremamente performante.



Occhio a quel che viene ripetuto anche nell'indice iniziale:
http://www.blachford.info/computer/Cells/Cell0.html
Si tratta di un analisi basata principalmente sui brevetti registrati, non
su dati tecnici "definitivi" dei produttori di Cell.
Teoricamente e' un bell'aggeggio (lo si potrebbe definire il nipote
dell'Amiga, che aveva coprocessori su piu chip "programmabili"
usando il DMA controller).
L'idea di base e' che invece di avere coprocessori specializzati
(GPU, SPU, unita SIMD sulla cpu, ecc. ecc.) e' molto meglio avere
tanti coprocessori semplici con una ram locale (anche se e' piu
simile ad una cache 1-way ultra-semplificata) in modo tale
da ridurre il carico sulla cpu spostandolo sui coprocessori
(o per meglio dire, sugli stream processors).
Il problema e' che la vedo dura per quel che riguarda "applicazioni
normali ricompilate", il compilatore o il sistema di compilazione JIT
devono essere in grado di sfruttare bene le APU, perche le prestazioni
effettive dipendono in larga parte con quanta efficienza un programma
viene scomposto in APUlet.
Il PU e' si un simil-G5 a 64bit, esso puo essere usato anche per far
girare software "vecchio" oppure "mal APUletizzabile", ma se si vogliono
le fantasmagoriche prestazioni di picco bisogna caricare al 100% le APU.
Sulla PS3, per quanto riguarda grafica e video lo vedo bene
lo stesso per quel che riguarda applicazioni tipo codifica/decodifica
(hardware per lettori/registratori Blue-Ray ad esempio, vi immaginate
  una cpu capace di codifica/decodifica MPEG4 su piu canali?)
e simili (male che vada qualcuno ottimizzera' a mano il codice).
Ma se si tratta di portarci sopra Linux oppure Windows CE e di farci
girare applicazioni "normali" scritte in C/C++, le prestazioni reali
in applicazioni "normali" dipenderanno molto dalle prestazioni del
"simil-G5" e del compilatore di APUlet,piu altri dettagli che potrebbero
fare una differenza notevole ma che per ora non sono chiari
(es: e' possibile che un task rilasci il PU ma mantenga il controllo di
      alcune APU in modo da permettere una sorta di multithreading anche a
      livello delle APU?).
Notare che anche Intel o AMD possono seguire la stessa strada del Cell;
basterebbe "rinunciare" al dual core ed usare lo spazio del secondo
processore per implementare la "APU farm" ("allevamento di APU"), oppure
implementare la "APU farm" sul northbridge, oppure usare lo stesso pinout
degli Opteron per implementare delle super-APU-farm (una scheda madre
Socket940 quadriprocessore con un Opteron e tre chip "APU farm", oppure
due Opteron e due chip "APU farm").
L. Micheletto

L. Micheletto


 stabilite come quella x86 d'altra parte.
Anche volendo.. sarebbe una rincorsa inutile, società del calibro di IBM, 
SONY e Toshiba non stanno certo a guardare dopo aver investito tutti quei 
soldi :-) 


la wikipedia ha un discreto riassunto:
http://en.wikipedia.org/wiki/INMOS_Transputer


 soldi :-) 
Ma sia Intel che AMD possono sfruttare a loro favore l'inerzia
del settore degli x86 ed avere il tempo necessario per uscire con
il loro Cellx86 prima che sia troppo tardi.
L. Micheletto

 quanto estremamente performante.
Ho riletto per benino questa parte e concordo che il lavoro da fare per 
sfruttare per bene le potenzialità del mostriciattolo è arduo sopratutto per 
i porting di software già esistenti :-(
Se invece si tratta, come IMHO sarà nella stragrande maggioranza dei casi, 
di svilupparre da ZERO nuovi algoritmi/applicativi.. beh allora sarà 
tutt'altra musica qiella che sentiremo ;-)
Ovvio che per i programmatori non sarà un gioco.. ma IMHO tutto dipenderà 
dalla loro capacità di 'APRIRE LA MENTE' ed uscire dai classsici schemi da 
cui il itolo del mio post ;-)
Alla fine sviluppare routine/funzioni di soli 128KB (tra codice e dati) per 
l'esecuzione praticamente realtime della stesse non è impresa così ardua! 
L'impegno profuso sarà di certo ampiamente ripaganto.