IBM annuncia il nuovo processore POWER6

[Criceto]

Originariamente inviato da xeal

Comunque, mi sapresti dare un link (ma mi va bene anche il titolo di un libro) ad una descrizione tecnica dettagliata del perchè e del come la logica ooo aggiunga una complessità tale da impedire od ostacolare l'aumento della frequenza di una cpu?

Risposta troppo lunga!
La leggerò tutta quando avrò un po' di tempo.
Per quanto rigurda il punto quotato, era stato esplicitamente menzionato da uno dei progettisti del Cell, quando ne spiegava le scelte progettuali. Puoi trovare l'articolo sul sito IBM. Sorry non ho il link, ma ti ho detto dove cercare.

[Criceto]

Originariamente inviato da xeal

6) Un processore ottimizzato per i flussi digitali è, per definizione, un DSP! Le SPE di Cell sono dei veri e propri "floating point dsp ", che eseguono operazioni vettoriali prevalentemente su interi

E comuqnue quello che sembra avere le idee molto ma MOOOOLTO confuse sulle architetture dei processori e del Cell in particolare sembri essere tu. A parte le castronerie, ti sei anche riuscito a contraddire in mezza frase!!!

[xeal]

No, guarda, hanno ragione gli altri a sostenere che leggi e capisci quello che ti fa comodo

Forse ho espresso il concetto con una frase un po' complessa, però mi rifiuto di credere che tu non sia in grado di cogliere il significato di quello che ho scritto, andando oltre le parti tra parentesi, che volevano essere dei chiarimenti, e capendo che la frase non finiva li, quindi la parte che hai citato l'hai troncata apposta dove ti faceva comodo...

Posto che un dsp senza troppe pretese, o dimensionato per calcolare elaborazioni numeriche mooolto ottimizzate per essere veloci e al tempo stesso precise, è progettato per lavorare SOLO su interi, mi pare evidente che un "floating point" dsp sia un dsp capace ANCHE di calcoli in virgola mobile, e di fatti le SPE di Cell sono in grado di elaborare sia interi, sia floating point, con i registri vettoriali a 128 bit che possono contenere indifferentemente interi e float. E comunque, a parte questo dettaglio che ho dato per scontato nel definire le SPE come "floating point dsp", il concetto della frase che hai castrato era questo:

"Le SPE sono dei DSP capaci di operare in virgola mobile ed eseguire calcoli vettoriali, che operano prevalentemente su vettori di interi, con varia lunghezza per gli elementi, E numeri in virgola mobile a singola precisione, ricoprendo praticamente le esigenze di qualsiasi dsp; sono anche capaci di calcoli in doppia precisione, ma in tal caso le prestazioni si riducono notevolmente, perchè evidentemente non sono ottimizzati per gli ambiti in cui la precisione di un double è importante, e guardacaso questi ambiti escono fuori dalla portata di un dsp che elabori dati in virgola mobile"

Adesso è più chiaro?

Mi rendo conto che il termine dsp proprio non lo digerisci... Scriverai le tue lamentele anche ai redattori di arstechnica, visto che anche loro definiscono esplicitamente le SPE (o SPU se preferisci chiamarle così) come dei DSP? Hanno le idee confuse anche loro?

Ma parliamo un po' di un dsp, così ci togliamo un po' di dubbi.

DSP = Digital Signal Processor, processore di "segnali digitali". La più elementare, ma anche più tipica, per certi versi, configurazione d'uso di un dsp, prevede un convertitore analogico/digitale che fornisce un flusso di dati digitali (era questa la castroneria?) continuo al dsp, che li elabora e li restituisce come output per essere riconvertiti in segnali analogici, anche se non è sempre necessario. Un esempio di questo tipo di uso, per rimanere nei campi di applicazione di un Cell, tanto per cambiare, è un set top box per sintonizzare canali digitali in alta definizione (in questo caso non serve neanche la conversione analogico-digitale in input, visto che i segnali in alta definizione vengono trattati solo come digitali, ma in generale, lo schema d'uso di un dsp ha sia l'adc in input, sia il dac in output; un'altro esempio simile può essere un decoder satellitare, che ha in ingresso un segnale digitale, quindi non serve l'adc, ma in output può avere il dac per inviare l'output su una tv analogica, per il resto il tipo di elaborazione è lo stesso). Si tratta di elaborare flussi di dati digitali (o digitalizzati), che ben si prestano ad essere trattati in memoria come array o matrici (cioè vettori a una o più dimensioni), ed è piùttosto semplice individuare blocchi che siano indipendenti tra di loro, quindi si prestano bene anche per una elaborazione vettoriale in unità di calcolo tipo SIMD o MIMD (le SPE effettuano proprio dei calcoli di questo tipo - era anche questa una castroneria?).

