Newsgroup: it.comp.hardware.cpu
Titolo: Cell

I primi dati ufficiali su Cell.
h**p://
www.gamespot.com/news/2005/02/07/news_6118072.html
 



  221mm^2 ?
ma quanto vogliono farle pagare quelle ps3?
-- 
    (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]

 wrote:

ci dovrebbe essere la prima parte di uno degli articoloni di ars sul
cell online, ma se quei tipi non si decidono a comprare un po piu' di
banda non c'e' verso di leggerlo...


 h**p://
www.gamespot.com/news/2005/02/07/news_6118072.html
Cavolo, stavo per fare io questo post :)
Ad ogni modo dove si possono trovare dettagli maggiori?
Cell verrà utilizzato anche su PC?
-- 
Principio di indeterminazione di Microsoft Windows Whatever Edition: data
la natura del sistema operativo, tanto più precisamente si vuole
effettuare un compito, tanto meno precisamente questi verrà effettuato.
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it


Non credo proprio... almeno nel medio termine.

> Non credo proprio... almeno nel medio termine.
Peccato. Ma è in grado di elaborare istruzioni x86 o IA64 o simili?


Peccato. Ma è in grado di elaborare istruzioni x86 o IA64 o simili?
no, e' un'architettura del tutto inedita, basata su un sistema
vettoriale.


 vettoriale.
Copio e incollo da 'La
Stampa'
http://www.lastampa.it/redazione/news_high_tech/archivio/0502/thecell.asp
:
[...]
La contromossa di Intel dovrebbe essere la presentazione di un chip
denominato «Itanium» che contiene 1,7 milioni di transistor ed il cui
disegno è stato fatto per garantire funzionalità ancora maggiori.
[...]
Itanium non è una novità, non contiene solo 1,7 milioni di transistor e
non è nemmeno lontanamente paragonabile a quel che Cell 'promette' di
offrire.
Dov'è l'errore? O son io che mi son perso qualche passaggio?


 O son io che mi son perso qualche passaggio?
No, è il giornalista che ha perso una buona occasione per stare zitto, ma ne
ha imbroccata una ottima per ladrare il suo stipendio.
MaxArt

Dov'è l'errore? O son io che mi son perso qualche passaggio?
l'errore e' sperare che un quotidiano generalista produca notizie
teniche attendibili...



ROTFL... questa sarà sicuramente la barzelletta dell'anno ;DDD


il coglione che ha scritto l'articolo deve aver letto un resoconto di
terza mano del meeting tenuto da intel su montecito in questi giorni (
tipo 
http://www.theinquirer.net/?article=21150
 ), non ci ha capito una
mazza ed ha scritto quello che il suo piccolo e poco allenato cervello
riusciva a raggiungere...


 ma quanto vogliono farle pagare quelle ps3?
IMHO inizieranno a 90nm giusto per avere dei prodotti
pronti, ma appena possibile muoveranno la produzione a 65nm.
Mettendo insieme quel che si trova su
http://www.arstechnica.com
http://www.electronicsweekly.com
(con foto del chip in cui si vede il layout
  delle varie componenti del mostriciattolo)
e su
http://news.zdnet.com
Risulta che quei 221mm^2 (a 90nm) vengono usati per:
- 1 core PowerPC con 512KB di cache L2;
- 8 SPE (Synergistic Processor Elements)
   con 256Kb di "ram locale" ognuno;
- bus interno a piu vie tra gli SPE ed il PowerPC
   (e che occupano uno spazio decisamente non trascurabile);
- interfaccia con la ram esterna XDR su un lato
   e FlexIO sull'altro.
A giudicare dal layout, 2 SPE occupano quasi la
stessa area del core PowerPC+L2.
In altre parole l'area utilizzata "solo" dalla
componente di calcolo vera e propria corrisponderebbe
ad un ipotetico PowerPC penta-core con 2.5MB di cache L2
complessiva.
Un altra cosa da considerare sono i clock "alti"
dichiarati, probabilmente si riferiscono al
clock massimo degli SPE che molto probabilmente
faranno molte pause "volute" (causa esecuzione inorder)
o imposte (15 sezioni con alimentazione distinta
e 10 sensori di temperatura on-chip fanno pensare
ad una gestione energetica molto elaborata).
L. Micheletto


