Newsgroup: it.fan.studio-vit
Titolo: Arrivo sempre tardi, ma...

A< 

Sulla carta
Emotion engine.
Papero

A< 

 Cell
così, secondo me, l'intervento di Papero era lievemente ironico e andava
letto in senso: "si, sticazzi, anche l'emotion engine ci venne propinato
come la meraviglia delle meraviglie. invece era come la falqui"
ma magari la mia è solo la supponenza dell'uomo di mondo che cede alla
spocchiosità
cmq il cell sembra ottimo. il valore spec dichiarato indica le capacità di
calcolo a precisione singola, quella che non serve quasi ad un cazzo al
giorno d'oggi, ma in generale il tutto dovrebbe spaccare il culo ad un x86
in scioltezza.
ovviamente non sarà così.
ecco un articolo interessante, sebbene un pò ostico. servirebbe l'aiuto di
tumeo in più di un punto.
http://www.realworldtech.com/page.cfm?ArticleID=RWT021005084318
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

A< 

letto 
Mi stupisco negativamente di te, maestro... :|
--
Tanto le pagate tutte.

 
http://www.realworldtech.com/page.cfm?ArticleID=RWT021005084318
Articolo molto bello e completo (sicuramente il piщ completo e chiaro 
uscito fino ad adesso sul web).
Diciamo che, in breve si tratta di un'architettura abbastanza 
innovativa, che comunque va verso quelle direzioni che si stanno 
seguendo oggi.
La caratteristica principale sono, naturalmente, le 8 SPE (Synergistic 
Processing Element), che sono in tutto e per tutto dei piccoli 
"sistemini" indipendenti costituiti da delle relativamente semplici CPU 
RISC e da 256 KB di memoria locale (non cache, и proprio memoria "on 
die" indirizzabile in tutto e per tutto come RAM).
Il core delle SPE come detto sopra и relativamente semplice: si tratta 
di CPU dual issue (cioи in grado di lanciare, in parallelo, al massimo 
due istruzioni, lungo due pipeline diverse) ma in ordine, caratterizzate 
da unitа di esecuzione vettoriali in grado di eseguire un picco di 8 
operazioni (4 FMADD - Full Procision Multiply and Accumulate) per ciclo 
di clock, eseguite su vettori di 128 bit ciascuno (cioи quattro valori 
in virgola mobile da 32 bit, ossia in full precision) ed accompagnate 
naturalmente dai relativi 128 registri da 128 bit. E' comunque anche 
possibile eseguire operazioni in doppia precisione con passate 
successive (naturalmente le prestazioni decrescono).
Manca invece del tutto la logica di predecodifica tipica delle attuali 
architetture (prefetch delle istruzioni, non и un caso se non c'и cache, 
e brach prediction...). In buona sostanza, ciт significa che, data anche 
la natura di esecuzione in-ordine, l'ottimizzazione e la 
parallelizzazione del codice (a livello di istruzioni) и deputata in 
TUTTO e per TUTTO al compilatore, che naturalmente sarа proprietario 
visto che il set di istruzioni delle SPU и nuovo.
A monte di tutto questo c'и invece una CPU basata sul set di istruzioni 
Power con unitа vettoriale VMX e supporto simultaneous multithreading 
(SMT: come sui P4 и possibile avere in esecuzione due thread alla 
volta), questa dotata di cache (512 KB di 2L) ma anche qua abbiamo 
ancora una pipeline con issue delle istruzioni in ordine (non 
necessariamente un male, ma quantomeno dunque di concessione non 
"ultramoderna": anche in questo caso si и preferito semplificare per 
raggiungere frequenze di clock molto piщ alte).
il tutto и "riunito" da un bus di connessione ad anello (4 anelli 
concentrici da 128 bit ciascuno, in veritа) che unisce una SPE con la 
successiva e confluisce verso due moduli di input/output: quello per la 
memoria (di tipo XDR, vi risparmio i dettagli sul bus, su due canali da 
8 bit ciascuno, per un totale di circa 25 GB) e il FlexIO, destinato 
alla connessione con altre unitа (anche qua, risparmio i dettagli sul 
bus, e dico solo che fornisce una banda in downstream di circa 44 GB e 
di 32GB in upstrea, per un totale di 76 GB). Il tutto, fornisce un 
totale di circa 100 GB/s di banda a CELL.
Nell'articolo (e nei paper) viene sottolineato anche l'utilizzo di 
logica dinamica (dove si sfruttano le capacitа parassite dei transistor 
come strumenti di memorizzazione, piuttosto che pensarle come "problemi" 
da superare), in controtendenza rispetto alle attuali pratiche (visto 
che sembrava cosa sempre piщ difficile da sfruttare con geometrie sempre 
piщ piccole), di 12 domini di alimentazione diversa (cioи, 12 diverse 
linee di "alimentazione" separate) e una decisa attenzione alle 
problematiche di controllo della temperatura.
Indubbiamente un'architettura interessante, si pongono perт diversi 
"problemi" di sfruttamento. In primo luogo, la necessitа giа evidenziata 
di compilatori che si prendano carico dell'ottimizzazione dei programmi 
a livello di ordinamento delle istruzioni, perchи si possa solo pensare 
di avere "efficienza". In secondo luogo, la necessitа di programmare 
pensando in "maniera" parallela: naturalmente le massime prestazioni 
computazionali possono essere raggiunte solamente avendo in "esecuzione" 
un thread su tutte le unitа (il modello probabilmente sarа che il Power 
"distribuisce" le varie sottofunzioni che possono procedere in parallelo 
alle varie SPE e manderа richieste con parametri a quel punto pensando 
solo di ottenere i risultati). Perт, trovare piщ flussi di esecuzione 
"paralleli" in un unico programma non и semplice (di solito sono le 
applicazioni "scientifiche", guarda un po', ma anche quelle PURAMENTE 
grafiche quelle massivamente parallelizzabili...) e di solito ci sono 
parti (anche abbondanti) che non possono proprio essere parallelizzate, 
e sono curioso di vedere bene come sarа gestito questo discorso (perchи 
sto cominciando a credere da come sono organizzate le cose che piщ che 
veri e propri thread sulle varie unitа ci saranno in esecuzione veri e 
propri processi proprio "lascamente" accoppiati tra loro, altrimenti il 
sistema operativo e i compilatori a monte si dovrebbe prendere carico di 
individuazione di parallelismo e di speculazione a livello di thread che 
non sono proprio cosa elementare...). Sembra piuttosto adatta ad 
elaborare dati di tipo multimediali (con dati che entrano ed escono 
dalle unitа modificati ma sostanzialmente nello stesso numero e dello 
stesso tipo), in effetti (del resto lo chiamano stream processor mica 
per niente), lasciando ad esempio (tipo negli algoritmi di compressione) 
che ciascuna unitа effettui una parte delle operazioni passando poi i 
dati ottenuti alle succesive per le altre elaborazioni.
Sarebbe stata una buona architettura se avesse dovuto per esempio 
elaborare vertici :D, ma a quel livello diciamo che giа sui due 200 
GFlop (che comunque ROTFL... sia in questo caso che con il CELL sono 
calcolati come prestazioni di punta ovviamente moltiplicando numero di 
operazioni per ciclo di clock per il numero di unitа per la frequeza :D, 
praticamente cosa che non sarа quasi mai ottenibile) ci arrivano le 
attuali schede grafiche, volendo (chissа perchи il chip grafico di PS3 
sarа un'unitа a se stante... :D )...
Problematica sembra essere anche la banda a disposizione: и vero che 100 
GB sembrano "tantissimi", ma per la memoria sono a disposizione di 
questi solo 1/4, 25 GB. Sempre tanti, sicuramente, rispetto a qualsiasi 
altra soluzione oggi vista, ma questi 25 GB devono rifornire 9 unitа (e 
10 thread, ricordate che il Power и SMT) e magicamente si arriva, per 
ciascun core, a piщ normali numeri tra i 2 e i 3 GB di banda per unitа 
che vanno a oltre 4 GHz, richiedono codice molto ottimizzato e non fanno 
prefetch di istruzioni, motivo per cui ci sono  - le memorie - (e non 
cache) locali.
In buona sostanza, architettura potenzialmente sм molto interessante e 
assolutamente intrigante, ma almeno al momento (non sapendo tool, 
compilatori e quant'altro, che saranno importanti per lo sfruttamento 
commerciale) non giudicabile appieno. Chi vivrа vedrа, e auguri a quelli 
che su di essa ci svilupperanno, comunque...
Questo и quanto mi viene in mente da dire al momento....

spocchiosità
Ruotfl, no, no.
È che le stime ufficiali sono veramente l'amo per i pesci.
Papero

 suggerì:

Ruotfl, Pisellonio.
Usato come aggettivo, proprio.
Papero

Era una notte buia? Era tempestosa? Fattostà che il Wed, 16 Feb 2005
18:05:49 +0000, Papero <paper...@NONOkaiba.cc> scrisse:

Mannò, che Pisellonio magari ti stima anche... :D


Mannò, che Pisellonio magari ti stima anche... :D
Ahahahaha, tutti a rischio brillio, eh?
Papero