Newsgroup: it.comp.hardware.cpu
Titolo: Cell - Una considerazione

Ho letto l'articolo di Anandtech (se ne avete altri che vadano ancor
più a fondo tecnicamente che ben vengano) e non capisco lo scetticismo
di chi ha fornito il link (Lamda mi pare).
Il fatto che sia un processore in-order e che quindi il compito di
ottimizzare il riempimento delle pipeline venga demandato al
compilatore non mi sembra una catastrofe. Voglio dire: alla IBM avranno
pensato a sviluppare un compilatore adeguato per i loro processore, non
credete?
E cmq, vista la relativa semplicità architetturale del PPE e del SPE
non pensate possa essere abbastanza semplice per IBM produrre un Cell
per usi general purpose che possa competere con i nuovi Pentium e
Athlon?
Detto sinceramente, a me Cell pare una gran CPU, sotto ogni punto di
vista.

Certo che è una ottima cpu!! Forse sono stato troppo "duro" :-). 300 milioni 
di transistor non sono bazzecole insomma! Sinceramente sono quasi un fan 
:-).
Dai post precedenti, che tendevano a enfattizzare il tutto (le 8 unità 
interne etc...), mi è parso che pochi avessero ben in mente di come fosse 
fatto "dentro"...
Il fatto che le varie unità siano in-order fa ben capire quanto esse siano 
state "castrate" per problemi tecnologici (anche per le unità di branch 
limitate....da qualche parte devono limitare il numero di transistor), certo 
il compilatore aiuta (mi sembra il minimo) ma è esattamente come tornare a 
13 anni fa, al 1° pentium (certo con 3.2Ghz e banda di memoria 
eccezionale)... questo è un punto debole. Per applicazioni fortemente 
specializzate e ottimizzate si avranno prestazioni eccezionali, ma per 
esempio in ambito "più general purpose"?  è solo il cuore power pc che si 
comporta decentemente che,da quel che ricordo, anch'esso è limitato da 
qualche parte (l'articolo l'ho letto appena uscito e non ho molta voglia di 
rileggerlo...oppure era sull'altro articolo? mha)...
Per esempio, rimanendo in ambito console, siamo sicuri che le cpu dell XBOX 
360 siano tanto meno efficienti? sono pur sempre 3 ingrado di gestire 6 
thread... e non mi pare che non abbiano limitazioni a livello 
architetturale...
L'idea di adottare tale cpu in una console, di sicuro successo, come la PS3 
è un'ottima soluzione per la sua diffusione... si troverebbe sicuramente in 
difficoltà altrimenti considerando l'incapacità del mercato ad accettare 
cambi architetturali di questo genere e soprattutto, se è vero quello che ho 
letto, la sua difficoltà di programmazione che rende più difficile il 
porting di software da/per questa architettura...
IBM ha precorso i tempi, ha anticipato di qualche anno la normale evoluzione 
nel campo delle cpu. In un certo senso mi pare quasi di essere tornati ai 
tempi dell'amiga.... un architettura nuova da esplorare...in me non può che 
trovare un accanito sostenitore :-)...

 trovare un accanito sostenitore :-)...
Bravo, appena IBM fornisce esce allo scoperto, ti
racconto un po' di storie.
bye,
-- 
piergiorgio

 che l'HW di una CPU non puo` quasi mai permettersi.
Ecco, questa cosa mi interessa. So qualcosa di architettura dei processori,
ma un po' niente di compilatori, quindi mi chiedevo se davvero il
compilatore puo' svolgere quel compito _meglio_.
Mi spiego: non c'e' dubbio che il compilatore puo' riordinare molte cose
piu' facilmente perche' ha una visione generale del programma, e non
limitata a qualche decina/centinaia di istruzioni come la CPU, pero' la CPU
ha una visione del programma "in run time", e puo' decidere il riordino al
momento, sulla base di come il programma si sta evolvendo nella CPU stessa.
Il compilatore non puo'. Se ad esempio un load ci mette troppo tempo a
caricare un altro lo potrebbe scavalcare... in run time, ma un compilatore
questo non puo' saperlo, li starebbe magari eseguendo in sequenza, perdendo
tempo prezioso.
Immagino (o forse c'era scritto nell'articolo?) che e' per questo che il
Cell non ha cache ma ogni core ha la sua memoria centrale, per avere un
tempo di accesso alla memoria uniforme e poter modellare deterministicamente
l'accesso alla memoria nel compilatore (latenze predicibili)... giusto?
Mi chiedo a 'sto punto pero' quale sia l'impatto sulle prestazioni di questo
modello di memoria: solo 256 K per processore, e 6 cicli di latenza... ma
non ha una cache istruzioni?
Vabbe', ho delirato abbastanza :-)
Pleg

 compito lo puo` svolgere _meglio_ il compilatore.
...
Non le ho mai viste :-(...
Devo dire che alcuni miei commenti sono stati scritti un po' di getto da 
quel che ricordavo dall'articolo (letto un po' di tempo fa)... Riflettendoci 
ho detto delle inesattezze... per vedere l'effettiva efficienza sul campo 
non rimane che aspettare cmq :-).
Sono contento che ci siano persone davvero preparate, spero di imparare 
molto da questo ng :-).

 non ha una cache istruzioni?
Idem come sopra, sorry,
bye,
-- 
piergiorgio

bye,
-- 
    (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]

 nda fino alla radice dei capelli? :)
Quasi :-)
Il fatto e` che non so se, per esempio, gli stadi del
pipeline (delle SPE) siano pubblici o no, oppure il
modo di controllo della memoria, per cui non posso
esprimermi... NDA rulez... :-)
bye,
-- 
piergiorgio

 in contesti ben precisi del codice e non a caso.