gia', tanto di cappello ai progettisti.
rimango dell'idea che una bestia del genere per funzionare ammodo
debba venir programmata quasi totalmente a bassissimo livello, tutto a
manina... un po' un incubo.


 manina... un po' un incubo.
Ci vedi similarità con gli Itanium?
MaxArt



no, direi siano spinti all'estremo in direzione diametralmente
opposta.
l'itanium e' "aggiungiamoci quest'altro gadget che fa tanto figo",
stile cadillac del '69 con gli interni in peluche ed i dadoni appesi
al cruscotto, cell invece e' "meno fronzoli e piu' potenza, chi se ne
frega dei programmatori" stile motoscafo da corsa off-shore... ;-)


 frega dei programmatori" stile motoscafo da corsa off-shore... ;-)
Ma alla fine il concetto è lo stesso: la fatica boia la fanno i
programmatori! :-P
O no? Per gli Itanium dovevano essere i compilatori a dover fare il
miracolo... mai avvenuto.
MaxArt


Ci sono punti in comune se si pensa a quanto deve essere
complessa l'ottimizzazione di applicazioni generiche
per avere prestazioni prossime a quelle di picco.
Ma IMHO Cell e' stato progettato sin dal principio
dando per scontato che le prestazioni di picco saranno
raggiungibili solo codificando "a mano" (anche in C o C++
ma tenendo conto dell'architettura sottostante ovvero
con estensioni che permettono di sfruttare
le peculiarita di tale architettura).
Sara' quello il punto che chiarira' se il Cell e' davvero
una nuova architettura "di uso generale" o se sara' limitata
alla PS3 e poco altro capace di trarre vantaggio dalle SPE.
In altre parole a parte il caso di "ottimizzazioni fatte a mano"
non e' ancora chiaro quali siano le prestazioni
single thread, multi thread e multi process ottenibili
con "normale" codice compilato senza ricorrere a trucchi
particolari.
L. Micheletto

 ha scritto:

