Cell!!

[alexmaz]

Originariamente inviato da Criceto
Hannibal di ArsTechica aveva anche fortemente criticato l'articolo del "dilettante" Blanchford (http://www.blachford.info/computer/Cells/Cell6.html) apparso un paio di settimane fà, che invece si è rilevato sorprendentemente corretto sia dal punto di vista delle previsioni architetturali (addirittura migliori del previsto per le SPE che sono risultate avere molta più memoria locale e un'unità DP) che di prestazioni stimate. Che poi il suo articolo si lanciasse su speculazioni probabilmente fin troppo ottimistiche è un altro conto (in particolare sulla possibilità di emulare un PC secondo me ha esagerato).

Credo che anche "pro" come Hannibal questa volta sono rimasti spiazzati dall'innovativo processore IBM/Sony/Toshiba che ha davvero le potenzialità di dare un forte scossone al mondo informatico. Non appare infatti esserci alcuna controindicazione tecnica per il suo utilizzo da parte di Apple, in particolare. Anzi le nuove funzioni Core Image & Video e il nuovo Codec H264 per il video HD che debutteranno in Tiger, sono particolarmente adatte per essere implementante su questo microprocessore. Come tutta la suite iLife (spinta molto da Jobs) che ne trarrebbe immenso beneficio.

Se volete leggere delle vere ed estreme speculazioni questo è un bel post:
http://forums.applenova.com/showthread.php?t=4033

Boh, lui dice che l'unità PPC parrebbe meno potente di un G5, ma soprattutto che l'unità Altivec sia molto semplificata rispetto a quella dei G5.

[Criceto]

Originariamente inviato da alexmaz
Boh, lui dice che l'unità PPC del parrebbe meno potente di un G5, ma soprattutto che l'unità Altivec sia molto semplificata rispetto a quella dei G5.

Per quanto si sà l'unità PPE del Cell è "in-order", mentre il G5 (aka 970) e i Power5 e tutti i principali processori attuali sono "out-of-order". Questo significa in parole povere che sul Cell le istruzioni vengono eseguite con lo stesso ordine in cui sono scritte nel codice eseguibile, mentre nelle architetture "out-of-order" l'ordine delle istruzioni può essere cambiato in fase di esecuzione dal processore per mantere il più possibile piene le pipeline.

Questo è un "trucco", molto complesso da realizzare architetturalmente, che si rende necessario in quanto i processori attuali hanno pipeline molto lunghe e sono molto penalizzati se devono accedere alla memoria che è estremamente lenta rispetto ai processori stessi. Quindi in caso di svuotamento della pipeline (branch mis-prediction) si possono perdere anche decine di cicli prima che il processore possa completare una nuova istruzione.

Però questo "limite" non è ancora chiaro quanto possa penalizzare il Cell per i seguenti motivi:
1) Non si sà quanto sono lunghe le sue pipeline, ma dall'articolo sotto citato si suppone che non siano poi così lunghe come sui G5 attuali o addirittura i Pentium4;
2) Il Cell avrà una velocità di accesso alla memoria di almeno 5 volte più veloce rispetto allo stato dell'arte attuale, quindi un accesso alla memoria in caso di branch mis-prediction sarà sicuramente meno penalizzante che nelle architettura attuali;
3) Il problema dell'ordine ottimale delle istruzioni può essere risolto a monte da un compilatore che ottimizza il codice per Cell. E' un approccio, per esempio, utilizzato dall'Itanium che (per quanto differente) può essere considerata una architettura "in-order".
Significherà in pratica che un codice ricompilato per Cell avrà sicuramente prestazioni molto superiori di un codice "generico" per PowerPC. Questo avviene anche adesso perchè un G4 e un G5 (per esempio) sono architetture molto differenti che richiedono ottimizzazioni differenti, con il Cell semplicemente tale differenza sarà più marcata. Infatti la natura "out-of-order" dei G4/G5 fà si che le penalizzazioni in caso di codice non ottimale siano ridotte, in quanto parte dell'ottimizzazione la fa il processore. Insomma si riduce la complessità del processore a fronte di un aumento di complessità del compilatore.
4) La PPE del Cell è 2-way multi-threaded, questo significa che è vista dal sistema operativo come se fosse un biprocessore. Questo è un bel passo avanti rispetto al G5 e potrebbe compensare i problemi dovuti alla sua natura non "out-of-order"