Ma questa visione dell'uso di un dsp, limitata a "segnali" così come li possiamo immaginare nell'esperienza quotidiana, è riduttiva, e potrebbe non far capire quanto un dsp possa essere utile in calcoli scientifici di una certa caratura, ad esempio. Un "segnale digitale" non è altro che un funzione (del tempo, o della frequenza, o dello spazio, o di quel che si vuole, tanto si trova una trasformata adatta a passare da un dominio all'altro, quindi la chiameremo semplicemente funzione) che descrive una "grandezza fisica" (nel senso più lato che si possa immaginare, quindi la chiameremo semplicemente grandezza) quantizzata, ossia presa per campioni, a intervalli interi (diventa una f(i), dove i è una variabile intera), e approssimata a valori interi (diventando, alla fine, una E(i), dove E rappresenta il codominio intero della funzione); però un sistema digitale può anche trattare numeri reali, che tuttavia dovranno inevitabilmente essere approssimati, perchè esprimibili, comunque, con un numero limitato di bit.

Quindi, in definitiva, un DSP è un processore capace di elaborare delle funzioni su delle grandezze espresse come quantità digitali: in questo senso, un dsp può elaborare qualsiasi cosa, ma darà il meglio di sè solo con dati strutturati in modo da costituire un flusso continuo, ovvero organizzati in grossi blocchi, da elaborare blocco per blocco, senza dover saltare da un blocco all'altro, meglio ancora se trattabili in parallelo per mezzo di unità di calcolo vettoriale. Ed è uno sporco lavoro che richiede tanta potenza: cosa ci sia di offensivo nel definire un processore DSP (=belva feroce nel macinare dati, ma con un certo livello di specializzazione), ancora non riesco a capirlo... si vede che sono tarato...

Forse il tono che ho usato nella parte finale del mio post ti sarà sembrato aggressivo, ma non era mia intenzione, e sono prontissimo a scusarmene, però al tempo stesso mi permetto di invitarti ad avere l'umiltà, che tutti dobbiamo avere, nell'accettare critiche da chi, forse (e dico forse), sa qualcosina in più di te, e ad avere la buona volontà di distinguere le critiche fini a se stesse, gli attacchi, da critiche fatte in buona fede, con l'intento di stimolarti ad approfondire questioni che già ti appassionano, per avere un dialogo più costruttivo.

[Criceto]

Originariamente inviato da xeal

Forse ho espresso il concetto con una frase un po' complessa, però mi rifiuto di credere che tu non sia in grado di cogliere il significato di quello che ho scritto, andando oltre le parti tra parentesi, che volevano essere dei chiarimenti, e capendo che la frase non finiva li, quindi la parte che hai citato l'hai troncata apposta dove ti faceva comodo...

Se mettessi anche un PUNTO ogni tanto evitarei di dover troncare le tue frasi. Ma ti prego di rileggere la parte quotata!

Mi sembra di capire che per te tutti i processori che hanno unità vettoriali siano DSP. Per me un processore "general pourpose" che ha anche unità vettoriali (TUTTI i processori moderni!) sono semplicemente ANCORA più general pourpose perchè, tra le varie cose, gestiscono meglio i flussi digitali (diciamo così).

Questo, naturalmente, include il Cell le cui SPU NON SONO semplici unità vettoriali ma processori veri e propri, A LORO VOLTA GENERAL POURPOSE, anche se particolarmente ottimizzate al trattamento vettoriali dei dati sia floating, che int (tanto per riprendere la tua contradditoria definizione) senza alcuna particolare preferenza se non il minor supporto alla doppia precisione. Se poi ci metti l'ulteriore unità PowerPC (che a sua volta include Altivec!), vedrai che il Cell è un CASINO ma tutto tranne che un DSP.

Originariamente inviato da xeal

Mi rendo conto che il termine dsp proprio non lo digerisci... Scriverai le tue lamentele anche ai redattori di arstechnica, visto che anche loro definiscono esplicitamente le SPE (o SPU se preferisci chiamarle così) come dei DSP? Hanno le idee confuse anche loro?

Quota dove lo scrivono!!!

Lo sai che con le SPE del Cell hanno implementato algoritmi per la gestione di alberi (roba per database, tutti salti condizionati) con prestazioni di 1 ordine di grandezza superiore ai moderni processori Intel?
Cioè proprio il campo più lontanamente immaginabile dai tuoi cari DSP.

Saranno tosti da programmare, saranno ottimizzati per i flussi digitali, ma sono sufficientemente general pourpose fare tutto e meglio dei processori tradizionali con OOO o meno.
Giusto qualche carenza sulla doppia precisione (ma se cerchi sul sito IBM già ci stanno lavorando su questa cosa).

Semplicemente sono una nuovo approccio all'architettura dei calcolatori. Non è che devi per forza inquadrarli in una categoria che era scritta sul libro di architettura che hai letto tu...

[xeal]

Il discorso sulle SPE come unità "complete" e non solo vettoriali è complesso, ed è valido più sulla carta che nella realtà, nel senso che se vai a guardare i brevetti (data la foglia, brevettare l'albero) e alcuni progetti, di cui però non si sa se verranno mai realizzati, allora vedi che effettivamente una SPE può contenere di tutto. Però, nell'implementazione attuale contiene SOLO 2 unità vettoriali che operano su registri a 128 bit, più la parte relativa al caricamento e alla decodifica delle istruzioni, in questo senso sono complete, ma non general purpose perchè "castrate": sono come le cpu amd o intel a cui togli tutto, ma proprio tutto, anche la cache - comunicano con il local storage con un piccolo controller dma esterno all'unità di calcolo - e lasci, come unità di calcolo, solo la parte per le SSE, oppure come un g4/5 che ha solo (2 unità) altivec. In teoria potrebbero lavorare autonomamente, ma non sono in grado di far girare, ad esempio, il codice di un sistema operativo, quindi devono essere pilotate dalla PPE general purpose. E siccome sono in-order, se capitano due istruzioni dipendenti (ad esempio, A+B e B+C) può usare solo una delle due unità vettoriali (il vantaggio della ooo consiste principalmente in questo: semplificando, anche se posso eseguire solo 2 operazioni alla volta mi preparo ad eseguirne 4-5, così se per caso nelle prime 2 trovo una dipendenza, allora vado a guardare nelle altre se ce n'è qualcuna che posso eseguire indipendentemente, così ho le pipeline sempre piene).

Ma veniamo ad arstechnica: parto dal primo articolo che avevo linkato, che comunque non parla male dell'architettura del Cell, anzi la descrive semplicemente come un approccio alternativo ed interessante, di cui valutare i risultati.

The Cell processor consists of a general-purpose POWERPC processor core connected to eight special-purpose DSP cores. These DSP cores, which IBM calls "synergistic processing elements" (SPE), but I'm going to call "SIMD processing elements" (SPE) because "synergy" is a dumb word, are really the heart of the entire Cell concept.

Ancora:

[quote]The actual architecture of the Cell SPE is a dual-issue, statically scheduled SIMD processor with a large local storage (LS) area. In this respect, the individual SPUs are like very simple, PowerPC 601-era processors.[/qoute]

Qui si potrebbe fare una piccola osservazione: in realtà, il PowerPC 601 è forse il primo processore della famiglia ad aver introdotto una forma moooolto embrionale di logica ooo: visto che possiede/possedeva 2 alu, non aveva senso eseguire le istruzioni strettamente in-order, una dopo l'altra, quindi si effettuava un controllo sulla loro dipendenza, e, se non erano dipendenti, venivano eseguite in parallelo. Le SPU fanno la stessa cosa (ma la logica ooo del 601 dovrebbe essere più complessa di quella dei una spu); ma vediamole più in dettaglio, nella descrizione di arstechnica:

Cell SPE is geared for single-precision SIMD computation. Most of its arithmetic instructions operate on 128-bit vectors of four 32-bit elements.
[salto una parte relativa al local storage, perchè vorrei evitare di impelagarmi anche in quel tipo di discorso]
The SPEs also move the burden of branch prediction and code scheduling into software, much like a VLIW design.

The SPE's very simple front end can take in two instructions at a time, check to see if they can operate in parallel, and then issue them either in parallel or in program order. These two instructions then travel down one of two pipes, "even" or "odd," to be executed. After execution, they're put back in sequence (if necessary) by the very simple commit unit and their results are written back to local memory. The individual SPUs can throw a lot overboard, because they rely on a regular, general-purpose POWERPC processor core to do all the normal kinds of computation that it takes to run regular code. The Cell system features eight of these SPUs all hanging off a central bus, with one 64-bit POWERPC core handling all of the regular computational chores. Thus all of the Cell 's "smarts" can reside either on the PPC core, while the SPUs just do the work that's assigned to them.

Un piccolo appunto: questo articolo è vecchio, è stato scritto subito dopo la presentazione delle spe e prima di conoscere (il giorno dopo) le caratteristiche del core powerpc (che viene enfatizzato molto meno nel secondo articolo, ma ne parliamo dopo).

To sum up, IBM has sort of reapplied the RISC approach of throwing control logic overboard in exchange for a wider execution core and a larger storage area that's situated closer to the execution core. The difference is that instead of the compiler taking up the slack (as in RISC), a combination of the compiler, the programmer, some very smart scheduling software, and a general-purpose CPU do the kind of scheduling and resource allocation work that the control logic used to do

Cioè, la logica ooo viene eliminata per togliere complessità, ecc. ecc., ma questo non vuol dire che un opportuno scheduling non sia necessario: esso viene semplicemente demandato al compilatore (che però può "ragionare" solo in modo generico, non essendo nota la situazione interna al processore nel momento in cui il codice viene eseguito: per questo è nata la logica ooo), al programmatore (ancora peggio), ad un eventuale software di scheduling e al core ppc: cioè, quello che un x86 fa in hardware, il cell lo deve fare (in parte) via software. Da questo punto di vista, anche se più sofisticato, l'approccio del Cell al general purpose (rilevate le debite differenze) è simile a quello dei Crusoe di trasmeta, che non sono certo il massimo della vita quanto a prestazioni (c'è da dire che i crusoe emulano l'architettura x86 con una macchina virtuale, quindi le prestazioni sono basse anche per questo, ma fino a un certo punto: funziona come una specie di jit, quindi alla fine vai ad eseguire del codice nativo). Per chiarezza, il paragone con trasmeta lo trovi anche in quell'articolo.

Once the instructions are in the SPE, the SPE's control unit can issue up to two instructions per cycle, in-order. The SPE has a 128-entry register file (128-bits per entry) that stores both floating-point and integer vectors. As stated above, there are no rename registers. All loop unrolling is done by the programmer/compiler using this very large register file.

Ma veniamo al core "general purpose", che però in quella presentazione non era stato descritto molto in dettaglio:

We do know that this core has a VMX/Altivec unit, at least one FPU, and supports simultaneous multithreading (SMT). It's also in-order issue, like the SPUs. So it appears that this core also lacks an instruction window, presumably for the same reasons that the SPUs do (i.e. to save on die space and cut down on control logic.) I have in my notes that the core is two-issue, like the SPUs, but I can't find this corroborated anywhere else. So it's possible that the core only issues two instructions per cycle peak, i.e. one from each currently-running thread.
[...]
the PPC core does have a VMX unit. Nonetheless, I expect this VMX to be very simple, and roughly comparable to the Altivec unit o the first G4. Everything on this processor is stripped down to the bare minimum, so don't expect a ton of VMX performance out of it, and definitely not anything comparable to the G5. Furthermore, any Altivec code written for the new G4 or G5 would have to be completely reoptimized due to inorder nature of the PPC core's issue

In realtà, al momento della commercializzazione della PS3 il core PPC è stato migliorato, ma non credo vada (molto) oltre il G4e. Da wikipedia:

Cell combines a general-purpose Power Architecture core of modest performance with streamlined coprocessing elements

Forse troverai interessante anche questo (era nella news che ho linkato dopo i 2 articoli):

Yesterday, IBM announced a project that will join forces with Brazilian game developer Hoplon Infotainment to develop a Cell-based mainframe system that will host massively multiplayer online games targeted at console and PC users. IBM is calling this system a "gameframe," and it will use Cell BE coprocessors to handle message passing and physics simulation for a Hoplon-developed MMOG middleware layer, called bitVerse, that the two companies are porting to Cell. The mainframe's general-purpose CPUs (probably POWER, but not specified yet) will handle aspects of the MMOG like logistics, connectivity, and the Websphere- and DB2-driven portions of bitVerse.

The system will be Linux-based, and though this isn't stated, it might be based on the IBM System Cluster 1350, if not identical to it. The System Cluster 1350 is a high-performance computing product with models that integrate the Cell BE as a coprocessor with general-purpose processors from Intel, AMD, or IBM.

Come a dire: per IBM Cell è così general purpose, che lo usa come coprocessore matematico in abbinamento ad altri processori, sia Power, sia x86.

Poi tu dici che nel general purpose va meglio dei processori tradizionali con o senza ooo, e mi fai pensare a certe "sparate" di Kenshi Manabe, della Sony, sparate che, per quanto riguarda il general purpose, su arstechnica definiscono "boriose" senza mezzi termini (full of it). Ti riporto la conclusione:

The consumer demand for Cell-like levels of DSP prowess is limited to gaming right now, and probably will be for a few more years. But the demand for UltraSparc T1-levels of performance per watt is there yesterday in the datacenter. I don't have any kind of insider information at all on this, but I think it's a near certainty that IBM will announce some kind of server-specific version of Cell with an altered, integer-focused SPE architecture as soon as they reasonably can.[nota: sono voci circolate nel 2005, ad oggi non mi risulta che l'architettura di una spe sia stata effettivamente modificata]

This point brings me back to the statement quoted above, and to the issue of whether or not Cell really is "better than" the Pentium line. Manabe's claim is meaningless unless you ask, "better at what?" If Manabe means "better at DSP," then yeah, Cell is certainly better than anything in Intel's current to near-term x86 lineup for that niche. If he means "better at general purpose computing tasks," then, well, he's full of it. And if he means "better at throughput computing applications, like high-volume web servers," then he's either full of it or he's talking about some version of Cell that hasn't been made public yet.

Per quanto riguarda il discorso dei database, mi daresti qualche link? Vorrei capire che algoritmi usano, perchè senza conoscerli posso solo fare delle osservazioni di carattere generale, che potrebbero anche non calzare troppo.

Intanto, il problema principale con gli alberi non sono tanto i salti, quanto piuttosto i frequenti accessi in memoria (che è più lenta, e quindi ti fa perdere tempo, a meno di poter andare avanti con le altre istruzioni, ma questo Cell non lo fa), perchè si tratta di una struttura dati dinamica, con i dati sparsi in memoria, e che per di più va "attraversata" per trovare ciò che si trova, poichè ogni elemento contiene l'indirizzo del successivo (non puoi prendere un elemento a colpo sicuro, ma lo devi cercare). PERO', gli algoritmi che esplorano gli alberi, siccome sono molto importanti, hanno subito nel corso degli anni una notevole ottimizzazione: per citarne una, un albero generico viene sempre trasformato in un albero binario (= ogni nodo ha al massimo due figli), e questo consente, per dati ordinati (o da ordinare), di effettuare algoritmi di ricerca (o di ordinamento) molto veloci, a cui si aggiunge un altro algoritmo, detto di bilanciamento, che consente di avere dei sottoalberi con lo stesso numero di nodi (ogni nodo ha due figli, che a loro volta ne hanno due, e così via), in modo da dividere la, chiamiamola, "area di ricerca" in due parti uguali, dimezzando ulteriormente il tempo di ricerca; il bilanciamento in genere prevede che si conservino a parte delle informazioni, in strutture dati idonee (che possono anche essere degli array), in modo tale e da semplificare le operazioni di bilanciamento, e da velocizzare la ricerca (alla fine, non trovo i dati che mi servono a colpo sicuro, ma quasi).

Per quanto riguarda i database, inoltre, se non ricordo male, una certa parte dell'elaborazione si effettua su dati organizzati in blocchi sequenziali.

Inoltre, una struttura dati, che si chiami "albero", "lista", "pila", "coda", "grafo" ecc., è per lo più un concetto astratto che può essere implementato in modi diversi: quello che ho descritto usa l'impementazione basata sulle "liste concatenate" (che è la versione "concreta" e dinamica del concetto di lista), ma può usare anche vettori (in particolare per le pile, o stack, e le code), o delle matrici (principalmente per i grafi, e un albero è molto simile, come concetto, ad un particolare grafo). Ogni implementazione ha i suoi pro e i suoi contro: ad esempio, nell'uso di vettori/matrici si ha una notevole velocità nell'accesso ai dati, ma una maggiore lentezza se i dati devono essere cancellati (e tolti del tutto, per risparmiare spazio) e/o aggiunti; inoltre, l'occupazione di memoria può essere molto peggiore (specialmente per i grafi "sparsi" e gli alberi). Di conseguenza, gli alberi vengono implementati come struttura dinamica, e non dubito che nei test a cui ti riferisci abbiano usato questo approccio. Aggiungo solo che spesso, nell'esplorare un albero, si fa uso della ricorsione, ovvero si richiama la stessa funzione, ed eseguire delle chiamate a funzioni (con pochi salti al loro interno) può essere meno pesante (anche molto meno) rispetto all'esecuzione di una porzione di codice lunga (= complicata) con molti salti, specialmente in una architettura risc o risc-like (come quella interna delle cpu x86 attuali), con o senza ooo (soprattutto senza, ma anche con).

In definitiva, comunque, ciò che conta maggiormente nei database è la velocità nei calcoli interi, e la possibilità di eseguire in parallelo molte operazioni diverse (= non sugli stessi dati), e su questo, per quanto riguarda Cell, farei un paio di considerazioni.

Innanzi tutto, "apparentemente" Cell ha una notevole potenza di calcolo sugli interi, in virtù delle sue unità SPE vettoriali (2 operazioni ciascuna su 4 interi a 32 bit), però le operazioni necessarie tendono ad essere diverse, quindi non possono essere facilmente vettorializzate, ragion per cui una SPU finisce col poter fare al più 2 operazioni "scalari" (cioè, ogni operando è un solo intero). Per di più, la logica delle due unità SIMD presenti in una SPE effettua anche calcoli in virgola mobile, quindi la circuiteria è più complessa e la singola operazione (un po') più lenta rispetto ad una semplice alu. Ed è per questo che in uno dei quote che ho preso da arstechnica si accenna a cambiamenti nell'architettura delle SPE per trasformarle da unità vettoriali in scalari, per meglio competere, ad esempio, con un UltraSparc (cpu in-order, ma molto "ferrata" nel calcolo intero scalare, che macina database e applicazioni web server alla grande).

D'altra parte (osservazione numero due) ci sono 8 spe, ciascuna delle quali può effetuare una singola transazione, per cui con un po' di sana ottimizzazione e sfruttando tutte le unità in parallelo (e i database si prestano bene a questo tipo di lavoro, anzi ne hanno bisogno), si può ottenere un risultato notevole. In generale, mi aspetto risultati simili con algoritmi parallelizzati a livello di "task", ovvero con dei thread che operano su dati diversi; meno buoni invece se la parallelizzazione prevede la collaborazione delle spe, visto che la loro architettura è pensata principalmente per svolgere compiti autonomi, e le comunicazioni per lo scambio di dati non sono efficientissime, almeno non quanto lo sono gli algoritmi di ispezione della cache e le comunicazioni via hyper transport in un opteron, oppure la condivisione della cache in un Core 2. Se poi vado a confrontare il risultato con un processore tradizionale, dual core monothread, mi aspetto che il cell, con i suoi algoritmi ottimizzati e le 8 spe, vada più veloce; ne sono meno convinto se il confronto vado a farlo con un quad core, oppure con un sistema dual cpu dual core, specialmente se con hyper transport e gestione della memoria NUMA.

Veniamo ai DSP. Innanzi tutto, avevo definito, alla fine, come dsp un processore che, per le sue caratteristiche tecniche, viene sfruttato al meglio con un certo tipo di algoritmi ottimizzati, in particolare su flussi digitali. In origine i dsp non erano vettoriali, ma per lo più eseguivano calcoli scalari su interi: siccome, però la maggior parte di questi calcoli coinvolge operazioni uguali su molte variabili, allora è stato normale trasformarli in unità vettoriali per massimizzarne la velocità di calcolo. Un dsp "puro" ha poi, spesso e volentieri, un'architettura particolare, detta di harvard, con la memoria dati separata dalla memoria di programma, e accede ad entrambe separatamente, per andare ancora più veloce (le cpu "tradizionali" lo fanno di solito con la cache L1), ma sono dettagli.

Le unità vettoriali inserite in una cpu general purpose aggiungono delle funzionalità da dsp, quindi sono parzialmente d'accordo nel dire che diventano ancora più "general". Ma solo parzialmente, perchè le stesse cose poteva farle già prima, solo adesso le fa meglio, quindi, in un certo senso, poichè sono calcoli specializzati, la nostra cpu general purpose si è anche un po' specializzata.

D'altro canto, un dsp può essere molto specializzato, oppure può avere un certo grado di generalità, e quindi può anche essere programmato (con maggiore o minore difficoltà, a seconda dei casi) per compiti meno specifici, al di fuori del campo per cui è stato progettato, ottenendo prestazioni meno buone di quelle che ottiene nel suo campo, ma potenzialmente (anche molto) valide. Alla fine della fiera, parlerei di architetture più o meno ibride general-purpose/dsp, eventualmente sbilanciate verso l'una o l'altra tipologia.

E se un certo processore ha un'architettura tale da eseguire meglio i calcoli tipici di un dsp (come nei test condotti da IBM sul calcolo matriciale, che hanno tirato fuori da Cell il 98% della sua potenza massima teorica!), se la maggior parte delle sue unità di calcolo "assomigliano" a quelle tipiche di un dsp, e se per ottenere buoni risultati nel general purpose deve affidarsi, in tutto o in parte, alle controp@lle del compilatore, ed eventualmente ad una qualche "emulazione" software della logica ooo (perchè se vuoi andare veloce devi riempire tutte le pipeline che lavorano sullo stesso thread, e per farlo spesso sei costretto a riordinare le istruzioni), allora non mi sembra sbagliato parlare di architettura sbilanciata verso il dsp. Oppure, come avevo detto nel post precedente a questo, dire che il processore in questione si comporta prevalentemente come un dsp.

Ma se non vogliamo dire dsp, allora diciamo "streamlined processor", anche se il concetto è simile (per certi versi assomiglia a quello di più dsp che lavorano in parallelo, come fanno le SPE, ma può riferirsi anche al multicore di una cpu tradizionale, anche se "streamlined" ha in sè il concetto dell'elaborazione di un flusso di dati).

Spero di aver messo abbastanza punti

[Criceto]

Originariamente inviato da xeal

Per quanto riguarda il discorso dei database, mi daresti qualche link? Vorrei capire che algoritmi usano, perchè senza conoscerli posso solo fare delle osservazioni di carattere generale, che potrebbero anche non calzare troppo.

http://www.ddj.com/dept/64bit/197801624

Comunque scrivi TROOOOPPO!!

[Florio]

Xeal perdonami, ma perchè ti ostini a tentare di far capire le cose a qualcuno che trae le sue informazioni da playstation magazine o fonti del genere, paventando comunque conoscenze assolute?
Non ti infastidisce vedere i tuoi sforzi presi per giunta in giro?

Solo un consiglio spassionato tra siciliani, investi meglio le tue spiegazioni

[Lud von Pipper]

Originariamente inviato da Florio

Xeal perdonami, ma perchè ti ostini a tentare di far capire le cose a qualcuno che trae le sue informazioni da playstation magazine o fonti del genere, paventando comunque conoscenze assolute?
Non ti infastidisce vedere i tuoi sforzi presi per giunta in giro?

Solo un consiglio spassionato tra siciliani, investi meglio le tue spiegazioni

Florio, perdonami, ma perchè non ti fai gli affaracci tuoi e li lasci continuare, per una volta che c'è una discussione interessante e istruttiva?
Se ti annoi vai su un altro 3D, prendi la palla e vai fuori a giocare, o fai quello che vuoi, senza per forza tacciare di "bimbominkiaggine" questo o quello
Nessuno ha citato articoli da "PS3 news fino ad ora, quindi di che ti lamenti"?
Se sei nato "imparato" buon per te ma le argomentazioni ci sono eccome, da una parte e dall'altra, quindi lascia a noi mortali la possibilità "leggere" e "farci un idea".

Per me non sono cose ovvie come sembrano essere per te, quindi chiedo venia e riprendo a leggere il 3D

[^TiGeRShArK^]

strano però ke ancora nessuno mi abbia risposto..
se il Cell da quello ke dite è un super-processore in grado di fare tutto, le SPE sono dei processori general-purpose con prestazioni magnifiche.. ecc .. ecc...
allora per quale minGhia di motivo IBM è stata tanto masochista da buttare 5 anni di ricerca e sviluppo sul power 6 visto ke a quanto dite il Cell è il non-plus ultra?
..e vediamo se al terzo post qualcuno si degna di rispondermi

[Criceto]

Originariamente inviato da ^TiGeRShArK^

strano però ke ancora nessuno mi abbia risposto..
se il Cell da quello ke dite è un super-processore in grado di fare tutto, le SPE sono dei processori general-purpose con prestazioni magnifiche.. ecc .. ecc...
allora per quale minGhia di motivo IBM è stata tanto masochista da buttare 5 anni di ricerca e sviluppo sul power 6 visto ke a quanto dite il Cell è il non-plus ultra?
..e vediamo se al terzo post qualcuno si degna di rispondermi

Perchè per sfruttare a dovere il Cell devi riscrivere i programmi da zero. Gli algoritmi devono essere reimplementati in modo totalmente differente. E può essere molto difficile farlo (oltre che sicuramente dispendioso).

Quindi sono più adatti dove ci sono piccoli algoritmi standardizzati da ottimizzare, piuttosto che per porting di mastodontici software da altre piattaforme, che è il pane del Power6.

E probabilmente è il motivo per cui Apple ci ha rinunciato. Sarebbero stati fantastici per i vari "core-video, core-audio, core-image", e altre librerie ottimizzate dell'OS, ma si sarebbe ritrovata con il 95% dei software di terze parti che giravano solo sulla PPE, con prestazioni da G4.

[^TiGeRShArK^]

Originariamente inviato da Criceto

Perchè per sfruttare a dovere il Cell devi riscrivere i programmi da zero. Gli algoritmi devono essere reimplementati in modo totalmente differente. E può essere molto difficile farlo (oltre che sicuramente dispendioso).

Quindi sono più adatti dove ci sono piccoli algoritmi standardizzati da ottimizzare, piuttosto che per porting di mastodontici software da altre piattaforme, che è il pane del Power6.

E probabilmente è il motivo per cui Apple ci ha rinunciato. Sarebbero stati fantastici per i vari "core-video, core-audio, core-image", e altre librerie ottimizzate dell'OS, ma si sarebbe ritrovata con il 95% dei software di terze parti che giravano solo sulla PPE, con prestazioni da G4.

ecco..
quindi sei d'accordo con me che il Cell non è affatto la panacea che viene dipinta in questo forum..
e soprattutto non è assolutamente detto che ogni tipo di algoritmo possa girare con prestazioni maggiori sul cell rispetto ad un qualsiasi altro processore, anzi, ci sono forti indizi per il contrario.
Non dimentichiamo che se ci fosse solo la difficoltà di scrivere software ottimizzato e non l'impossibilità di scrivere codice con prestazioni migliori in ogni campo allora IBM non avrebbe avuto alcun problema a gettare via il suo power 6 e a spingere su cell.
Basta ricordare l'architettura EPIC su cui è basato itanium su cui intel ha spinto moltissimo (anke se con scarsi risultati x diversi motivi).

[xeal]

Ragazzi, su, non litigate
Non voglio certo portare avanti la discussione all'infinito, ed effettivamente scrivo troppo però l'argomento è interessante, e con la scusa sono andato a rivedere un po' di cose

Veniamo all'algoritmo ottimizzato: occhio che si tratta di grafi, non di alberi. E i grafi si prestano a volte ad essere trattati come vettori/matrici, oppure con una struttura ibrida vettore-lista, che è quella adottata nell'algoritmo, più altri vettori con informazioni rilevanti. Ma come dicevo, un Cell è ottimizzato per trattare meglio i flussi di dati continui (= vettori) rispetto alle liste, anche se ha delle ottimizzazioni per ridurre il gap, e nell'algoritmo si usano degli hack per sfruttare queste ottimizzazioni più un double buffering dei dati caricati nella memoria interna del processore (e riportati in memoria centrale), per mascherare le latenze di accesso alla ram (accesso che oltretutto va programmato "a manina" ). Questo complica le cose e mi dimostra, ancora una volta, come Cell sia ottimizzato, in hardware, più per accessi sequenziali e usi specifici che per accessi casuali e utilizzi generali.

Ma veniamo (in breve) all'algoritmo: si tratta di una esplorazione "in larghezza", contrapposta all'esplorazione in profondità che si preferisce con gli alberi. E' un'algoritmo che potremmo definire quasi "brute force", perchè per un certo livello di profondità io prendo tutti i nodi e li esamino contemporaneamente, ma si presta bene per una parallelizzazione estrema, specialmente se nei livelli ci sono molti nodi (cioè se ogni nodo è collegato a molti altri nodi, anche in livelli precedenti).

Va bene per molte applicazioni con i grafi (ma non per tutte), molto meno per gli alberi, specialmente se i dati sono ordinati/ordinabili (una delle situazioni principali in cui si ricorre agli alberi, appunto), perchè so che per qualunque nodo, a sinistra avrò tutti i nodi con elementi "minori", a destra tutti quelli "maggiori", e se l'albero è ben bilanciato, ogni volta che vado a destra o a sinistra dimezzo il numero di nodi da considerare. Vero è che il bilanciamento ha un costo computazionale, però nell'algoritmo sui grafi preso in considerazione, per ottimizzare la distribuzione dei nodi alle spe e per migliorare ulteriormente l'accesso ai dati, il grafo viene preliminarmente organizzato e riordinato opportunamente (presumo quindi che una variante sugli alberi dovrebbe essere parimenti "sistemata" ).

Oltretutto, l'analisi in larghezza del grafo (o anche di un albero) può andar bene (anche se più lenta per gli alberi) se il contenuto è "fissato" prima dell'elaborazione, mentre non va bene se il contenuto è dinamico, come ad esempio nel caso di elaborazioni che utilizzano un albero per organizzare i risultati parziali, e spesso, una volta ottenuti dei risultati significativi, cancellano delle (grosse) parti dell'albero, prima di andare avanti, ottimizzando l'uso della memoria (è il caso di algoritmi di backtracing, di cui si fa largo impiego, ad esempio, nell'intelligenza artificiale e nei programmi di ottimizzazione, tipo graams).

Ma quello che più colpisce è la difficoltà nell'ottimizzazione: il codice (semplificato) di partenza si compone di 60 righe, quello finale di ben 1200!! Questo vuol dire che per spremere un Cell serve uno sforzo notevole, che diventa ancora più grande se si deve adattare il programma o a una variante (possibile in futuro) di Cell con più spe (è noto che per farlo nella maggior parte dei casi occorrerebbe riscrivere una parte del programma), oppure per farlo eseguire da più Cell (da questo punto di vista, i processori "tradizionali" scalano un po' meglio, ma non troppo). Quindi, un Cell si dimostra più adatto a scopi specifici nei quali le prestazioni ottenute valgono il prezzo di un'ottimizzazione spinta (= tempo, e quindi denaro, maggior rischio di incorrere in bug, maggiore difficoltà nella manutenzione/modifica del codice). Insomma, non è esattamente quello che si intende per general purpose. Inoltre, per ammissione degli stessi programmatori, il loro codice superottimizzato è poco leggibile, e questo contrasta con una delle regole "generali" della programmazione: all'ottimizzazione e alle prestazioni, se non strettamente necessarie, è sempre preferibile la semplicità e la leggibilità del codice (perchè con un codice poco leggibile aumentano a dismisura i problemi cui accennavo poco sopra).

Infine, farei un piccolo appunto alla "metodologia" di confronto, che annichilisce un povero P4 a 3.4 Ghz con HT. Mi sembra di capire che il P4 abbia eseguito la versione base dell'algoritmo; tuttavia, poichè l'articolo è incernierato sulle prestazioni massime ottenibili con quell'algoritmo, avrei gradito uno sforzo per ottimizzare il codice anche per il Pentium e creare una struttura dati adegeguata, come è stato fatto per il Cell, per sfruttarne bene l'HT e possibilmente anche le SSE + MMX (visto che per il Cell hanno ottimizzato in modo da eseguire dei calcoli SIMD nelle spe). Naturalmente mi aspetto ancora una "sconfitta" per la cpu monocore, però magari un risultato un po' migliore, e presumo che aggiungendo delle ottimizzazioni per il multicore (o per sfruttare più cpu) un quadcore avrebbe sfigurato ancora meno.

[Lud von Pipper]

Originariamente inviato da ^TiGeRShArK^

ecco..
quindi sei d'accordo con me che il Cell non è affatto la panacea che viene dipinta in questo forum..
e soprattutto non è assolutamente detto che ogni tipo di algoritmo possa girare con prestazioni maggiori sul cell rispetto ad un qualsiasi altro processore, anzi, ci sono forti indizi per il contrario.

No, mi sa che non hai afferrato bene la differenza tra un cell e un, diciamo X86

Il secondo è un processore NATO per esegure codice preesistente, un ibrido complesso di tecnologie CISC e RISC con Pipelines (lunghe o corte che siano) che cerca, per velocizzare i processi attraverso sofisticati meccanismi di predizione delle richieste del software: in pratica scommette su quello che il programma chiederà di fare per "mettersi avanti" con il lavoro.
Il P4 era un esempio di processore con Pipelines molto lunghe, L'A64 ha Pipes più brevi ma è più efficiente.

Il CELL è "sui generis", e penso che qui ci sia gente che può descriverlo molto meglio di me.
La potenza di calcolo, soprattutto in certi ambiti è altissima, ma in altri soffre di "semplificazione", quindi è difficile fare porting di applicazioni gia scritte.
Prendi per farti un esempio un processore RISC all'antica, come un ALPHA della Digital. La potenza di calcolo era diverse volte maggiore per esempio di un MIPS CISC montato ad esempio dalle stazioni Silicon graphic.
Eppure gli Alpha non si sono mai espansi (pur non essendo particolarmente costosi) al di fuori di una nicchia limitata di informatica perchè la loro semplicità costruttiva (relativa) obbligava i programmatori ad una programmazione di basso livello, dispendiosa e complessa.
In pratica le istruzione ridotte del processore richiedevano programmi più "dettagliati", certo non un semplice compilatore C++ se si voleva ottenere il massimo dalle prestazioni del porcessore.

Il Cell ha problemi simili: programmazione complessa e difficile, programmi completamente riscritti (e non semplicemente "portati"), sistemi operativi esistenti molto orientati ad architetture diverse dal Cell.
Anche per portare un semplice word processor si sarebbe dovuto riscriverne gran parte, cosa poco pratica in termini economici.

PS3 ha dimostrato proprio questo: il Cell che potenzialmente sarebbe docuto essere il cuore unico del sistema, in grado di calcolare la grafica, fungere da CPU centrale e da unità di gestione audio è stato affiancato da schede grafiche e cooporcessori per rendere la programmazione della consolle meno "aliena" e permettere un porting più semplice dei programmi da altre consolle (basate su evoluzioni del G4)
Non so quali prestazioni avrebbe offerto nella grafica il Cell di PS3 ma è comune opinione che nella configurazione attuale il sia molto sottosfruttato.

Power6 invece può facilmente usufruire di tutte le applicazioni gia scritte per risc6000 e generazioni successive, cosiderando che per i clienti di workstation IBM il software è uno degli investimenti più costosi.

[^TiGeRShArK^]

Originariamente inviato da Lud von Pipper

No, mi sa che non hai afferrato bene la differenza tra un cell e un, diciamo X86

bhè.. se lo dici tu

Il secondo è un processore NATO per esegure codice preesistente,

gli 8086 quale grande base di codice preesistente avevano a disposizione? quello dei 4004?

un ibrido complesso di tecnologie CISC e RISC con Pipelines (lunghe o corte che siano) che cerca, per velocizzare i processi attraverso sofisticati meccanismi di predizione delle richieste del software: in pratica scommette su quello che il programma chiederà di fare per "mettersi avanti" con il lavoro.

e questa è l'unità di branch prediction e non ha nulla a che vedere con le caratteristiche in-order o out of order di un processore
Il principio dell'out of order è ke le istruzioni vengono riorganizzate in modo da permettere alle unità di calcolo di non restare bloccate mentre è richiesto un accesso potenzialmente ad elevata latenza: ovvero un accesso alla memoria.

Il P4 era un esempio di processore con Pipelines molto lunghe, L'A64 ha Pipes più brevi ma è più efficiente.

Il CELL è "sui generis", e penso che qui ci sia gente che può descriverlo molto meglio di me.

ovvero?
che processore è un processore "sui generis"?

La potenza di calcolo, soprattutto in certi ambiti è altissima, ma in altri soffre di "semplificazione", quindi è difficile fare porting di applicazioni gia scritte.
Prendi per farti un esempio un processore RISC all'antica, come un ALPHA della Digital. La potenza di calcolo era diverse volte maggiore per esempio di un MIPS CISC montato ad esempio dalle stazioni Silicon graphic.
Eppure gli Alpha non si sono mai espansi (pur non essendo particolarmente costosi) al di fuori di una nicchia limitata di informatica perchè la loro semplicità costruttiva (relativa) obbligava i programmatori ad una programmazione di basso livello, dispendiosa e complessa.

veramente ai tempi i processori RISC dominavano di fatto il mercato dei Server.
La vera ragione della sconfitta dei RISC è stata la creazione dei processori odierni che hanno l'architettura ibrida da te citata che permette loro di tradurre le operazioni complesse CISC in micro-ops RISC che possono essere eseguite a piena velocità dall'unità di esecuzione di tipo RISC interna.
Ovviamente così facendo però si è complicato lo stage di decode ma si è anke reso possibile l'uso di tecniche "interessanti" (vedi la micro-ops fusion dei processori CORE).
Inoltre l'ottimizzazione dei compilatori ha reso praticamente inutile ricorrere alla scrittura in assembly e quindi quella da te citata non può essere la causa della scomparsa dei RISC dato che se programmi in C se hai davanti un processore CISC o un RISC non te ne frega nulla.
Tra l'altro i processori 680x0 della motorola erano MOLTO ma MOLTO + semplici da programmare in assembly dei corrispettivi INTEL.
vabbè.. a parer mio in effetti era anke + semplice l'assembly degli SPARC rispetto a quello "CISC" degli x86.. ma lì andiamo in una questione di gusti soggettivi

In pratica le istruzione ridotte del processore richiedevano programmi più "dettagliati", certo non un semplice compilatore C++ se si voleva ottenere il massimo dalle prestazioni del porcessore.

Il massimo delle prestazioni deve essere ottenuto nell'1% di codice in cui si ha lo spreco del 90% del tempo della CPU.
Scrivere tutto il codice in assembly è pura follia perchè si avranno ovviamente prestazioni peggiori rispetto ad un compilatore che conosce tutti i trucchetti e sa perfettamente come ottimizzare e ovviamente si avrò uno spreco di anni-uomo assurdo per arrivare ad un risultato peggiore.

Il Cell ha problemi simili: programmazione complessa e difficile,

Per ottimizzare adeguatamente un algoritmo in maniera da sfruttare adeguatamente le SPE sono d'accordo.

programmi completamente riscritti (e non semplicemente "portati"), sistemi operativi esistenti molto orientati ad architetture diverse dal Cell.
Anche per portare un semplice word processor si sarebbe dovuto riscriverne gran parte, cosa poco pratica in termini economici.

Perchè per un semplice word processor si sarebbe dovuto riscrivere gran parte del codice?
un word processor ha forse requisiti prestazionali spinti?
Sarà che ero abituato ad usare wordstar su un 286...
ma non credo che un word processor possa beneficiare delle SPE del cell

PS3 ha dimostrato proprio questo: il Cell che potenzialmente sarebbe docuto essere il cuore unico del sistema, in grado di calcolare la grafica, fungere da CPU centrale e da unità di gestione audio è stato affiancato da schede grafiche e cooporcessori per rendere la programmazione della consolle meno "aliena" e permettere un porting più semplice dei programmi da altre consolle (basate su evoluzioni del G4)

O forse perchè quello non era il campo di utilizzo del Cell?
Secondo voi il Cell ha risorse infinite ed è la panacea per ogni problema di programmazione se adeguatamente ottimizzato?

Non so quali prestazioni avrebbe offerto nella grafica il Cell di PS3 ma è comune opinione che nella configurazione attuale il sia molto sottosfruttato.

Se parli di grafica inteso come sfruttamento all'interno di una pipeline grafica del tutto simile a quella di una moderna GPU.. bhè.. il Cell sarebbe impallidito al confronto
Per operazioni di post-processing e di geometria invece avrebbe avuto da dire la sua.

Power6 invece può facilmente usufruire di tutte le applicazioni gia scritte per risc6000 e generazioni successive, cosiderando che per i clienti di workstation IBM il software è uno degli investimenti più costosi.

E inoltre le prestazioni del power 6 in totale, checchè se ne dica su questo forum sono maggiori rispetto al cell.
Il cell in diversi ambiti sarebbe stato superiore.
Ma una CPU come il power 6 non è pensata per lavorare in ambiti ristretti ma è una CPU pensata per dare il meglio di sè in tutti gli ambiti possibili.

Ancora sicuro ke non ho afferrato bene la differenza tra cell e x86?

[Lud von Pipper]

Originariamente inviato da ^TiGeRShArK^

bhè.. se lo dici tu

Ok, scusa, pensavo che tu veramente non avessi capito e cercavo di spiegare in termini comprensibili da tutti.
Visto che vuoi fare il brillante dimostrando tutta la tua cultura informatica, muovi pure il culo e leggi TUTTE E QUATTRO le pagine precedenti: li trovi tutto quello che vuoi sapere sull'argomento compresa la domanda con cui ci vai assillando da quattro post.

Piccola precisazione: X86 rivolto a un processore indica un processore in grado di eseguire codice di quel tipo, compreso A64, Core2, centrino e tutti i processori di quel genere.
Ovvio che se parliamo di Cell, non ha molto senso parlare di 8088 e del software sviluppato all'epoca.

Se poi sei qui per dire che il Cell non vale nulla fai pure, ma il fatto che tu non capisca non indica necessariamente che le tue tesi siano valide

[^TiGeRShArK^]

Originariamente inviato da Lud von Pipper

Ok, scusa, pensavo che tu veramente non avessi capito e cercavo di spiegare in termini comprensibili da tutti.
Visto che vuoi fare il brillante dimostrando tutta la tua cultura informatica, muovi pure il culo e leggi TUTTE E QUATTRO le pagine precedenti: li trovi tutto quello che vuoi sapere sull'argomento compresa la domanda con cui ci vai assillando da quattro post.

ehmm..
veramente ai tempi abbiamo riempito + di una 50ina di pagine parlando del cell..
quindi non è ke mi spaventino le 4 pagine..
è ke io la mia idea ce l'ho e IBM sembra confermarla in toto pensando a investire 5 anni in R&D sul power 6 piuttosto che sul cell che ora come ora semplicemente non è adatto ad essere impiegato in tutti i campi di utilizzo del power 6.

[Criceto]

Originariamente inviato da ^TiGeRShArK^

ehmm..
veramente ai tempi abbiamo riempito + di una 50ina di pagine parlando del cell..
quindi non è ke mi spaventino le 4 pagine..
è ke io la mia idea ce l'ho e IBM sembra confermarla in toto pensando a investire 5 anni in R&D sul power 6 piuttosto che sul cell che ora come ora semplicemente non è adatto ad essere impiegato in tutti i campi di utilizzo del power 6.

Anche per i Cell ci ha investito 5 anni.

Sono entrambi (Power6 e Cell) processori eccellenti, il meglio della tecnologia odierna, il Power6 è un processore dal punto di vista costruttivo senza compromessi (num. transistor, banda, cache, ecc) ma tutto sommato "tradizionale", fatto per far girare al meglio il codice esistente.

Il Cell non è così spinto a livello costruttivo (1/3 di transistor o meno), perchè nell'attuale evoluzione è nato per tutt'altro mercato, ma ha caratteristiche uniche che in molti ambiti (non così ristretti come molti pensano), con software appositamente scritto, lo può far eccellere.

Insomma io il SuperCell da desktop, con un solo core Power6, un po' meno cache, e qualche SPE (magari ottimizzata per la doppia precisione) ce lo vedrei tutto! Peccato che IBM sia uscita da quel mercato.

[xeal]

Credo che si possa (e si debba) chiudere la diatriba sul general purpose. Cell è sicuramente più generico di un "semplice" dsp (anche se un buon 70% dei suoi transistor si trovano dentro unità ottimizzate per fare un lavoro da dsp), ma per riuscire a sfruttarlo in ambiti diversi bisogna fare i salti motrali, quindi ha senso usarlo solo se il gioco vale la candela. Molto probabilmente è vero che nella PS3 è sottosfruttato, ma perchè la tipologia di applicazioni cui è destinata si adatta meglio ad altre tipologie di hardware (oltre un certo limite, non si può parallelizzare un gioco senza diventare pazzi), e per questo motivo, rispetto ai piani iniziali, il die è stato aumentato per migliorare le prestazioni dell'unico core general purpose.

Alla fine della fiera, un'architettura è vincente nel general purpose quanto più è semplice da programmare per la maggior parte delle applicazioni, ottenendo prestazioni mediamente buone senza dover tenere conto dell'architettura. Cioè, scaricando il compito delle ottimizzazioni al compilatore, guardando alle architetture di interesse in maniera il più possibile trasparente, e con un compilatore che sia anch'esso facile da scrivere. In questo, storicamente i CISC (e secondo molti il motorola 68000 va considerato come CISC, visto che la parte maggiormente in comune con i RISC è la lunghezza fissa delle istruzioni) hanno primeggiato, con i RISC che davano (e danno) il meglio sulla lunga distanza e con algoritmi che necessitano di una notevole ottimizzazione. Per questo motivo, col tempo i Risc si sono "adattati" alle esigenze del general purpose diventando meno risc: il numero di istruzioni è cresciuto notevolmente, così come la loro complessità, allontanandosi dalla definizione canonica di "reduced set, reduced instruction"; sono state introdotte circuiterie per l'esecuzione fuoriordine e la predizione dei salti; si è arrivati anche a una soluzione "ibrida" simile a quella degli attuali x86, con una unità d'esecuzione ancora più risc rispetto al set di istruzioni. Poi ci sono Risc più "classici", che riprendono l'approccio della semplicità estrema, e si prestano meglio per scopi specifici che per usi "generici", come appunto il Cell (fortemente sbilanciato in hardware per la gestione di flussi digitali).

Il problema del Cell nel general purpose non è tanto la presenza di codice in abbondanza per le architetture "precedenti", perchè in tal caso "basterebbe" un buon compilatore per risolvere in gran parte il problema, visto che un'applicazione "general purpose" non è caratterizzata da un'ottimizzazione estrema; tutt'al più si potrebbe avere un periodo di transizione con un jit, che potrebbe operare in background e impegnare un paio di spe. E nemmeno la difficoltà nel programmarlo, perchè sono sicuro che, finchè ci si limita alle tipologie di calcolo per le quali l'architettura Cell è progettata (e sbilanciata, rispetto al general purpose), come i flussi audio-video (o più in generale applicazioni con strutture dati a blocchi contigui, forte parallelizzazione e possibilmente operazioni vettoriali), allora programmare un Cell non può essere così difficile. Il problema è la difficoltà nel programmare Cell al di fuori di un ambito tutto sommato ristretto, perchè Cell soffre gli accessi casuali in memoria, e quindi bisogna inventarsi un double buffering + altri barbatrucchi; perchè le spe non hanno una cache, ma un local storage che si comporta come una specie di ram privata, e bisogna decidere "a mano" cosa conviene caricare e quando, e quando invece spostare i dati nella ram; perchè mancando la logica per ooo e branch prediction bisogna scrivere un compilatore con le alle quadrate, più complicato da realizzare rispetto ad uno per architettura più general purpose, e in alcuni casi potrebbe essere addirittura necessario scrivere un layer software per emulare le funzioni della logica ooo/bp, oppure fare molta attenzione ad evitare accuratamente salti di qualsiasi genere, trasformando un semplicissimo ciclo for in una sequenza in cui si indicano tutte le operazioni sequenzialmente (è quello che hanno fatto nell'algoritmo dei grafi!!!).

E non è tanto una questione di algoritmi ottimizzati per altre architetture, ma piuttosto di problemi di per sè poco adatti all'architettura Cell, che non solo ha bisogno di un'ottimizzazione specifica, ma in molti casi ha bisogno di molta più ottimizzazione per così dire alla base. In questo senso ha ragione TigerShark quando parla di impossibilità, però bisognerebbe chiarire un po' meglio il concetto, per evitare fraintendimenti e altre quattro pagine che rischierebbero di trasformarsi in un litigio. NON è impossibile effettuare il porting di una qualche applicazione per Cell, e NON è impossibile ottimizzare il programma in modo da sfruttare decentemente Cell, ma POTREBBE, in alcuni casi e in tempi compatibili con la vita di una persona, o anche solo con il ciclo del software, essere impossibile ottenere risultati SENSIBILMENTE MIGLIORI rispetto a quelli ottenibili, in molto meno tempo e con molta meno fatica, su altre piattaforme. Se dopo aver speso tempo, denaro, fatica, scopri che non hai guadagnato abbastanza (e questo lo scopri solo alla fine) e dovresti ottimizzare ancora, senza la certezza di riuscirci, allora rischi una reazione che è un misto di pianto, rabbia, urla, sconforto, incredibie ulk, maniaco suicida, chi più ne ha più ne metta. Insomma, finchè non ci metti le mani sul serio non sai se il gioco valga la candela.

Qundi, benchè l'architettura Cell sia in qualche modo adatta/adattabile al general purpose, usarla al di fuori dei campi per i quali è maggiormente ottimizzata non è necessariamente una buona idea. Questo perchè l'essere ottimizzato per certi scopi vuol dire che un Cell ha un'architettura sbilanciata per fare alcune cose meglio di altre, e di conseguenza se si vuole tirare fuori il massimo delle sue prestazioni anche con quelle altre, bisogna "trasformarle" in quelle che fa meglio, ma questo non è nè facile, nè possibile con certezza. E allora perchè IBM, o qualcun altro, dovrebbe pensare di usare Cell per fare tutto e il contrario di tutto, invece di fargli fare esattamente ciò che gli riesce meglio, a meno di poter predire in qualche modo gli esiti, o di avere a che fare con applicazioni che necessitano veramente di una notevole (e difficile) ottimizzazione (quindi, casi abbastanza specifici)?

In realtà potrebbe, a patto però di modificare l'architettura di Cell: un "SuperCell", con un cuore Power "completo" (lo lascerei dual core, per non ricascare nel problema delle ottimizzazioni), con tanto di logica ooo (più o meno castrata), e delle SPE diverse, capaci anche di calcoli in doppia precisione più veloci e diversamente specializzate, alcune scalari, altre vettoriali, sarebbe qualcosa di diverso da ciò che Cell è oggi, assomiglierebbe al concetto di multicore eterogeneo di amd, con dei core general purpose x86 accanto a core specializzati per fare da coprocessore (anche se nella visione di amd si dovrebbe fare in modo che per il compilatore sia semplice decidere quale core usare, sgravando il più possibile il programmatore dalle decisioni difficili). Sarebbe sicuramente una belva, e non solo per applicazioni desktop (anzi, per lo scopo avrebbe fin troppi transistor ma avrebbe senso con un processo di miniaturizzazione molto spinto). E allora potremmo fare dei ragionamenti diversi, perchè sarebbe molto meno ottimizzato per scopi specifici.

[NeatoEurope]

Originariamente inviato da bernh

Se non lo fanno evidentemente avranno i loro buoni motivi, però non mi dispiacerebbe vedere IBM entrare anche in ambito desktop a competere con AMD e Intel, servirebbe una terza azienda.

IBM che si può considerare l'inventrice dell'informatica attuale, come caratteristica ha quella di vendere i rami poco remunerativi prima che si secchino, vedi prima il settore PC, poi quello HD e di recente anche quello dei portatili.

Non scenderebbe mai direttamente in una lotta del genere ma ne rimane uno dei fulcri con tutti i suoi brevetti.

Ciao

Sèvero

[Criceto]

Originariamente inviato da xeal

Credo che si possa (e si debba) chiudere la diatriba sul general purpose.

Discorso ragionevole.

Comunque un paio di precisazioni.
La famiglia 68000 è SEMPRE stata CISC e senza ombra di dubbio.

Negli anni 80-90 i RISC (IBM, HP, SPARC, MIPS, ALPHA) erano significativamente superiori ai CISC dell'epoca, cioè in pratica ai 68k e x86 che andavano per la maggiore, ed erano utilizzati in costose workstation (SUN, SGI) e nei server. Poi, in particolare Intel e AMD, hanno inziato a ibridizzare la loro architettura colmando piano piano il gap prestazionale e spesso superando i vari RISC. Nell'altro ambito la famiglia Power di IBM ha assunto alcuni aspetti dei CISC (il numero di istruzioni, in particolare, è molto elevato). Oggi la distinzione tra CISC e RISC non è così netta come 10-15 anni fà.

Però l'architettura x86 risente comunque di una progettazione davvero iniziata male, anche in confronto degli altri CISC dell'epoca (68k) e anche con i salti mortali di cui è capace Intel per me difficilmente potrà mai competere con un'implementazione di alto livello di un'architettura partita con un approccio molto più moderno ed efficiente come la famiglia Power di IBM (quindi l'attuale Power6).

E per TigerShark, anche i MIPS di Silicon Graphics erano RISC e anche molto "puri" come tipologia.