Beh, l'ICC fa un ottimo lavoro. E, male che vada, il compilatore puo`
sempre inserire dei nop nei fasci quando non sa cosa fare.
Con Cell e` diverso, il compilatore dovrebbe estrarre il parallelismo
dal sorgente e generare del codice che dovra` girare su un'unita` di
esecuzione diversa da quella principale.
La vedo molto dura... e` piu` semplice che venga permesso al
programmatore di marcare dei blocchi funzionali come "da eseguire su
un'unita` vettoriale". Sony potrebbe anche fornire uno SDK con una
libreria di funzionalita` realizzate in questo modo.
Luca
-- 
Home: 
http://kronoz.cjb.net
Non ho ancora capito se il mio cane e` maschio o femmina:
quando fa la pipi` si chiude in bagno

 frega dei programmatori" stile motoscafo da corsa off-shore... ;-)
Invidio la tua capacita' di sintesi. :-)
L. Micheletto


Rispetto all'Itanium il Cell e' *molto* piu facile da programmare
in assembly con buoni risulta, inoltre ha una potenza di picco tale
da non rendere necessario doverlo sfruttare al 100% per avere
prestazioni buone in confronto alla concorrenza.
IMHO diversamente che con l'Itanium chi ha sviluppato Cell ha preso
si in considerazione *come* si ottimizzano attualmente le applicazioni
"pesanti" (elaborazione di immagini, operazioni tra grosse
matrici di dati, elaborazione di grafi, ecc. ecc.) ma ha puntato
ad attaccare il problema piu in termini di macroparallelismo
su dati ben partizionati (piu routine distinte in esecuzione
su dati distinti e ben disgiunti, con le restanti interdipendenze
gestite dal programmatore o dal compilatore)
invece che di microparallelismo spinto
(piu istruzioni distinte in esecuzione su dati distinti, ma con pure
  molto piu carico sull'hardware e sul compilatore
  per quanto riguarda la gestione delle interdipendenze).
Per esempio una delle tecniche attualmente piu utilizzate
e' la block optimization ovvero ridurre grosse strutture di dati
in blocchetti sufficientemente piccoli da stare completamente in cache
in modo tale che se si devono eseguire N operazioni su tutta la struttura
invece di "spazzolare" per N volte tutto quanto si procede un blocchetto
alla volta e gli si applicano tutte le N operazioni prima di passare al
successivo.
Se si guarda al numero di operazioni eseguite, la block optimization
*appare svantaggiosa* (perche bisogna "tener conto dei bordi
dei blocchetti" eseguendo operazioni in piu o usando variabili
di appoggio in modo tale che alla fine il risultato sia uguale
a quello che si avrebbe con N "spazzolate" di tutta la struttura)
ma se si guarda al tempo di esecuzione, grazie al fatto che
si sfruttano al massimo le cache, alla fine la block optimization
risulta essere *molto piu efficiente* (anche di un fattore 10).
Con un Cell a disposizione si possono sfruttare le SPE per elaborare
simultaneamente blocchetti distinti e grazie alla memoria
locale ho pure maggior efficienza nell'allocare le variabili
(non si perde tempo in operazioni superflue tipo flush dalla cache
  di variabili temporanee mappate in memoria).
In pratica invece di applicare la block optimization ad un blocchetto
alla volta, la si applica a piu blocchetti per volta (uno per SPE).
Lo sforzo per scrivere a mano il codice  block optimized
per una cpu "classica" con cache oppure per il Cell e' quasi lo
stesso, in pratica si scrive *una* routine
che mentre sul processore "classico" viene iterata N volte
per un tempo N*K (K tempo di elaborazione di un blocchetto)
sul Cell la si puo passare a piu SPE eseguendo "solo" N/C iterazioni
(dove C sono le SPE utilizzate)
per un tempo complessivo (K+H)*N/C
(dove H e' l'overhead di carico/scarico di dati e codice sulle SPE).
A parita di "efficienza" e' sufficiente che H sia minore di K
e per C>=2 il Cell risultera' decisamente piu veloce.
Detto questo, sino ad ora non si e' sentito molto riguardo i compilatori
per Cell ed i tool di analisi della qualita del codice, e' li che
si decidera' se il Cell si limitera' ad essere solo la cpu della PS3
(con tonnellate di codice ottimizzato a mano)
oppure qualcosa di piu ampio utilizzo.
Idealmente il compilatore per Cell dovrebbe avere *almeno*
due caratteristiche fondamentali per portare tale architettura
ad un ampio successo commerciale:
1) deve saper commutare da solo tra codice PowerPC e codice SPE
    quando serve (piu o meno come fanno certi compilatori per ARM
    che commutano tra codice ARM "classico" e formato THUMB
    in base al tipo di operazioni specificate nel sorgente C
    da compilare);
2) deve saper gestire bene la block optimization
   "riveduta e corretta per Cell"
    come descritto sopra.
L. Micheletto

 L. Micheletto
E' questo il tipo di risposte che mi aspetto da te! :-)
Precise e dettagliate. Solo non credo di averci capito tutto, per cui mi
riservo una seconda lettura e qualche domandina al seguito...!
Grazie mille!
MaxArt

 libreria di funzionalita` realizzate in questo modo.