Scusa, qua non ti seguo. Cosa vuol dire "D'altro canto nessuno e` in grado
di sapere _apriori_ se una load/store andra` in un modo o nell'altro" ? In
che modo puo' andare una load/store?
L'esempio che facevo io era un load che scavalca un altro load: in quel caso
posso accelerare (mandare subito in pipeline) le istruzioni dipendenti dal
secondo load, prima di quelle dipendenti dal primo (se non ci sono altre
dipendenze dati, ovviamente).
Ciao
Pleg

 dipendenze dati, ovviamente).
Si, ma, ancora, con che vantaggio.
Devi essere sicuro che:
1) ci sia un'altra load
2) sia in cache
3) non abbia altre dipendenze
Direi che la probabilita` sia piuttosto bassa.
Inoltre il compilatore potrebbe benissimo cercare
di ordinare le load in modo piu` assennato possibile.
bye,
-- 
piergiorgio

 compilatore puo' svolgere quel compito _meglio_.
Almeno nel caso del Cell il discorso e' un altro, ovvero se un compilatore
puo eseguire quel compito _abbastanza_ bene.
Fondamentalmente dai dettagli resi pubblici si capisce che
*una* delle idee alla base del Cell e' realizzare un sistema
con una potenza di calcolo *di picco* (quella che ottieni se riesci
a far lavorare tutto al 100%) E L E V A T I S S I M A.
Poi basta che un compilatore riesca ad ottimizzare/riorganizzare
il codice in modo da ottenere prestazioni reali che siano un 20..30%
di quelle di picco e comunque la potenza di calcolo sara' superiore
ad una cpu "normale".
Per quel che si puo capire il Cell e' stato pensato
tenendo conto di molteplici obiettivi.
Solo se si tiene conto di tutti questi obiettivi prefissati
si puo capire perche sono state fatte certe scelte.
Per esempio, l'avere molte SPE tra le altre cose permette
di avere un parziale controllo della potenza dissipata
senza usare troppa circuiteria dedicata (se le temperature
superano una certa soglia lo scheduler delle SPE puo decidere
di non fornire nuovo lavoro ad alcune di esse per abbassare
la temperatura), inoltre sempre perche le SPE sono
relativamente "semplici" ma in numero elevato si semplifica
il lavoro del compilatore o del programmatore
(perche se hai 8 SPE "semplici" e non ne sfrutti una, perdi
  solo il 12.5% della potenza di calcolo di picco, se invece
  ne ci fossero solo 4 SPE "piu potenti", se non ne sfrutti
  una perdi di botto il 25% della potenza di calcolo di picco).
Anche la PPE "semplice" ma con supporto dual threading
la si vede in modo diverso non appena si considera
che il suo lavoro e' principalmente far girare codice
che mal si adatta alle SPE (e di solito si tratta di roba
non particolarmente pesante in termini di potenza di calcolo
richiesta) e che il supporto del dual threading ha come conseguenza
che le SPE non utilizzate da un thread sono quelle disponibili
per l'altro (quindi anche qui basta che quel che gira nei thread
sfrutti anche solo il 50% delle SPE disponibili ed il Cell
si trova a lavorare quasi a potenza di picco).
Ovviamente le mie sono solo ipotesi, ci sono certi "dettagli"
non ancora noti (sino a che punto i PPE possono controllare
le SPE, sino a che punto le SPE sono indipendenti da quel
che gira sulle PPE, ecc. ecc.) che sono fondamentali
per capire quanto le prestazioni teoriche del Cell
siano vicine a quelle reali.
L. Micheletto