Bisogna poi aggiungere il non irrilevante aumento di frequenza del Cell rispetto ai G5, più o meno il doppio. Questo ridurrà sicuramente all'atto pratico le sue "lacune" architetturali.

Sono ancora convinto che l'unità PPE del [email protected] avrà prestazioni leggermente superiori di quelle di un [email protected] con codice attuale. E significativamente superiori per codice ricompilato e ottimizzato per lei.

In quanto all'Altivec quel commento di Hannibal è molto stupido, perchè:

1) non sa come è fatto (nessuno l'ha detto) quindi che sia più semplice è una sua supposizione.
2) Comunque il processore avrà una frequenza di funzionamento di circa il doppio più veloce dello stato dell'arte dei G5 attuali e quindi le istruzioni Altivec saranno eseguite in metà tempo senza eventuali penalizzazioni date dalla natura "in-order" della PPE, in quanto le istruzioni Altivec sono sempre "in-order".
3) E' irrilevante perchè l'unità Altivec sta lì solo per motivi di compatibilità con il software scritto per Mac e quindi sarà utilizzata solo per il periodo di transizione al Cell. Infatti le unità SPE hanno la stessa funzione dell'Altivec ma con prestazioni mostruosamente più veloci, quindi il codice che attualmente utilizza Altivec dovrebbe essere prima o poi riscritto per le SPE.

Insomma "Hannibal" mi ha molto deluso in questo caso.
Molto meglio l'articolo di di David Wang su http://www.realworldtech.com/include...318&mode=print

[Criceto]

Un nuovo report sul Cell veramente completo sullo stato di conoscenza attuale e finalmente ben fatto (oltretutto impaginato con Pages, per la cronaca) si può scaricare qui: http://www.igeek.com/CellProcessor.pdf

[cdimauro]

Originariamente inviato da alexmaz
Boh, lui dice che l'unità PPC parrebbe meno potente di un G5, ma soprattutto che l'unità Altivec sia molto semplificata rispetto a quella dei G5.

E ha certamente ragione. Su un punto non concordo: le pipeline del PPE dovrebbero essere più lunghe di quelle del G5, come risulterebbe dalle informazioni provenienti dal ISSCC 2005 (in particolare dal report di real world e che ho già sottolineato: "the pipeline was lengthened as a result").
D'altra parte proprio la riduzione del lavoro eseguito per ogni stage della pipeline e il conseguente l'allungamento della medesima permette a un processore di scalare meglio in frequenza...

Altra cosa da sottolineare, è che anche se la banda verso la memoria è notevolmente aumentata, è aumentata molto anche la sua latenza d'accesso. Questo non è un problema per un'architettura che ha come scopo principale quello di "macinare numeri" (le SPE), ma diventa un handicap per una CPU che deve eseguire codice "general purpose" (la PPE).