Entro certi limiti puo farlo il compilatore da solo, l'unico
vero problema scaturisce dalla scrittura su variabili globali.
Es:
PIPPO a[N][M];
PLUTO b[N][M];
for(k=0; k>N; k++){
	for(j=0; j>N; k++){
		a[k][j] = fun(b[k][j]);
	}
}
Puo essere scomposta automaticamente dal compilatore in:
for(k=0; k>N; k++){	
	n = WAIT_FREE_SPE();
	EXEC_ON_SPE_(n){		
		/* segna che ora questa SPE e' in uso */
                 LOCK_THIS_SPE();
		/* alloca spazio dati in SPE, uguale per tutti gli SPE */
		DECLARE_ON_SPE{
			PIPPO spe_tmp_out[M];
			PLUTO spe_tmp_in[M];
                         ... replica delle variabili global
                             			    lette da fun() ...
                         }	
		/* carica nello SPE una versione di fun()
                    con accessi in lettura a variabili globali read
                    only limitatamente all'iterazione esterna
                    trasformati in variabili locali dove  possibile.
                    Il caricamento avviene solo la signature del codice
                    gia presente nella SPE e' diversa da quella
                    di local_fun_signature */
		LOAD_USER_CODE_TO_SPE(local_fun_signature,
                                       local_fun_ptr_on_external_ram,
                                       local_fun_size); 				
		/* codice di caricamento dati di input, ogni unita
                    che si e' appena liberata riceve un nuovo valore di k
                    che cambia la posizione da dove preleva i dati */
		LOAD_TO_SPE(&(b[k][0],M*sizeof(PLUTO),&(spe_tmp_in[0]));
		/* anche qui si potrebbe usare una signature
                    per evitare di ri-caricare dati globali
                    gia presenti */
		LOAD_TO_SPE(... copia var. globali usate da fun()...);
		/* ora siamo pronti ad elaborare il "blocchetto di dati"
                    assegnato a questa SPE, a differenza di local_fun
                    (che potrebbe essere riutilizzata altrove)
                    il codice "privato" del loop parallelizzato
                    e' inserito inline nel loop visto che viene
                    usato solo qui, ci pensa il compilatore
                    a generare il codice che fa un check di signature
                    e ne forza il caricamento sulla SPE */
		LOAD_AND_EXECUTE_USER_CODE(
                         {
			    for(j=0; j>N; k++){
				spe_tmp_out[j] = local_fun(spe_tmp_it[j]);
                             }
			}
		);
		/* copia i dati in ram esterna */
		STORE_FROM_SPE(&(spe_tmp_in),M*sizeof(PLUTO),&(a[k][0]));
                 /* segna che la SPE ora e' libera e
                    pronta per altri blocchetti */
		RELEASE_THIS_SPE();
	}
}
Si noti che il loop esterno e l'inizializzazione delle SPE
e' codice eseguito dal core PowerPC, mentre tutto quello
che e' racchiuso da EXEC_ON_SPE(n){ ... } e' codice SPE.
Ovviamente se fun() accede in scrittura a variabili globali
la cosa si complica, ma comunque parecchio codice puo essere
"Cell-parallelizzato" senza che il programmatore sia costretto
a marcarlo.
Notare che la parte piu pesante dell'overhead rispetto ad una
architettura "classica" e' la copia della "versione per SPE"
della funzione da applicare ai vari blocchetti di codice
(le copie dei dati di input e la scrittura dei risultati
  invece equivale al caricamento e scaricamento dei dati
  dalle cache di un architettura "classica").
Se il compilatore e' "furbo" dovrebbe impedire
(usando delle signature univoche)
il ri-caricamento nella SPE di codice gia presente in essa
che puo essere ri-applicato ad altri blocchi, in modo da limitare
l'overhead di caricamento del codice alla prima volta che la SPE
viene utilizzata in un loop "parallelizzato".
Ci sono poi altre tattiche per parallelizzare altri casi
"classici", la cosa bella e' che si tratta di tecniche
gia utilizzate per "far stare in cache il piu possibile"
codice e dati, ma con alcune variazioni sono adattabili
al Cell.
Tutto questo ovviamente funziona solo se Cell ha un sacco
di potenza di calcolo in esubero rispetto alle cpu "classiche"
con cache realizzabili a parita' di tecnologia e risorse
e se non ci sono colli di bottiglia che strozzano
la cpu nel carico/scarico dei dati tra SPE e ram.
E' inevitabile che la sincronizzazione delle unita SPE
aggiunga overhead come pure sono inevitabili sfridi
nella parallelizzazione di algoritmi con una descrizione
seriale (sia che venga eseguita a mano sia che la faccia
il compilatore), se Cell non ha sufficiente banda di I/O
sulla ram e potenza di calcolo tale da viaggiare in media
almeno al doppio della concorrenza (n.b. prestazioni
medie effettive, non quelle di picco!!!)
e' destinato ad avere un utilizzo relativamente limitato.
L. Micheletto

 e per C>=2 il Cell risultera' decisamente piu veloce.
Mi correggo:
Piu che "efficienza" basta che sia piu o meno uguale il tempo
di elaborazione per blocco, se si impiega un tempo K per blocco
non importa se questo e' ottenuto da una cpu con clock "alto"
ed IPC basso o viceversa.
L. Micheletto