I compilatori possono cercare di "mitigare" il problema dell'esecuzione di codice che presenta degli stalli nella pipeline causati da cache miss per i dati e/o codice, da salti non predetti correttamente (a proposito: non ho ancora letto nessuna informazione sulla presenza o meno di una sezione di branch prediction, ed eventualmente della sua implementazione. L'unica cosa sicura è che il G5 ne ha una eccellente), e dalla dipendenza dei dati (questo è ancora più amplificato in un'architettura "in order"), ma certamente non possono fare miracoli. Anzi, è molto difficile farli! Basta vedere il comportamento di Itanium con del codice "general purpose": considerato il fatto che Intel produce dei compilatori fra i migliori al mondo e le scarse prestazioni del suo Itanium, è un fattore da prendere seriamente in considerazione.

Inoltre la possibilità di eseguire due thread potrebbe servire soltanto nei casi in cui si ci possa avvantaggiare di questa caratteristica. Resta da vedere, comunque, in che modo è realizzata l'esecuzione di codice dei due thread: potrebbero anche eseguire un'istruzione "a testa", e questo migliorerebbe l'efficienza del processore col codice multithreaded, ma penalizzerebbe molto quello single thread.
Comunque non ci sono ancora informazioni precise in merito: è presto per poterne parlare...

Altra cosa: i G5 attualmente sono arrivati a 2,5Ghz a 90nm, e le specifiche del Cell sono passate dai 4,6Ghz iniziali ai 4Ghz attuali (i 256GFLOPS di picco sono stati "tirati fuori" con questo clock). Le differenze ci sono, ma ci sono anche e soprattutto quelle architetturali: il G5 è decisamente più complesso ma anche MOLTO, MOLTO più efficiente rispetto all'unità PPE presente in Cell.
Penso che un G5 attuale potrà ottenere delle prestazioni mediamente migliori dell'unità PPE del Cell.

Quanto al VMX/Altivec: è diverso da quello implementato dei G5 (si parla della possibilità di manipolare quantità a 64 bit, suppongo numeri FP a doppia precisione, che non è presente nell'unità Altivec). Non è detto che quest'unità sia presente per mantenere una qualche compatibilità con quella dei G5 (Sony, Toshiba e IBM hanno ben altri obiettivi per Cell), ma può darsi che sia utile per la comunicazione con le unità SPE, essendo in grado di trasferire dati a 128 bit "alla volta" anziché a 64 bit, come i registri del PPE; 128 bit che somigliano molto anche ai 128 bit dei registri delle unità SPE.
D'altra parte non ha senso pensare di far girare eventualmente (perché ancora non si sa ancora esattamente come sono fatti né la PPE né la sua unità VMX, e quindi la compatibilità col G5 e/o Altivec è tutta da provare) le "vecchie" applicazioni PowerPC/Altivec, perché le prestazioni sarebbero decisamente scadenti, anche a fronte di clock d'esercizio così elevati.
Sarebbe necessario una ricompilazione, ma a questo punto tanto varrebbe ricompilare le applicazioni per sfruttare direttamente tutta la potenza di Cell (PPE E unità SPE).

P.S. Hannibal è un utente Mac, ma forse ha un "difetto" agli occhi di tanti utenti Mac: è una persona razionale e i suoi giudizi sono dettati dalla sua esperienza e dal suo bagaglio culturale, non dal fanatismo o da un irreale ottimismo, com'è possibile rilevare dalla lettura del thread di AppleNova o da quel documento PDF su Cell (che tra l'altro riporta un po' di inesattezze).

[Hal2001]

Certo che è strano pensare ad una cpu [se tale può essere definita] così complessa, funzionante a oltre 4GHZ, con una pipeline molto corta, come tu affermi Criceto.

[Criceto]

Originariamente inviato da Hal2001
Certo che è strano pensare ad una cpu [se tale può essere definita] così complessa, funzionante a oltre 4GHZ, con una pipeline molto corta, come tu affermi Criceto.

Non è che lo affermo io, questa ipotesi è fatta sia dallo stesso Hannibal che da Wang negli articoli citati da cdimauro (che evidentemente continua a non saper leggere). E inoltre pare fosse molto corta nel prototipo presentato nel 2000 che sembrerebbe essere l'antesignano della SPE del Cell.

Per esempio questa frase che cdimauro ha riportato sopra "the pipeline was lengthened as a result" non è riferita al G5, ma a quel prototipo del 2000 che di di stadi nella pipeline pare ne avesse 4, se non ho capito male. Il G5 ne ha 16 per gli interi e 21 FP. C'è una BELLA differenza...

[cdimauro]

E' vero: quella frase si riferisce al prototipo a 1Ghz del 2000. Ma c'è da dire anche questo:

"IBM claims that while the logic complexity of each pipeline stage is roughly comparable to other processors with a per stage logic depth of 20 FO4, aggressive circuit design, efficient layout and logic simplification enabled the circuit designers of the CELL processor to reduced the per stage circuit delay to 11 FO4 throughout the entire design."

D'altra parte il PPE è comunque un RISC Power-like, per cui per eseguire le istruzioni dovrà fare sempre un certo tipo di lavoro, distribuito su diversi stadi di pipeline. In tutti i documenti non si fa menzione a quanti sono gli stadi di pipeline, ma semplicemente che il ritardo di ogni stadio di pipeline è stato ridotto (rispetto alle altre soluzioni).

Inoltre un processore Power-like a 1Ghz, per quanto possa essere semplificato eliminando la logica out-of-order, difficilmente potrebbe far uso di soli 4 stadi di pipeline per portare a termine tutto il lavoro necessario per eseguire un'istruzione: questo vorrebbe dire che ogni stadio di pipeline dovrebbe eseguire PIU' LAVORO (rispetto alle altre implementazioni), il che cozza contro le dichiarazioni di IBM di cui sopra (più lavoro -> maggiori ritardi -> frequenza raggiungibile dai circuiti più bassa).

Ricordiamoci che il G3 e i primi G4 erano decisamente meno "complicati" dei successivi G4 (i G4+) e addirittura dei G5, avevano una pipeline a 4 stadi, e sono stati "bloccati" a 500Mhz proprio per questo motivo.

Al contrario, e come ha sottolineato anche Hal2001 e viene riportato in letteratura, è noto che, per fargli raggiungere delle frequenze elevate, un circuito deve semplificare il lavoro eseguito per ciclo di clock; il che porta a suddividerlo in più stadi (di pipeline).

Da tutto ciò si deduce che, se non ne avrà di più, probabilmente il PPE avrà un numero di stadio di pipeline comparabile a quello di un G5.

Altra considerazione che m'è venuta in mente: il fatto che il PPE sia un'architettura "in order", potrebbe portare a dei problemi di compatibilità con l'esecuzione di codice, anche nel caso in cui l'ISA fosse quello di un PowerPC.
Infatti, cosa succederebbe se dovesse eseguire due istruzioni, con la seconda che ha una dipendenza dalla prima? Potrebbe generare un'eccezione (probabile), dar luogo a risultati "imprevedibili" (meno probabile), o eseguirne soltanto una (anche questa probabile).
Nel caso in cui venga eseguita un'eccezione, il "kernel" potrebbe sobbarcarsi l'onere di "suddividere" l'esecuzione delle due istruzioni, portando a termine correttamente il lavoro, ma pagando un prezzo elevatissimo in termini computazionali.
Molto migliore la situazione nel caso in cui il processore provvedesse ad eseguire un'istruzione alla volta per ciclo di clock.
Pessima situazione nel caso di risultato "imprevedibile".
Tutto dipende chiaramente dalla soluzione che ha adottato IBM.

Anche nel caso migliore (un'istruzione per ciclo di clock), le già scarse prestazioni di una CPU come questa verrebbero ridotte.
Considerato il fatto che il codice attuale sfrutta fortemente l'esecuzione fuori ordine, avvalendosi anche del fatto che le implementazioni delle architetture fanno uso di rename register per limitare le dipendenze dei risultati, il quadro non mi sembra affatto favorevole all'uso di Cell per rimpiazzare la CPU delle macchine attuali...

P.S. IBM potrebbe anche aver deciso di far eseguire un'istruzione per ogni thread per ciclo di clock: ricadremmo nel caso "migliore", ma in questo modo le prestazioni risulterebbero ulteriormente penalizzate (una sola istruzioni per ciclo di clock, contro le due eseguite nei casi di non dipendenza).

[Gold2004]

Originariamente inviato da cdimauro
Altra considerazione che m'è venuta in mente: il fatto che il PPE sia un'architettura "in order", potrebbe portare a dei problemi di compatibilità con l'esecuzione di codice, anche nel caso in cui l'ISA fosse quello di un PowerPC.
Infatti, cosa succederebbe se dovesse eseguire due istruzioni, con la seconda che ha una dipendenza dalla prima? Potrebbe generare un'eccezione (probabile), dar luogo a risultati "imprevedibili" (meno probabile), o eseguirne soltanto una (anche questa probabile).
Nel caso in cui venga eseguita un'eccezione, il "kernel" potrebbe sobbarcarsi l'onere di "suddividere" l'esecuzione delle due istruzioni, portando a termine correttamente il lavoro, ma pagando un prezzo elevatissimo in termini computazionali.
Molto migliore la situazione nel caso in cui il processore provvedesse ad eseguire un'istruzione alla volta per ciclo di clock.
Pessima situazione nel caso di risultato "imprevedibile".
Tutto dipende chiaramente dalla soluzione che ha adottato IBM.

L'angolo dell'ignorante.

Andando per deduzione, credo che logica 'in order' esegua calcoli in ordine, 'out of order' fuori ordine^^
Se si possono calcolare due istruzioni contemporaneamente, ma la seconda e' dipendente dalla prima per forza andranno eseguite prima una poi l'altra.
Ammenoche' l'unita' non abbia curiose doti di preveggenza dovra' avere il risultato della prima per poter calcolare la seconda, anche andando 'fuori ordine'.

Cosa mi sfugge??

Saluti

[Powerhouse]

http://www.ilmac.net/notizie/visualizza.php?id=2267

[Criceto]

Originariamente inviato da Gold2004
L'angolo dell'ignorante.

Andando per deduzione, credo che logica 'in order' esegua calcoli in ordine, 'out of order' fuori ordine^^
Se si possono calcolare due istruzioni contemporaneamente, ma la seconda e' dipendente dalla prima per forza andranno eseguite prima una poi l'altra.
Ammenoche' l'unita' non abbia curiose doti di preveggenza dovra' avere il risultato della prima per poter calcolare la seconda, anche andando 'fuori ordine'.
i

Infatti le archietture fuori ordine cercano per quanto possibile di tirare fuori il parallelismo nel codice scalare (non parallelo). Ma se ci sono delle dipendenze dirette non c'è fuori-ordine che regge: devono aspettare il completamento dell'istruzione prima di poter elaborare la successiva.

Però il fatto che il Cell è multithread significa che se su un thread il codice stalla (per un branch mis-prediction) intanto il processore può elaborare un altro thread. Su un G5 questo non è possibile. E in un sistema operativo complesso come OS-X (anche XP e Linux) ci sono sempre decine di thread in esecuzione.

Per la "preveggenza" ci sono i circuiti di "branch-prediction", che cioè cercano di prevedere dove andrà a finire il flusso del codice dopo un salto. Ma sono una cosa separata rispetto all'"out-of-order" e dovrebbe averli anche la PPE del Cell, anche perchè addirittura questi circuito ce l'hanno le SPE che sembrano quasi dei processori general-purpose, per quanto ottimizzati per il calcolo vettoriale.



Correzione: avevo inverito PPE con SPE

[Gold2004]

Originariamente inviato da Criceto
Infatti le archietture fuori ordine cercano per quanto possibile di tirare fuori il parallelismo nel codice scalare (non parallelo). Ma se ci sono delle dipendenze dirette non c'è fuori-ordine che regge: devono aspettare il completamento dell'istruzione prima di poter elaborare la successiva.

Curioso, ora che non sono del tutto lucido.. ehm, mi e' venuto in mente che una architettura fuori ordine potrebbe benissimo eseguire una istruzione che non ha dipendenze particolari che sarebbe seguente a quelle con le dipendenze.



Saluti

[cdimauro]

Originariamente inviato da Gold2004
L'angolo dell'ignorante.

Andando per deduzione, credo che logica 'in order' esegua calcoli in ordine, 'out of order' fuori ordine^^
Se si possono calcolare due istruzioni contemporaneamente, ma la seconda e' dipendente dalla prima per forza andranno eseguite prima una poi l'altra.
Ammenoche' l'unita' non abbia curiose doti di preveggenza dovra' avere il risultato della prima per poter calcolare la seconda, anche andando 'fuori ordine'.

Cosa mi sfugge??

Saluti

Ti sei risposto da solo nel tuo ultimo messaggio.

Prendiamo il G5, ad esempio: per ogni ciclo di clock legge una linea di cache L1 che contiene 8 istruzioni, la "analizza" e tira fuori al massimo 5 istruzioni da eseguire.
E' chiaro che se c'è un'istruzione che per essere eseguita ha bisogno del risultato di qualche istruzione precedente, sarà messa "in coda" aspettando che esistano le condizioni per poter essere finalmente eseguita. Ciò non pregiudica, però, la possibilità di eseguire le altre istruzioni, se non hanno dipendenze di questo tipo.
E' così che funziona un moderno processore che implementa della logica out-of-order, ed è in questo modo che si riesce a migliorare l'IPC (numero di istruzioni eseguite per unità di clock).

Ciò non toglie che è possibile ritrovarsi con la CPU in stallo perché ha trovato delle dipende che non si possono risolvere, o le risorse sono tutte impegnate, a causa di un branch misprediction, ecc. ecc... In questo caso una CPU multi-thread "passa la palla" all'altro thread, che potrà continuare l'esecuzione, sempre a patto che possa farlo.

Il fatto che Cell sia un sistema multi-thread non implica, comunque, che sia efficiente. Infatti non è ancora nota la sua implementazione (due istruzioni per thread o una per ogni thread?), ma il fatto che sia in-order lo penalizza in ogni caso: non c'è paragone con l'implementazione multi-thread-on-chip di un P4 o di un Power5.
Cell passerà molto tempo a "switchare" fra un thread e l'altro, perché "bloccato" dalla sua natura in-order, e questo non vuol dire che l'intero sistema se ne avvantaggerà: le applicazioni che sfruttano il multi-thread se ne potranno avvantaggiare, le altre no. Ma questo avviene già per i sistemi multi-thread attuali, che si comportano molto meglio, appunto.

La logica di branch prediction comunque non farà miracoli: anche se è presente (e non si conosce la sua implementazione), davanti a un classico

cmp x,y
jcc etichetta

si scontrerà comunque con la logica in-order del processore (il salto condizionato dipende dalla prima istruzione), con tutte le conseguenze del caso.

[cdimauro]

Originariamente inviato da Powerhouse
http://www.ilmac.net/notizie/visualizza.php?id=2267

Si parla di server però, e i server non richiedono la compatibilità binaria con le applicazioni OS X esistenti...

[GiovanniGTS]

Originariamente inviato da cdimauro
In parole povere: Cell è stato concepito per eseguire dei calcoli paralleli, come può essere il rendering 3D, la manipolazione di audio o video, ecc., mentre è decisamente inefficiente nel caso di applicationi di tipo "office", database, server web, emulatori, ecc.

il rendering 3D e la manipolazione audio/video? potrebbe essere intergato su una scheda di acquisizione/montaggio video?

[cdimauro]

Sicuramente, ma 256GFlops solo per questo tipo di compito sono decisamente eccessivi: si potrebbe pensare di usare un Cell "castrato" .

Un Cell con una sola SPE arriva fino a 32GFlops: mi sembra "più che sufficiente" per l'acquisizione e il montaggio video.

Per il rendering 3D, invece, non c'è potenza che possa bastare...