Link alla notizia: http://www.hwupgrade.it/news/cpu/spursengine-coprocessore-ce-derivato-da-cell_22654.html

Toshiba è prossima a dare dimostrazione di un coprocessore multimediale per impieghi consumer electronics derivato direttamente dalla soluzione Cell

Click sul link per visualizzare la notizia.

Alla fine arriva! Sarebbe interessante sapere se sarà in grado di codificare
MPEG4 e/o H.264 in tempo reale, di sicuro sarebbero una killer app nei
videoregistratori di domani...

Il nome e' orribile...

ma veramente che nome orribile!!sarà il processore integrato nei wc intelligenti di domani :stordita:

tra l'altro nei piani di toshiba e sony inizialmente si pensava di utilizzare il cell con 1 solo core e 1 spe anche nei robot da cucina(che cazz dovò farci un impastotore con cell nn si sà) mentre con 3 spe si pensava di metterlo sui tv

Chissà chissà chissa.... se sta tornando l'era dei 'coprocessori'.

Non bastano + 8 core? Oo

Cmq mi sembra una cosa interessante.

già per le architetture standard a più core si fatica a trovare software decente , qui si inventano una architettura da 0 ... con quale SO girerà questa roba ?

già per le architetture standard a più core si fatica a trovare software decente , qui si inventano una architettura da 0 ... con quale SO girerà questa roba ?

Chissà chissà chissà...

magari dei semplici driver e passa la paura.

Sicuramente andrà in linux comunque, in winzozz.. chissà :P ;)

mi chiedo perchè nessuno abbia pensato a creare schede per l'elaborazione della Fisica basate su processori Cell, gia disponibili ed abbastanza economici...

Da quel che si sa questo porcessore è un mostro nei calcoli e PS3 gia si avvale della tecnologia software Ageia sulla PS3 elaborandola proprio attraverso un Cell...

si vedrà.

mi chiedo perchè nessuno abbia pensato a creare schede per l'elaborazione della Fisica basate su processori Cell, gia disponibili ed abbastanza economici...

Da quel che si sa questo porcessore è un mostro nei calcoli e PS3 gia si avvale della tecnologia software Ageia sulla PS3 elaborandola proprio attraverso un Cell...

si vedrà.

perché le schede per l'elaborazione della fisica non le vuole nessuno. Ecco perché. In ambito professionale, per i calcoli scientifici, schede ausiliarie con un cell montato sopra già ci sono

Le schede che calcolano la fisica mi sembrano una cavolata!
Non solo costano, ma non hanno supporto!
Nell'era degli n-core si potrebbe anche dedicare un core per questo calcolo diamine!
Bruttissimo nome sto coprocessore..

a quando una versione per socket F da abbinare a un opteron quad core?

Non mi ricordo come si chiamava quella tecnologia che lasciava un socket libero per coprocessori

E' *Ovvio* che se farà solo la fisica saranno soldi buttati, se invece è davvero
in grado di fare encoding h.264 senza impiegare 4 cores di un Q6600 ma
utilizzando 15Watts, sarà appetibile e tutto dipenderà dal prezzo.

a quando una versione per socket F da abbinare a un opteron quad core?

Non mi ricordo come si chiamava quella tecnologia che lasciava un socket libero per coprocessori

Ecco.. io se dovevo pensare ad una implementazione... pensavo proprio a questa. Usato come co-processore in ambienti dual socket. E pensavo proprio ad AMD. Ad ogni modo anche saldato nella sk madre non farebbe schifo, se dovesse portare a benefici. E solo 'progresso'.


E' *Ovvio* che se farà solo la fisica saranno soldi buttati, se invece è davvero
in grado di fare encoding h.264 senza impiegare 4 cores di un Q6600 ma
utilizzando 15Watts, sarà appetibile e tutto dipenderà dal prezzo.


Ecco. Infatti :)

Visti i consumi sarebbe "osceno" proporlo come scheda pci(-e)? O si va a creare un collo di bottaglia che rende necessario l'utilizzo di un socket dedicato?

Ecco.. io se dovevo pensare ad una implementazione... pensavo proprio a questa. Usato come co-processore in ambienti dual socket. E pensavo proprio ad AMD. Ad ogni modo anche saldato nella sk madre non farebbe schifo, se dovesse portare a benefici. E solo 'progresso'.

Nel render si riuscirebbe a trarre qualche beneficio o bisogna aspettare SO/driver/programmi/plug-in nuovi?

...penso che proprio per questa domanda ci vorrebbe una bella sfera di cristallo.

E mentre siamo.. dovremmo capire se sarà visto un uso PC-compliant del pezzo di silicio o se te lo troverai in altro materiale di consumo "da Tavolo" e in configurazioni "server hi-end" per altri scopi di calcolo.

Possibile utilizzo in ambito consumer (secondo me): prendo un bel A64 embedded da 8W, aggiungo due di sti "cosi" a fare da coprocessori multimediali (se uno non basta), più un paio di ingressi tv (diciamo 3 - e diciamo anche che ci basta convertire il segnale per veicolarlo ai processori, il resto via software, quindi circuiteria e costi al minimo), un paio di lettori per le schede di decodifica dei flussi in abbonamento, un ripetitorino wifi et voilà, ecco un bel decoder universale per tutti i flussi digitali e non, possibili e immaginabili (diciamo un analogico tradizionale, almeno finchè ci sarà, uno satellitare, ma anche due per chi sfrutta il doppio "occhio" nella parabola, uno per il digitale terrestre,...) e recuperare tutti i televisori di casa sfruttando tutte le tecnologie che si vogliono, e magari vedersi una partita mentre qualcun'altro guarda un film criptato (d'altronde, non mi pare che gli abbonamenti a sky e co. impongano restrizioni sul numero di utenti, all'interno della famiglia, che possono fruire contemporaneamente di contenuti diversi, succede solo "incidentalmente" per la natura del decoder, ma se con un aggeggino come quello che penso io cercassero di costringere a pagare un abbonamento per tv credo che nascerebbe un'insurrezione...). A completare, naturalmente, dei ricevitorini da collegare alle tv, diciamo tramite presa scart, con un'antennina wifi, e un processorino arm o mips per gestire le comunicazioni con il decoder e poco più (per la maggior parte delle funzioni, si comporterebbe come terminale remoto, quindi la potenza di calcolo richiesta sarebbe minima, come anche il costo, volendo - credo che si possa anche fare in modo di usare lo stesso telecomando del televisore per "navigare" tra i contenuti). IMHO non sarebbe un'idea malvagia...

Ma non vi sembra tutta una presa per i fondelli? Toshiba (sponsor principale dell'HD-DVD) e Sony (BlueRay) che collaborano per costruire cpu per riproduttori multimediali (il Cell e questo suo derivato)? La verità è che lucrano e gongolano sulla pelle dei consumatori....

Beh, se la fisica fosse implemetata bene, con effetti degni di essere visti non credo che sarebbe una cavolata...
Ageia non la vule nessuno perchè in uno sparatutto la fisica non è rilevante, ma in una simulazione tipo Raibow Six vecchia maniera direbbe al sua per il realismo...
oppure in una simulazione di guida dove potrebbe calcolare l'effetto delle buche sulle sospensioni, o magari il vento in un simulatore di volo...

Diciamo che la tecnologia se ben sfruttata sarebbe utile eccome.

Per il render, non spererei molto, le spe di cell sono troppo simili a un dsp o a uno stream processor per consentire l'elaborazione di dati random, caratteristica intrinseca delle strutture dati sfruttate dagli algoritmi di raytracing e radiosity (parliamo di liste di liste, con indirezioni multiple e frequenti accessi in memoria, niente che vada a genio a circuiti nati per elaborare flussi di dati, vettori e matrici). Tuttavia, non scriverei la parola fine, poichè con qualche ottimizzazione lato software, usandoli come coprocessori "puri", ovvero come fpu aggiuntive, questi "cosi" non li vedrei male a supporto di cpu general purpose adeguate, che organizzano il lavoro e smistano al coprocessore un po' di calcoli pesanti (a ben guardare, così ci avviciniamo al concetto di base del cell, ma con un sistema più distribuito e meglio programmabile, anche perchè l'unico core general purpose di cell è un po' troppo "leggero" per gestire questo tipo di scenari d'impiego in maniera ottimale, quindi, in definitiva, in realtà ci andiamo ad avvicinare a quella che dovrebbe essere la filosofia di Fusion).

P.S. La tecnologia che dovrebbe consentire di accostare coprocessori agli opteron si chiama torrenza; l'idea di questi cosi su pci-e non sarebbe male (del resto, torrenza si appoggia a hyper transport che, pur avendo caratteristiche diverse, si potrebbe usare in alternativa a pci express in molti casi).

Per la fisica, mi sa che per il futuro si stanno orientando, per la fascia enthusiast, verso la seconda/terza/ventunesima scheda video da collegare in sli/crossfire e dedicare ai calcoli per la fisica, appunto. Certo che un paio di questi cosi (perdonatemi la ricorrenza del termine, è che spursengine non piace troppo neanche a me :p) saldati su una schedina di espansione potrebbero cavarsela bene, se ben sfruttati, per un totale di 40W. Credo, comunque, che l'evoluzione dei "coprocessori" dedicati per la fisica passerà attraverso un set di api dedicato (tipo dx) e driver opportuni (un approccio di questo tipo, con una sorta di driver o middleware di gestione, lo troverei assai utile per sfruttare a dovere questi derivati di cell, poichè le spe sono un po' ostiche da programmare a mano - è un po' come dover decidere cosa caricare nella cache della cpu, quando spostare i dati in ram, come gestire i cache miss e scrivere tutto a manina: agli sviluppatori di videogame devi fornire un'api adeguata che ne agevoli la produttività, oppure firmano un contrattino con un sicario...).

@ Vas.ko

Sono solo multinazionali che cercano di fare profitto, si fanno la guerra quando entrano in contrasto, si vengono incontro quando gli interessi comuni collimano, tutto qui. Come diceva il saggio, pecunia non olet (o come si dice dalle mie parti, i soldi fanno tornare perfino la vista ai ciechi... - a scanso di equivoci, è solo un detto popolare molto enfatico - come a dire: figurati se qualche miliarduccio di dollari non fa accantonare per un po' le divergenze a Sony e Toshiba).

Per il rendering il Cell della PS3 è ottimo, fa quasi rendering in real time*,solo
che i 256 MB di memoria lo limitano a circa 800'000 poligoni. (queste schede sono una versione
ridotta ma avrebbero a disposizione la ram di sistema, invece)

Fonte: http://www.alphaworks.ibm.com/tech/irt

*in 720x576 con una scena comprendente riflessioni ed altro, fa 5 frames al secondo.
a 1080p fa sempre più di un frame al secondo.
http://www.alphaworks.ibm.com/tech/irt/faq#06

Metà dei core, meno della metà della frequenza.
Quindi oltre 4 volte più lento del Cell originario (ormai vecchio di qualche anno).
Non è comunque poco, ma non poi tantissimo più di quello che può dare un processore Intel di ultima generazione, magari quelli nuovi a 45nm con le SSE4 e 4 core...

Metà dei core, meno della metà della frequenza.
Quindi oltre 4 volte più lento del Cell originario (ormai vecchio di qualche anno).
Non è comunque poco, ma non poi tantissimo più di quello che può dare un processore Intel di ultima generazione, magari quelli nuovi a 45nm con le SSE4 e 4 core...
Si ma quello lo ottieni "usando" 110-120 Watt (un Q6600 a pieno carico),
qui invece ne usi 20 (per di più, non necessariamente su scheda per PC,
il target sono anche gli elettrodomestici), e per sistemi specifici è
micidialmente potente (vedi appunto encoding mpeg4 o h.264).

Di nuovo, tutto dipende dal prezzo.

Si ma quello lo ottieni "usando" 110-120 Watt (un Q6600 a pieno carico),
qui invece ne usi 20 (per di più, non necessariamente su scheda per PC,
il target sono anche gli elettrodomestici), e per sistemi specifici è
micidialmente potente (vedi appunto encoding mpeg4 o h.264).

Di nuovo, tutto dipende dal prezzo.Il confronto non sarebbe 110W contro 20W, ma bisogna contare che è una scheda aggiuntiva, e quindi succhierà comunque una data potenza della CPU, e anche in idle consumerà corrente.
Comunque gli utenti desktop hanno già le schede video per questi compiti, questo miniCELL mi sembra inutile.
Possibile utilizzo in ambito consumer (secondo me): prendo un bel A64 embedded da 8W, aggiungo due di sti "cosi" a fare da coprocessori multimediali (se uno non basta), più un paio di ingressi tv (diciamo 3 - e diciamo anche che ci basta convertire il segnale per veicolarlo ai processori, il resto via software, quindi circuiteria e costi al minimo), un paio di lettori per le schede di decodifica dei flussi in abbonamento, un ripetitorino wifi et voilà, ecco un bel decoder universale per tutti i flussi digitali e non, possibili e immaginabili (diciamo un analogico tradizionale, almeno finchè ci sarà, uno satellitare, ma anche due per chi sfrutta il doppio "occhio" nella parabola, uno per il digitale terrestre,...) e recuperare tutti i televisori di casa sfruttando tutte le tecnologie che si vogliono, e magari vedersi una partita mentre qualcun'altro guarda un film criptato (d'altronde, non mi pare che gli abbonamenti a sky e co. impongano restrizioni sul numero di utenti, all'interno della famiglia, che possono fruire contemporaneamente di contenuti diversi, succede solo "incidentalmente" per la natura del decoder, ma se con un aggeggino come quello che penso io cercassero di costringere a pagare un abbonamento per tv credo che nascerebbe un'insurrezione...). A completare, naturalmente, dei ricevitorini da collegare alle tv, diciamo tramite presa scart, con un'antennina wifi, e un processorino arm o mips per gestire le comunicazioni con il decoder e poco più (per la maggior parte delle funzioni, si comporterebbe come terminale remoto, quindi la potenza di calcolo richiesta sarebbe minima, come anche il costo, volendo - credo che si possa anche fare in modo di usare lo stesso telecomando del televisore per "navigare" tra i contenuti). IMHO non sarebbe un'idea malvagia...L'idea è buona, quello di cui parli sarebbe comunque "Card Sharing", pratica fra il legale e l'illegale (si può fare, ma i gestori non vogliono).Chissà chissà chissa.... se sta tornando l'era dei 'coprocessori'.

Non bastano + 8 core? Oo

Cmq mi sembra una cosa interessante.Io sono molto dubbioso a riguardo della validità di questi "accrocchi" (e vi rientra Torrenza) nel mondo PC.
Con la creazione delle istruzioni SIMD, ovvero 3DNOW! prima e MMX poi, si è visto che è stato possibile aumentare le prestazioni delle CPU general purpose anche in ambiti specifici.
Anche Intel è scettica a riguardo della validità di queste soluzioni esterne, dato che ha recentemente acquisito Havok, gli sviluppatori del motore fisico attualmente leader del mercato.
Il prossimo passo sarà l'implementazione del core GPU affianco la CPU, e non credo questo avrà solo benefici in ambito video, visto che le architetture ATI e NVIDIA ci hanno dimostrato la loro bravura anche nel calcolo in virgola mobile.
Immagino quindi il futuro vedrà un sempre maggior "egocentrismo" delle CPU, il progetto Tera Scale di Intel ci da infatti un assaggio di quello a cui andremo incontro: centinaia di core che, a richiesta, possono specializzarsi in uno o più compiti, lavorando all'unisono.
Questo mini-Cell è destinato agli scopi già evidenziati dall'articolo: ricevitori SAT e DTT, lettori DVD e HD.

Si ma quello lo ottieni "usando" 110-120 Watt (un Q6600 a pieno carico),
qui invece ne usi 20 (per di più, non necessariamente su scheda per PC,
il target sono anche gli elettrodomestici), e per sistemi specifici è
micidialmente potente (vedi appunto encoding mpeg4 o h.264).


Non ha la PPE (il Core PowerPC) come il Cell, quindi è strettamente un coprocessore. Quindi dentro una TV o un lettore HD-DVD da solo non ce lo puoi mettere. Dentro un computer di ultima generazione le sue prestazioni non apportano molto (penso che un quad core Intel a 45nm e SSE 4 alla fine sia anche più veloce sul vettoriale).
Quindi, a che serve?!

Sarebbe meglio un Cell "vero" a 45nm, sta ancora a 90, credo...
Purtroppo Sony ha avuto una bella batosta con la PS3 e tutte le sue manie di grandezza con il Cell si stanno ridimensionando: ora vogliono anche vendere la fabbrica che avevano fatto appositamente per fabbricarlo e di ulteriori sviluppi, ovviamente, non se ne parla.

Io credo che la rincorsa agli n core di un processore general purpose soprattutto in ambito desktop sia un po' una presa in giro. A parte il supporto dal lato software generico ci vuole anche un buon supporto del sistema operativo e da questo punto di vista XP e compagnia bella fanno finta di garantirla.

L'idea invece dei coprocessori ha molto senso, ma sempre non in ambito home. Sono molto utili per applicazioni specifiche specialmente in ambiente sever. Basta pensare a una macchina che deve gestire la crittografia per un ambiente protetto quanto potrebbe guadagnare da un coprocessore che esegue esclusivamente calcoli crittografici.

Non per niente AMD ha previsto nelle future architetture slot e connessioni dedicate a coprocessori.

Non ha la PPE (il Core PowerPC) come il Cell, quindi è strettamente un coprocessore. Quindi dentro una TV o un lettore HD-DVD da solo non ce lo puoi mettere. Dentro un computer di ultima generazione le sue prestazioni non apportano molto (penso che un quad core Intel a 45nm e SSE 4 alla fine sia anche più veloce sul vettoriale).
Quindi, a che serve?!

Sarebbe meglio un Cell "vero" a 45nm, sta ancora a 90, credo...
Purtroppo Sony ha avuto una bella batosta con la PS3 e tutte le sue manie di grandezza con il Cell si stanno ridimensionando: ora vogliono anche vendere la fabbrica che avevano fatto appositamente per fabbricarlo e di ulteriori sviluppi, ovviamente, non se ne parla.

Io la vedo sotto tutto un altro aspetto :)
Cioè guardando all'evoluzione di quello che ci entra in casa (non parlo di macchine in industriali o di server blade o di calcolo distribuito dove comunque i numeri parlano chiaro per il Cell ovviamente) il rendere un videoregistratore qualcosa di diverso da quello che abbiamo oggi o il frigo o l'amplificatore dolby o tutti gli elettrodomenstici insieme nel modo in cui operano
mi fa ringraziare il cielo che esista mamma ibm.
Cioè se anche toshiba pensa che implementare le spu (che sono mi pare le unità vettoriali delle spe o perlomeno una parte delle spe
ma mancano dettagli su questo progetto) sia conveniente oltre ad essere compatibile con quello che forse io mi aspetto dal futuro
allora direi che il progetto Cell è tutt'altro che fallimentare.
Questa di toshiba è un tipo di implementazione che non dice nulla su quello che può essere il futuro,
è un implementazione di basso profilo perlomeno da come è presentata.
E lo dico pensando a cosa sarà cell quando avrà una ppe diversa da un g5 castrato o con funzionalità di risparmio energetico
accostabili a un core2 o a un phenom, ma malgrado questo mettere un core2 o qualcosa di simile in un video recorder ad alta
definizione non credo proprio sia cosa conveniente
altrimenti lo avrebbero già fatto l'altro ieri, la potenza gp del pc non serve a una beneamata in quasi tutti gli aparecchi elettronici che hai in casa, i quali di certo possono e faranno qualcosa di più domani.
Ma pensa te che attualmente questo non serve perchè anche cosi va bene e costa maledettamente poco, ci si concentra sui tool di sviluppo e non su 6000 shader processor e multi gp-gpu con pci express e bus indegni di questo nome su pc con alimentatori da mille megawatt.
Ps3 è praticamente un passaggio obbligato,
già adesso è una macchina mostruosamente flessibile (anche molto potente in alcuni ambiti),
lo sviluppo di adesso servirà per il futuro visto che hanno capito tutti dopo dove bisogna andare,
capisci che la partita è ben diversa dal vendere un milione o 5 milioni di copie per una sh che fa un videogame o anche l'alta definizione.
Cioè 5 milioni di unità vendute (e speranze ben maggiori per il futuro comunque), il progetto torrenza e intel
che il multiprocessore gp vuole farselo da solo, fusion etc non sono male come cosa,
l'unica differenza è che la soluzione ibm (con l'ottimo esecutore sony che ci guadagna nei più svariati ambiti) è in campo da un bel po,
molta gente lavora su un prodotto finito con caratteristiche da presa in giro per come siamo abituati: un g5 castrato e 7 spe
(una in meno) che fanno paura,
l'architetturra del cell è entrata nelle case di tutti almeno sotto forma di slide.
Certo esistono dsp molto più veloci in determinati ambiti delle spe ma essi si sognano la flessibilità di una spe,
esistono processori più veloci in gp del Cell ma essi si sognano la velocità in virgola mobile del Cell..
si passa cioè all'idea di un processore flessibile e modulabile a seconda degli ambiti di utilizzo
e comunque questo di toshiba non è che un tassello del mosaico
spero di essermi spiegato in qualche modo :Prrr:

Mah, la descrizione che fa ibm del suo ray-tracer interattivo è fuorviante, lascia quasi intendere che sia in grado di fare in poche frazioni di secondo quello che una render farm fa in diverse ore, e questo è semplicemente falso, a meno di sacrificare la qualità del risultato. Del resto, esistono anche altri progetti simili (ad esempio, openrt ottiene risultati prestazionali tuttosommato comparabili con un ray-tracer sulla carta più "fedele" sfruttando un dual P3 a 800 mhz e 256 mb di sdram) e tutti devono scendere più o meno a compromessi per ottenere una velocità d'esecuzione real time, oltre ad avere degli engine superottimizzati e meno flessibili. In particolare, mi pare di capire che questo di ibm si appoggi pesantemente al modello di illuminamento di Phong, che non ha molto a che fare con il ray tracing, più alcuni elementi (del ray tracing e non) più o meno approssimati che aggiungono realismo calcolando riflessioni, rifrazioni, ombre e influenza reciproca (in particolare, l'ambient occlusion).

Il risultato è veramente notevole, ma non credo proprio che reggerebbe il confronto con un ray tracing two pass puro, con distribuzione stocastica dei raggi che partono dal pixel (che da risultati migliori, per quanto riguarda l'antialiasing, del multisampling di cui parla ibm), più radiosity con subsequencing, che sono gli algoritmi usati (con varianti e ottimizzazioni) per ottenere un rendering fotorealistico e richiedono elaborazioni molto lunghe. Insomma, questo engine è comunque lento per essere sfruttato in un videogame e un po' "castrato" per interessare a una grossa produzione cinematografica, decisamente più orientata verso il fotorealismo e meno verso il real time, ma comunque è interessante.

Oltretutto, nel filmato su youtube linkato da ibm, con 3 ps3 che lavorano insieme, si vedono degli artefatti che mi fanno pensare ad un trucco che alcuni algoritmi di questo tipo usano per dare meglio l'impressione del real time: calcolano la scena in maniera incrementale visualizzando i risultati parziali e aggiornando spesso l'immagine a video mentre il rendering complessivo impiega un certo tempo (ma potrei sbagliare: potrebbe essere anche un problema legato all'esecuzione distribuita e all'immaturità dell'algoritmo per questi casi, ma non penso, visto che ibm ha sviluppato il ray-tracer basandosi molto sui suoi bladecenter, sistemi con due cell).

@ bonzuccio

Mi sa che hai le idee un po' confuse: se per flessibilità intendi la possibilità di sfruttare bene (o almeno decentemente) una cpu in molti ambiti diversi tra di loro, e senza patricolari problemi nel passare da un ambito all'altro, allora stai parlando di una cpu general purpose "pura", non certo di una fortemente sbilanciata verso funzionalità da dsp/stream processor quale è cell. Cell in realtà è un processore molto più specializzato di quanto non voglia far credere, altro che grande flessibilità.

Sulle spe si sa abbastanza: sono formate da

- una spu: l'unità di calcolo vettoriale, con due pipeline (che usi contemporaneamente solo con coppie di istruzioni indipendenti) e molti registri vettoriali, che servono indistintamente per interi e float;

- una piccola ram: hai letto bene, si tratta di memoria ram, non di cache, e va gestita come tale, cioè devi decidere tu cosa metterci, farci entrare i dati che ti servono, stare attento a non perderli (e quindi gestire in maniera diretta le letture e le scritture dalla memoria centrale e quelli che per un processore "normale" sarebbero dei cache miss, tutte cose che un x86, ma anche un g5 (non il core gp di cell), fa da sè ), devi spostare manualmente i dati da questa ram ai registri interni della spu e viceversa, per ottimizzare l'esecuzione, e gestire a mano anche le comunicazioni tra le spe;

- un piccolo controller DMA che serve per gestire il traffico di dati tra la ram della spe e la spu della spe, e per interfacciarsi con il bus di comunicazione tra i vari elementi.

Insomma, un cell è un po' come un "computerino monoblocco": ha un certo numero di processori, di cui alcuni specializzati e uno più generico che detta le "regole del gioco" (è una sorta di multiprocessing asimmetrico), una memoria interna dedicata a ciascun (co)processore, un bus di comunicazione tra i processori e un'interfaccia verso il "mondo esterno". Questo contribuisce ad una notevolissima libertà nelle scelte del programmatore (che si potrebbe interpretare, questa si, come flessibilità), ma lo rende spaventosamente difficile da programmare (ad esempio, può essere necessario trasformare un ciclo in una serie di operazioni sequenziali per sfruttare al meglio i registri della spu, cosa che, nel caso di molte iterazioni, rende il codice non solo "brutto" e difficile da scrivere, ma anche "brutto" e difficile da leggere e gestire per quanto riguarda bug, modifiche ecc.).

Il riferimento alle gpu, poi, non l'ho capito. Per i giochi, c'è un layer di astrazione (direct x, opengl e driver) e si, ci si concentra sui tool di sviluppo piuttosto che sulle caratteristiche specifiche, facendo poi qualche ottimizzazione specifica, ma niente di paragonabile alla difficoltà di programmare un cell; nel gp-gpu c'è qualche difficoltà in più a seconda di ciò che si vuol fare, se si può vettorializzare molto e ricondursi in qualche modo alle operazioni degli shader in modo simile a quanto farebbe un gioco (ma non è certo una cosa banale da farsi, e neanche tanto conveniente) allora si potrebbe anche pensare di appoggiarsi ad una libreria grafica per alcune funzioni e al driver, diversamente ci sono i tool messi a disposizione, che in alcuni casi semplificano le cose, ma in generale si è in una situazione simile a quella che si ha con cell (una gpu è un processore estremamente specializzato, quindi non facile da programmare per ambiti diversi dal proprio, AL PARI di Cell).

Poi dici che la ps3 è "mostruosamente flessibile", ma è "molto potente in alcuni ambiti": ti contraddici. Una macchina è veramente flessibile quando esprime una potenza mediamente uguale e sufficientemente vicina al proprio limite in tutti gli ambiti in cui si pensa di usarla; una macchina che, invece, risulta molto potente in pochi ambiti e molto meno in tutti gli altri, con un divario sensibile, evidentemente non può essere sfruttata adeguatamente al di fuori di pochi ambiti nei quali darà il meglio di sè, cioè è una macchina specializzata, e la specializzazione non va d'accordo con la flessibilità. A meno che tu per flessibilità non intenda un qualche sinonimo di modularità, cioè la possibilità, prevista nel progetto, di creare delle varianti di cell adattabili a diversi contesti, ma in questo caso parleremmo di una modularità del progetto, non delle sue incarnazioni, e la ps3 è solo una delle tante possibili incarnazioni di cell.

La PPE di Cell NON è un g5 "castrato", nel senso che ha esattamente le caratteristiche che sono state individuate come necessarie in fase di progettazione: eseguire codice generico per avviare il sistema operativo e smistare i calcoli vettoriali(zzati) alle spe, non deve fare altro, quindi non serve niente di più complesso. La questione cruciale in questa scelta è stata la volontà di realizzare un multicore dalle caratteristiche essenziali, ispirandosi a quello che era lo spirito originario dei processori RISC, riducendo all'osso la complessita circuitale dei singoli elementi per scaricarla sul codice e, quindi, sul compilatore (in parte) e sull'abilità del programmatore (che deve fare i salti mortali).

Un Cell con una PPE diversa non sarebbe più cell come lo conosciamo adesso, sarebbe un'altra cpu, un po' meno sbilanciata verso le funzionalità da dsp e un po' più general purpose, più vicina, insomma alla filosofia che sta alla base del progetto fusion, ma solo in parte, perchè rimarrebbe comunque più difficile da programmare.

Poi, questa parte mi ha lasciato un po' basito:

Cioè 5 milioni di unità vendute (e speranze ben maggiori per il futuro comunque), il progetto torrenza e intel
che il multiprocessore gp vuole farselo da solo, fusion etc non sono male come cosa,
l'unica differenza è che la soluzione ibm (con l'ottimo esecutore sony che ci guadagna nei più svariati ambiti) è in campo da un bel po,

????
Guarda che IBM, Intel, AMD, Sun, Digital e tanti altri il multiprocessore, con o senza coprocessori, l'hanno fatto da taaaanto tempo, forse volevi dire multicore? A parte che non è vero che è in giro da più tempo, perchè esistevano multicore molto prima della realizzazione di Cell, ma comunque un multicore non è altro che un insieme di più processori accorpati insieme, il "multiprocessore" lo fai anche con più processori (volendo anche con più core per ciascuno) in uno stesso sistema o in un cluster, e in questa incarnazione esiste dalla notte dei tempi, anche sottoforma di più unità vettoriali che formano un solo processore (vedi i primi supercomputer cray). Dunque dov'è che sarebbe in giro da più tempo? Lo usano sulla maggior parte dei server grandi e piccoli? no. Lo usano nei datacenter? no. Lo usano nei supercomputer della top 500? no, la usano i power e derivati di ibm, gli opteron di amd, gli Itanium e gli Xeon di intel (non ricordo se ci sono anche i niagara di sun, qualcuno dovrebbe esserci). Dov'è che si trova Cell? Nella ps3, una consol, che la gente compra come giocattolo e scopre che può far vedere i film, e qualcuno anche che ci gira folding@home? in qualche server di ibm con chiara vocazione multimediale? Non mi sembrano certo risultati straordinari, tanto da far rivalutare quasi in negativo i progetti di amd e intel (che nascono per altri ambiti oltre tutto), come se l'idea di intel di fare un multiprocessore "da solo" fosse una cosa fuori dal mondo, come se chissà cos'altro avesse fatto negli ultimi decenni. E non direi proprio che sony ci guadagni un bel po' in tutti gli ambiti, visto che ha mandato a monte i progetti per la produzione diretta di Cell.

Una spe non è altro che un dsp, ed è anche un dsp molto veloce in tutti i suoi ambiti, cioè quando fa da dsp (fare da dsp significa elaborare flussi continui di dati, cioè in buona sostanza fare calcolo vettoriale e matriciale: non a caso i dsp più veloci attualmente hanno unità di calcolo vettoriale). E come ogni buon dsp non è per niente flessibile (rendo atto però che è più flessibile di molti dsp nella misura in cui questi sono specializzati spesso o per calcoli interi o floating point). E la potenza reale in virgola mobile di cell, all'atto pratico, è inferiore a quella sbandierata con i numeroni sui GFLOPS: a parte il fatto che si tratta di una misura della potenza massima con tutte le unità di calcolo attive contemporaneamente e sfruttate al massimo, cosa che nella realtà non succederà praticamente mai, questa potenza di calcolo è misurata sui calcoli in singola precisione, che guardacaso è quella più usata dai dsp, mentre se si devono elaborare dei double precision la potenza di calcolo di Cell risulta dimezzata, comunque notevole, ma dimezzata (ancora convinto che una spe sia così flessibile?).

L'unica parte flessibile di Cell è la PPE, ma da questo punto di vista è si troppo castrata per poter fare di cell una cpu veramente general purpose (lo è, ma è sbilanciata verso funzionalità molto specializzate). Ti pregherei comunque di non fraintendermi, io non intendo ridicolizzare Cell: lo considero un buon processore, anzi ottimo, per quello che sa fare, e non stento a trovargli dei possibili impieghi: oltre al decoder universale di cui parlavo prima (unico per tutta la casa), vedrei bene una versione di cell con qualche spe in meno (e forse con qualche piccola modifica), un paio di core general purpose "completi" e qualche ottimizzazione per la virtualizzazione, come una sorta di "piattaforma universale", un po' come volevano essere le cpu Transmeta, utilizzando i core gp per le elaborazioni principali, e qualche spe per tradurre le istruzioni dal formato di altre macchine (x86, ppc, sparc, itanium, ecc., ma anche bytecode: java, .net) a quello proprio, in background, in modo tale da consentire l'esecuzione virtualmente di qualsiasi applicazione, nativa e non, con codice nativo prodotto on-the-fly molto velocemente, con qualche accorgimento nel sistema operativo. Insomma, non considero certo itanium un progetto fallimentare, ma non è certo il processorone cannibale che invaderà tutti i campi sbaragliando la concorrenza. Potrà dire la sua in alcuni contesti, meno in altri.

Colpa mia visto che volevo dire tante cose e alla fine ho messo troppa carne al fuoco

..
..A meno che tu per flessibilità non intenda un qualche sinonimo di modularità, cioè la possibilità, prevista nel progetto, di creare delle varianti di cell adattabili a diversi contesti, ma in questo caso parleremmo di una modularità del progetto, non delle sue incarnazioni, e la ps3 è solo una delle tante possibili incarnazioni di cell.


E alla fine convergi, proprio questo intendevo..,
ovviamente non immagino Cell come unità singola che lavora in ambito gp nei pc di casa (linux ci va bene comunque con un po di memoria di massa vicino, le spe comunque vanno in dma anche verso la xdr su ps3) o come una gpu classica (gliela puoi affiancare certo)
A che serve? Già le cpu odierne fanno anche troppo bene il loro lavoro

In ambito pc standardizzi mediante la chiamata a funzioni prefabbricate dal produttore per far sfruttare al meglio il proprio hardware (che è complesso, dispendioso e mirato all'uso generico tipico di un pc)
con cell fa la stessa cosa il programmatore o l'azienda che tira fuori la libreria che sfrutta 3 10 20 spe in parallelo appartenenti a un cell o a più cell in parallelo o affiancati a una o più cpu classiche o a una gpu oppure addirittura un cell sezionato cui rimangono solo le spu per fare una cosa ben determinata.. encoding, filtri e quant'altro..
questa è flessibilità,
è flessibilità trasformare con un cell che costa 2 soldi in economia di scala (5 milioni) una console di gioco in una postazione multimediale con le bolas

..
La PPE di Cell NON è un g5 "castrato", nel senso che ha esattamente le caratteristiche che sono state individuate come necessarie in fase di progettazione: eseguire codice generico per avviare il sistema operativo e smistare i calcoli vettoriali(zzati) alle spe, non deve fare altro, quindi non serve niente di più complesso. La questione cruciale in questa scelta è stata la volontà di realizzare un multicore dalle caratteristiche essenziali, ispirandosi a quello che era lo spirito originario dei processori RISC, riducendo all'osso la complessita circuitale dei singoli elementi per scaricarla sul codice e, quindi, sul compilatore (in parte) e sull'abilità del programmatore (che deve fare i salti mortali).


Sono daccordo ma questa del g5 è una implementazione particolare oltre ad essere certo quella attuale :) ,
se potenzi il lato ppe con un processore gp con le OoO ti avvicini a un utilizzo generico tipico del pc con al contempo unità dedicate agli utilizzi specifici di una work station ad esempio

..
Un Cell con una PPE diversa non sarebbe più cell come lo conosciamo adesso, sarebbe un'altra cpu, un po' meno sbilanciata verso le funzionalità da dsp e un po' più general purpose, più vicina, insomma alla filosofia che sta alla base del progetto fusion, ma solo in parte, perchè rimarrebbe comunque più difficile da programmare.


Mica solo quello di ps3 è Cell, è difficile da programmare come è difficile fare le sse4, un compilatore Intel o le dx10 o le librerie di fusion

Guarda che IBM, Intel, AMD, Sun, Digital e tanti altri il multiprocessore, con o senza coprocessori, l'hanno fatto da taaaanto tempo, forse volevi dire multicore?


Si, intendevo multicore :muro:

.. questa potenza di calcolo è misurata sui calcoli in singola precisione, che guardacaso è quella più usata dai dsp, mentre se si devono elaborare dei double precision la potenza di calcolo di Cell risulta dimezzata, comunque notevole, ma dimezzata (ancora convinto che una spe sia così flessibile?).


Continui a vedere in Cell quello montato su ps3 che prima di tutto ha una spe in meno, sui server adesso montano cell orientati ai calcoli in doppia precisione.. :)

Sto cercando di dire che il concetto di una unità coordinatrice di n unità dedicate adesso è il Cell che è anche dire alla rovescia che..
Cell è oggi il CONCETTO di una unità coordinatrice di n unità dedicate e costruite per ambiti ben precisi (e quindi con la potenza necessaria a quel determinato ambito)
questo è sinonimo di flessibilità e la ottieni geenralizzando il concetto e pensanfo alle applicazioni.
Non è che se una unità è dedicata non è flessibile, a ben vedere è proprio il contrario
chiaro che se sta dentro una work station o dentro un videoregistratore o come coprocessore non la puoi staccare e metterla dove vuoi.. ci vorrebe infatti un connettore standard a tutti gli apparecchi.. mumble mumble.. scherzo,
a parte le seghe mentali è una cosa che non puoi fare TANTOMENO con un core2 o con un phenom che in questo senso sono unità dedicate al pc o a macchine che fanno tante cose..
quindi in questo senso la cpu del pc è un concetto rigido e poco flessibile rispetto alla potenza ed alla economia di unità dedicate.. e parallele :)
No perchè Cell sarà pure difficile da programmare ma se almeno un po più di software iniziasse a sfruttare i dual core oggi in commercio non sarebbe comunque male... :muro:

Temo di non poterti rispondere prima di lunedì :p

In ambito pc standardizzi mediante la chiamata a funzioni prefabbricate dal produttore per far sfruttare al meglio il proprio hardware (che è complesso, dispendioso e mirato all'uso generico tipico di un pc)
con cell fa la stessa cosa il programmatore o l'azienda che tira fuori la libreria che sfrutta 3 10 20 spe in parallelo appartenenti a un cell o a più cell in parallelo o affiancati a una o più cpu classiche o a una gpu oppure addirittura un cell sezionato cui rimangono solo le spu per fare una cosa ben determinata.. encoding, filtri e quant'altro..

E ti pare poca come differenza? Il produttore dell'hardware, diciamo gpu, conosce perfettamente il suo hardware e può scrivere un driver ottimizzato (che può essere un'operazione molto complicata: vedi i problemi nell'ottimizzazione dei driver di R600, concettualmente non troppo dissimile da cell) da affiancare a una qualche libreria (ma posso fermarmi al driver, perchè comunque, nel caso della gpu, sia l'hw sia il driver sono modellati in base alle specifiche di dx e ogl) in base al quale gli sviluppatori scriveranno con minore difficolta le applicazioni per lo specifico campo di utilizzo dell'hardware in questione; se vuoi programmare un cell per eseguire qualcosa di diverso da "encoding, filtri e quant'altro", cioè al di fuori dei campi in cui eccelle per sua natura, devi prima creare l'equivalente del driver + libreria per il tuo ambito d'uso e poi scrivere l'applicazione che si appoggia ad essi (o fare un "fritto misto" nell'applicazione), oppure appoggiarti a una qualche libreria resa disponibile da altri, sempre che si adatti al tuo problema specifico, perchè la soluzione ottimale per te potrebbe essere troppo specifica, e in genere lo sarà, perchè stiamo cercando di usare come gp una cpu che è da un lato, piuttosto specializzata, dall'altro molto difficile da programmare, così come lo sono le gpu per il gp-gpu (le librerie messe a disposizione dai produttori per lo scopo sono molto "generiche" e lasciano una mole notevole di lavoro al programmatore "finale", che non le gradisce molto).

Il nocciolo della questione stà tutto nella complessità che una cpu general purpose, flessibile in ogni singola incarnazione, usa per rendere più semplice il lavoro del programmatore, e che in cell non si trova per una precisa scelta progettuale, e questo è uno dei motivi che rendono cell difficile da programmare. Un altro è che ogni accesso alla memoria centrale blocca l'esecuzione dell'unità che l'ha richiesta, e per questo motivo o elabori flussi di dati continui, come per l'encoding, oppure devi fare i salti mortali per adattare le tue strutture dati e i tuoi algoritmi alle esigenze di cell, mascherando "a mano" le latenze introdotte dagli accessi in memoria.

è flessibilità trasformare con un cell che costa 2 soldi in economia di scala (5 milioni) una console di gioco in una postazione multimediale con le bolas

Questa flessibilità diventa meno evidente se guardi la situazione al contrario: usi un processore "multimediale" con le bolas per adattarlo in una console, con risultati non totalmente soddisfacenti, prova ne sia che il progetto originale del cell per ps3 era ancora più "castrato", con meno transistor e un ppe più semplice, poi, in seguito alle lamentele degli sviluppatori è stato un po' migliorato per il general purpose, ma solo un po' (e ci sono ancora lamentele, perchè i videogame non si prestano molto nè ad una parallelizzazione massiccia, nè al calcolo vettoriale).

Sono daccordo ma questa del g5 è una implementazione particolare oltre ad essere certo quella attuale

A parte che, facendo un calcolo a spanne sui transistor, la ppe sembrerebbe assomigliare più a un g4 o a un g3 (non ricordo esattamente), la questione è che l'unità "gp" di cell (quello di ps3, ok) non è semplicemente una cpu gp castrata, nel senso che non hanno solo ridotto la potenza di calcolo, tolto altivec, ridotto la cache, ma hanno rimosso totalmente la logica out-of-order, il branch predictor, ecc. rendendolo concettualmente simile ai primi powerpc, e questo per una precisa scelta progettuale.

Durante le prime presentazioni del progetto Cell fu posta molta enfasi proprio su questo orientameno risc-style, e sulla libertà concessa al programmatore di fare e disfare di tutto a suo piacimento (libertà che però ha un costo notevole in termini di difficoltà nella programmazione), caratteristica essenziale dell'architettura del Cell Broadcasting Engine (ci sono un paio di articoli molto chiari, al riguardo, su ArsTechnica, praticamente i primi 2 che parlano di cell). Aggiungere unità di calcolo "full genral purpose" stravolgerebbe radicalmente questo orientamento: è per questo che dico che un cell con una ppe ooo non sarebbe più cell così come lo conosciamo ed è stato ideato (al di là di come è stato implementato in ps3), ed è per questo che dubito fortemente che vedremo mai un cell con unità di calcolo fortemente orientate al general purpose, a meno di cambi di rotta "epocali" (paragonabili, per intenderci, al passaggio di Apple da ppc a x86), anche se mi piacerebbe vedere qualcosa del genere. Ed è anche per questo che dicevo che un cell con ppe gp sarebbe concettualmente una specie di ibrido tra il cell di ps3 e fusion, ma non sarebbe più il cell da qui è stata ricavata la cpu di ps3, perchè andrebbe ben oltre il tipo di flessibilità architetturale messa in conto dai progettisti.

Del resto, se nei progetti originari di cell fosse rientrata la possibilità di aggiungere un core gp completo ciò sarebbe avvenuto già in ps3, proprio perchè questa incarnazione di Cell non è certo la più adatta ad un videogame. In seguito alle prime lamentele degli sviluppatori, i progettisti avrebbero potuto togliere una o due spe ed eliminare le "castrazioni" dalla ppe, oppure aggiungerne un altra identica, perchè in questo modo avrebbero reso cell più simile a xenon, la quale cpu, pur essendo in-order, ha dei core sufficientemente generici (contrariamente alle spe, piuttosto ostiche da sfruttare per i giochi) da facilitarne la programmazione nello specifico ambito delle consol. Invece si sono "limitati" a potenziare complessivamente la cpu già realizzata (in particolare la ppe) con una ventina di milioni di transistor, lasciandone invariate le caratteristiche di base, e questo mi fa pensare che il progetto-Cell abbia una flessibilità minore di quanto si possa immaginare, almeno nelle intenzioni originarie e nei piani attuali (se in futuro questi piani dovessero cambiare, come dicevo, si avrebbe uno stravolgimento tale a livello di microarchitettura che continuare a usare il termine "cell" avrebbe solo un significato di continuità storica, perchè cambierebbe radicalmente il modo in cui il processore deve essere progrmmato).

Mica solo quello di ps3 è Cell, è difficile da programmare come è difficile fare le sse4, un compilatore Intel o le dx10 o le librerie di fusion

Le SSEx sono difficili da programmare perchè sono unità vettoriali che trasformano, quando usate, un x86 in una specie di dsp, aumentandone, ad esempio, le prestazioni in ambito multimediale. La difficoltà è dovuta al fatto che non puoi affidarti alla capacità di ottimizzazione di un compilatore, ma devi modificare i tuoi algoritmi e le tue strutture dati per vettorializzare al massimo i tuoi calcoli: si tratta di una ottimizzazione al livello della logica del programma, non della traduzione di questa logica in routine efficienti in linguaggio macchina (in realtà, i compilatori recenti cercano di individuare delle sequenze di istruzioni convertibili in istruzioni simd, ma non fanno certo miracoli).

Cell introduce una difficoltà simile in quanto fortemente orientato al calcolo vettoriale, ma presenta anche qualche complicazione in più: con le sse puoi gestire direttamente i prefetch nella cache, l'uso dei registri, e naturalmente puoi anche lavorare direttamente in assembly, ma non sei "costretto" a fare niente di tutto ciò, perchè i registri li gestisce bene il compilatore (e li riarrangia il processore), il prefetcher della cpu gestisce la cache in maniera ottimale, mentre il branch predictor e lo scheduler organizzano dinamicamente il lavoro in modo da non trovarsi (quasi) mai a doversi rigirare i pollici; con cell, invece, se vuoi ottenere risultati almeno decenti, devi gestire "a mano" i registri e il local storage, non riceverai nessun aiuto a runtime e il compilatore più di tanto non può aiutarti, dato che in fase di progettazione si è scelto di lasciare a te, programmatore, il massimo controllo possibile sull'hw, e questo ti impone di tener conto dei minimi dettagli e di ottimizzare tutto il tuo codice (= tempo e fatica con risultati incerti) [spero converrai con me che una spe con branch predictor, prefetcher, cache tradizionale e logica per il riordino delle istruzioni non sarebbe più una spe, ma qualcosa di profondamente diverso dall'unità vettoriale del progetto cell]. In definitiva, cell ti "costringe" ad operare costantemente ad un livello di astrazione logica più basso (forse questo concetto sarà più chiaro in seguito).

Veniamo al compilatore: questo, si, è un compito difficile da svolgere su qualsiasi piattaforma, perchè richiede una notevole ottimizzazione ad un livello logico molto basso, ma c'è una differenza fondamentale, cioè la prospettiva in base alla quale si "scarica" la difficoltà nello svolgere alcuni compiti all'accoppiata compilatore + cpu oppure a quella compilatore + programmatore.

Nel "mondo" dei processori veramente general purpose, la maggiore complessità architetturale della cpu serve per sgravare il programmatore sia dell'applicazione "finale", sia del compilatore, da alcuni compiti, come ad esempio la gestione della cache, o la linearizzazione spinta del codice (= eliminazione dei salti): si sceglie, cioè, la prima strada. Il compilatore eseguirà il caricamento nella cache al più all'inizio, poi la cpu sarà perfettamente in grado di gestire il caricamento e i cache miss in totale autonomia e con risultati egregi. Il compilatore deve gestire i registri interni, ma si tratta di questioni ben note, di problematiche già risolte negli anni con dei pattern generici sufficientemente efficienti; in più, per fare questo, cioè per decidere cosa mettere nei registri e cosa tenere in ram, non si curerà molto della cache, la quale è gestita ottimamente dal processore: non deve "combattere" con una piccola memoria "quasi tampone" da gestire in tutto e per tutto, da tenere sempre piena e da swappare con la memoria centrale all'occorrenza, ma può far finta di avere a disposizione una quantità di ram infinita (entro i limiti dello spazio indirizzabile). Il compilatore deve trasformare le istruzioni ad alto livello in un insieme efficiente (= il più possibile ridotto e veloce) di istruzioni in linguaggio macchina (ma possiamo fermarci a ragionare in assembly, tanto la traduzione in opcode è immediata), e lo fa applicando dei pattern di "decisione" abbastanza standardizzati, perchè si tratta ancora di problematiche ben note; deve inoltre linearizzare il codice, rendere indipendenti le istruzioni e raggrupparle adeguatamente, ma non occorrono i salti mortali, perchè comunque l'ottimizzazione ideale non può prescindere dalla situazione contingente, interna, della cpu a runtime, quindi il compito più importante, in questo senso, lo svolgerà la logica ooo, insieme al branch predictor; a questo aggiungiamo le istruzioni condizionali non di salto (cmov e le altre) che, se ben sfruttate, consentono in molti casi di semplificare i blocchi di istruzioni con (molti) salti, per cui il compito del compilatore risulta ulteriormente semplificato (e quindi anche quello di chi scrive il compilatore).

In definitiva, un compilatore con ottimizzazioni generiche è in grado di produrre un buon codice per tutte le microarchitetture della stessa famiglia (ad esempio, indistintamente per gli a64 e per i p4), garantendo prestazioni più che decenti a qualsiasi applicazione, e aggiungere delle differenziazioni specifiche, per ottimizzare ulteriormente il codice prodotto, non è certo un'impresa epica.

Cell, invece, adotta la soluzione opposta: abbraccia la filosofia risc e scarica tutte le "grane" sull'accoppiata compilatore + programmatore (principalmente su quest'ultimo). Il compilatore dovrebbe avere il compito più gravoso, ma quasi paradossalmente può fare ben poco, perchè la particolare architettura delle SPE di Cell lascia una notevolissima libertà (e, in un certo senso, flessibilità) nel loro sfruttamento, libertà che però ha un costo: molti dei problemi relativi all'ottimizzazione del codice finiscono per essere risolvibili solo ad un più alto livello logico, e quindi ricadono sulle spalle del team di svilupppo dell'applicazione "finale". Di conseguenza, quelle che sono le scelte operate in un ambito non saranno più valide in un altro, e con estrema difficoltà si può pensare a una libreria di base sufficientemente produttiva o a delle ottimizzazioni sufficientemente standard da poter agevolare il lavoro già a partire dal compilatore. Ad esempio, bisognerà ottimizzare gli accessi in memoria per mascherarne le latenze e non lasciare il processore a rigirarsi i pollici, e a tal fine conta molto il tipo di strutture dati con cui si ha a che fare, la loro dimensione, oltre alla frequenza degli accessi; inoltre, il local storage delle spe da gestire in toto da un lato costituisce un vantaggio in termini di libertà e flessibilità potenziale, dall'altro rende più difficile il compito del programmatore e ancora più specifiche (=dipendenti dalla singola applicazione) le ottimizzazioni.

Certo, tu potresti dirmi che si può aggiungere la logica ooo alla spu, ma questo, oltre ad essere già un primo stravolgimento del progetto, non risolverebbe le difficoltà di programmazione delle spe; puoi ancora pensare di modificare le spe e di aggiungere, ad esempio, un branch predictor + uno scheduler elementare, o anche solo trasformare la ram in una vera cache, ma rendiamoci conto che facendo tutto ciò smetteremmo di parlare di Cell e cominceremmo a parlare di Fusion. Da questo punto di vista, infatti, i due progetti sono diametralmente opposti, con il secondo che, pur introducendo dei coprocessori matematici (e presumibilmente vettoriali), manterrà intatta la filosofia cisc per sgravare il più possibile il programmatore dalle ottimizzazioni di più basso livello: l'obbiettivo è quello di lasciare al programmatore la possibilità di ragionare (per quanto possibile) in maniera semplice, sapendo che i vari blocchi di codice (o i diversi thread) verranno eseguiti in maniera ottimale (perchè il compilatore si occuperà di smistare adeguatamente le istruzioni, ma si potrebbe arrivare ad una logica interna che assolva, in parte, questo compito). Su ars technica, oltre alla descrizione delle scelte progettuali alla base di cell, puoi trovare anche una interessante intervista ad un esponente di amd sulle differenze di base tra cell e fusion (però bisogna cercare un po', anche tra gli articoli più vecchi, per trovare tutto il materiale, in particolare su cell). Del resto, questo tipo di indirizzo salta all'occhio immediatamente se si vanno a considerare alcuni progetti (e anche brevetti) di amd, come quello relativo alla condivisione della cache tra cpu e gpu.

Ma vediamo un paio di esempi per vedere un po' meglio le differenze "all'opera".

In precedenza si parlava di un ray-tracer realtime che sfrutta cell. Ne esiste uno simile, ottimizzato per le sse e l'esecuzione parallela, nel mondo degli x86: OpenRT, sviluppato all'università di Saarland; nelle pubblicazioni tecniche relative sono stati esposti i principi seguiti per ottimizzare e velocizzare gli algoritmi implementati. Una parte delle scelte operate ha riguardato l'uso delle sse, quindi la scelta di elaborare quattro raggi in parallelo, raggruppati secondo un certo criterio, e l'adattamento allo scopo dell'albero da esplorare ricorsivamente, dimensionando opportunamente alcuni dati; fin qui, il livello di difficoltà nell'ottimizzazione dell'algoritmo è paragonabile a quanto necessario per un cell, trattandosi dello sfruttamento adeguato di unità vettoriali. Un'altra parte riguarda la gestione degli accessi in memoria, che costituiscono un collo di bottiglia ben maggiore rispetto alla potenza di calcolo della cpu: data la natura della cache di un x86, e l'efficienza con cui viene gestita dalla cpu a runtime, la scelta più corretta è lasciare che il processore faccia ciò che deve senza interferire, limitandosi a strutturare opportunamente i dati più importanti per facilitarne il caricamento nella cache (ciò equivale ad allinearli alla lunghezza di una linea di cache o suoi multipli, quindi 256bit) E questo nonostante la possibilità di forzare il prefetch dei dati nella cache mediante istruzioni sse: una gestione di questo tipo si baserebbe su una previsione dei possibili scenari di runtime che, giocoforza, non potrebbe essere completa, quindi sarebbe una risorsa estrema, da considerarsi superflua in presenza di un buon algoritmo, cioè un algoritmo semplice abbastanza da non interferire con il normale funzionamento del processore (in questo modo scala meglio al variare delle sue caratteristiche: pensa ad esempio che una cpu con una cache più grande o più piccola di quella che vuoi gestire potrebbe far saltare i tuoi calcoli), ma ben congeniato in relazione al problema che risolve, e con dati ben strutturati.

Chiaramente, questo non è possibile con un Cell, perchè il local storage delle spe non ha blocchi fissi al suo interno e non viene gestio autonomamente, quindi puoi strutturare i tuoi dati come ti pare e caricarli al momento che ti pare più opportuno, e quindi puoi fare un fine tuning che una cache di un x86 non ti consetirebbe, cioè sei più libero di ricercare il grado di efficienza che preferisci, ma il problema è che sei costretto a farlo a prescindere, anche se tutta quest libertà non ti serve, quindi un algoritmo semplice diventa difficile, quindi devi lavorare molto di più per ottimizzare il tuo codice o anche solo per eseguirlo correttamente, perchè devi prestare attenzione anche a come sistemare nel local storage blocchi di dati di differenti dimensioni, a come spostarli, a come sostituirli all'occorrenza con altri di dimensioni potenzialmente diverse, prestando attenzione alla coerenza dei dati nella memoria centrale, e inoltre vincoli le tue scelte alle caratteristiche della particolare variante del progetto-Cell con cui stai lavorando, perchè una variazione nella dimensione del local storage di una o più spe in una nuova versione di Cell potrebbe verosimilmente costringerti a riscrivere ampie porzioni di codice.

Ma quanto sarà difficile adattare un algoritmo per l'elaborazione di dati sparsi in memoria ad un Cell? Un po' di tempo fa discutevamo di un "esperimento" svolto da alcuni ricercatori per "portare" su cell un algoritmo di esplorazione di un grafo e massimizzarne le prestazioni per questa architettura. Si partiva da una implementazione semplice, da una sessantina di righe in C, che dava prestazioni relativamente basse ma dignitose su un P4 (ma sarebbe stato opportuno un minimo di ottimizzazione per migliorarne le prestazioni anche per l'architettura x86, se si fosse voluto fare un confronto "serio" ), per arrivare a risultati velocistici veramente notevoli con un Cell, a patto però di trasformare le circa 60 righe complessive iniziali in ben 1200 (!!!) linee di codice, con una strutturazione dei dati studiata ad hoc (mista vettore-lista per i dati del grafo più dei vettori con delle informazioni rilevanti per un accesso più rapido), una sezione di codice per il riordino dei dati nel grafo (solitamente si fa con gli alberi e con risultati diciamo migliori), in modo da minimizzare gli accessi random, un meccanismo di duble buffering dei dati da e verso la memoria, per mascherare le spe e non lasciarle ad aspettare i dati, una trasformazione spinta dei loop in blocchi sequenziali, e un bel po' di assembly, ottenendo un sorgente, a detta degli stessi sviluppatori, che pure enfatizzavano il loro risultato, praticamente illegibile...

Continui a vedere in Cell quello montato su ps3

Si, è vero, nel punto che hai ripreso avevo in mente il Cell della ps3 (sapevo comunque che era nei progetti un miglioramento della logica circuitale per le operazioni in doppia precisione), ma principalmente per due motivi. Il primo è che in alcuni punti del tuo post precedente mi era sembrato che attribuissi a questa incarnazione di cell un ruolo fondamentale quale precursore di tutte le altre versioni: non è così, perchè quei 5 milioni non sono comunque un numero sufficiente per pensare ad una specie di "porting selvaggio" e frenetico di applicazioni su Cell, con eserciti di programmatori che cercano di ottimizzare tutto il codice presente, passato e futuro e di creare librerie di base per facilitare l'adozione in massa di Cell, perchè le scelte operate/operabili con un gruppo di applicazioni o una singola applicazione non è detto che siano valide anche in altri ambiti (anzi, tipicamente non lo saranno) e perchè la necessità di preoccoparsi di questioni non di "altissimo livello logico" vincola i risultati ottenuti con il cell di ps3 al cell di ps3, e non andranno bene per versioni successive e diverse (vedi l'esempio della spe con un diverso quantitativo di "ram privata" che ti costringe a riscrivere le sezioni del tuo codice che la gestiscono). Il secondo consiste in quanto ho esposto in precedenza: c'è un limite inevitabile alla flessibilità dell'architettura Cell, dovuto alla filosofia di base del progetto, che impedirà ad una qualsiasi incarnazione futura di essere troppo diversa da quelle attuali, perchè altrimenti il progetto sarebbe snaturato e non si potrebbe più considerarlo ragionevolmente come una sua evoluzione "naturale".

a parte le seghe mentali è una cosa che non puoi fare TANTOMENO con un core2 o con un phenom che in questo senso sono unità dedicate al pc o a macchine che fanno tante cose..
quindi in questo senso la cpu del pc è un concetto rigido e poco flessibile rispetto alla potenza ed alla economia di unità dedicate.. e parallele

Mai sentito parlare di processori embedded? Gli xscale di intel, i geode di amd, le varie famiglie via (che però hanno un costo sproporzionato, quindi sono una storia a parte) sono "processorini" x86, con potenza di calcolo variabile e consumi massimi ridicoli, da pochi watt (con una soglia superiore di 15-20w per le versioni più veloci) se non inferiore al watt (per quelle meno prestanti), che puoi mettere praticamente dovunque, in un chiosco interattivo, cioè praticamente un computer che dovrà svolgere poche o una sola funzione (come dare informazioni), in un bancomat, in un terminale dummy da collegare a un mainframe per usi aziendali; te li ritrovi in alcuni palmari, e volendo anche per uno smartphone vanno benone (puoi dire che si tratta di "telefoni" che in realtà assomigliano molto a un piccolo pc, ma sempre di dispositivi limitati e destinati alla comunicazione stiamo parlando), e vanno bene anche per un navigatore gps; li ritrovi anche in apparecchiature di controllo industriali, e puoi metterli tranquillamente anche in un ruter/firewall hardware variamente dimensionato, o in un access point wifi, e la lista potrebbe continuare aggiungendo tutti i campi in cui generalmente si usano cpu arm o mips, non troppo veloci ma dai bassi consumi; nell'ottica della domotica, potresti anche metterli in un elettrodomestico come un frigorifero. In ogni caso ti troveresti a "combattere" con architetture più o meno castrate, ma molto simili a quelle impiegate nei pc come nei server, cioè con degli x86 che in tutti gli ambiti ti presentano la stessa facilità di programmazione: a me questa sembra una notevole flessibilità (per me un'architettura è veramente flessibile quando si presta bene a diversi ambiti senza richiedere degli stravolgimenti).

Quanto alla potenza di unità dedicate: in genere si operano scelte diametralmente opposte. Ad esempio, per gestire un hd o un lettore/masterizzatore da pc (ma anche un lettore da tavolo - non vale sempre però in questo caso) difficilmente si progetta una logica ad hoc (= dedicata), ma si preferisce usare processorini (in alcuni casi molto "-ini" ) generici che fanno girare un firmware specifico. Un hw dedicato serve in ambiti particolari e ristretti: una scheda video svolge dei compiti limitati ed è ottimizzata per questi, così come un videoregistratore o un lettore dvd/hd-dvd/bd deve fare encoding/decoding audio-video, che guardacaso è un tipico compito da dsp, e guardacaso una spe è un dsp vettoriale a tutti gli effetti. Per come la vedo io, il concetto di hw dedicato non va molto d'accordo con quello di hw flessibile.

Quanto al parallelo (rispondo anche all'ultima parte): la difficoltà nella programmazione parallela non è un problema "intrinseco" di un'architettura, bensì una questione legata al tipo di applicazione che si sta scrivendo. Non tutti gli algoritmi si possono parallelizzare, e anche quelli per cui è possibile non scalano necessariamente bene in funzione del numero di core/processori, perchè in molti casi la programmazione lineare e la logica deterministica impediscono di andare oltre un certo limite. Bisogna sempre ricordare che il 10% del codice richiede il 90% del tempo di esecuzione, e se proprio questo 10% deve finire in un "megathread", parallelizzare il resto non porterebbe vantaggi e anzi, in alcuni casi, potrebbe perfino diventare controproducente (ma si finirà per farlo comunque, per dire "anche il mio programma sfrutta n core" ). In ambito desktop, per molte applicazioni il multicore non serve, come non serve un aumento di potenza, per altre si farà il possibile (sui giochi si sta già facendo, l'encoding video praticamente è pronto da sempre); in generale, per vedere l'utilità di un dual core non si deve guardare alla singola applicazione, ma all'aumento di produttività e di reattività del sistema che si può avere sfruttando più applicativi contemporaneamente (non necessariamente "pesanti" ).

Spero di essere stato chiaro, perchè conciso proprio non mi riesce :p

.

.

Ho letto tutto, grazie mille ;)
Tante fonti di approfondimento, un paio di passaggi in cui mi sembra hai un po schivato la mia convinzione che servirà forza bruta a basso consumo in tanti campi e per questo il calcolo parallelo sarà il futuro e obbligherà al mettere da parte molte abitudini e punti fermi del passato..
mi hai convinto decisamente sulla poca flessibilità di Cell se lo si pensa come una architettura che cambia come quella dei pc, a cambiare non sarà l'hardware ma il software che dovrà essere ingegnerizzato in un certo modo,
se cambia cambia il fattore di parallelizzazione (il numero di spe) e poco altro (anche se quel poco altro dovesse risolvere un sacco di problemi) e in quest'ultimo caso dovrebbe esserci un compilatore che traduce o semplifica il vecchio nel nuovo,
continuo a pensare che ad esempio le sse di un pc sono poca cosa rispetto al riuscire a sfruttare delle unità dedicate in parallelo,
il Cell è fatto per l'encoding e il decoding (http://www-03.ibm.com/industries/media/doc/content/news/pressrelease/2416733111.html ),
credo anche che ci siano dei pattern di utilizzo specifici che si tradurranno in librerie che a loro volta saranno sfruttabili in modo parametrico in tool di sviluppo che possano così facilitare l'utilizzo e l'integrazione in funzione di un hardware statico da sfruttare, il problema si sposta quindi a livello software certo ma questo bisognerà fare imho, niente è più flessibile del software specie quando è buggato :cool: :D

Chissà chissà chissà...

magari dei semplici driver e passa la paura.

Sicuramente andrà in linux comunque, in winzozz.. chissà :P ;)

utilissimo far girare linux su un coprocessore :asd:

Ho letto tutto, grazie mille ;)
Tante fonti di approfondimento, un paio di passaggi in cui mi sembra hai un po schivato la mia convinzione che servirà forza bruta a basso consumo in tanti campi e per questo il calcolo parallelo sarà il futuro e obbligherà al mettere da parte molte abitudini e punti fermi del passato..
mi hai convinto decisamente sulla poca flessibilità di Cell se lo si pensa come una architettura che cambia come quella dei pc, a cambiare non sarà l'hardware ma il software che dovrà essere ingegnerizzato in un certo modo,
se cambia cambia il fattore di parallelizzazione (il numero di spe) e poco altro (anche se quel poco altro dovesse risolvere un sacco di problemi) e in quest'ultimo caso dovrebbe esserci un compilatore che traduce o semplifica il vecchio nel nuovo,
continuo a pensare che ad esempio le sse di un pc sono poca cosa rispetto al riuscire a sfruttare delle unità dedicate in parallelo,
il Cell è fatto per l'encoding e il decoding (http://www-03.ibm.com/industries/media/doc/content/news/pressrelease/2416733111.html ),
credo anche che ci siano dei pattern di utilizzo specifici che si tradurranno in librerie che a loro volta saranno sfruttabili in modo parametrico in tool di sviluppo che possano così facilitare l'utilizzo e l'integrazione in funzione di un hardware statico da sfruttare, il problema si sposta quindi a livello software certo ma questo bisognerà fare imho, niente è più flessibile del software specie quando è buggato :cool: :D
incrementare di 20 volte il numero di righe di codice necessarie per svolgere un'operazione equivale spannometricamente ad aumentare di 20 volte il numero di bug presenti nel software.
Ma in realtà io penso che la dipendenza non è proprio lineare, dato che arrivati a certe dimensioni di codice, nel caso in cui non sia PERFETTAMENTE ingegnerizzato, il numero di bug tende a crescere esponenzialmente.
Almeno tutto ciò secondo la mia esperienza :p

incrementare di 20 volte il numero di righe di codice necessarie per svolgere un'operazione equivale spannometricamente ad aumentare di 20 volte il numero di bug presenti nel software.
Ma in realtà io penso che la dipendenza non è proprio lineare, dato che arrivati a certe dimensioni di codice, nel caso in cui non sia PERFETTAMENTE ingegnerizzato, il numero di bug tende a crescere esponenzialmente.
Almeno tutto ciò secondo la mia esperienza :p

Ma anche gli hardware hanno dei bug che poi vengono risolti coi vari step produttivi, anche i driver li hanno, per l'aggiornamento del chipset l'ultima volta sono stato costrtetto al formattone del pc, per le schede video sono costretti al tuning sul singolo gioco e si hanno migliaia di righe di codice per far girare bene coj piuttosto che battlefield, non voglio immaginare il mazzo che si fanno in amd-ati per tirare su R600 ottimizzando un codice non ottimizzato per la propria piattaforma..
sulla crescita esponenziale concordo in pieno la vivo tutti i giorni anche io

incrementare di 20 volte il numero di righe di codice necessarie per svolgere un'operazione equivale spannometricamente ad aumentare di 20 volte il numero di bug presenti nel software.
Ma in realtà io penso che la dipendenza non è proprio lineare, dato che arrivati a certe dimensioni di codice, nel caso in cui non sia PERFETTAMENTE ingegnerizzato, il numero di bug tende a crescere esponenzialmente.
Almeno tutto ciò secondo la mia esperienza :p

Certo non ci scrivi tutti i programmi con le SPU cercando di ottimizzarli al massimo.
Però ottimizzare quelle librerie di sistema usate da tutti gli altri programmi non è male (ad. es. le librerie matematiche, quelle per il trattamento di suono/video/immagini, codec, ecc).

E' come scriverle in assembler. Certo sarà 20 volte più difficile ma le prestazioni sono superiori e ne beneficiano tutti i programmi che usano quelle librerie. Scrivendole magari in assembler per un processore general-pourpose guadagni 2-3x di velocità. Scrivendole per le SPU guadagni 10-20x.
Per esempio già oggi OS X ha un "accelerate framework (http://developer.apple.com/performance/accelerateframework.html)" che utilizza le unità vettoriali dei processori PPC/Intel.

Certo non ci scrivi tutti i programmi con le SPU cercando di ottimizzarli al massimo.
Però ottimizzare quelle librerie di sistema usate da tutti gli altri programmi non è male (ad. es. le librerie matematiche, quelle per il trattamento di suono/video/immagini, codec, ecc).

E' come scriverle in assembler. Certo sarà 20 volte più difficile ma le prestazioni sono superiori e ne beneficiano tutti i programmi che usano quelle librerie. Scrivendole magari in assembler per un processore general-pourpose guadagni 2-3x di velocità. Scrivendole per le SPU guadagni 10-20x.
Per esempio già oggi OS X ha un "accelerate framework (http://developer.apple.com/performance/accelerateframework.html)" che utilizza le unità vettoriali dei processori PPC/Intel.

programmare gli spe non è poi così difficile. E' possibile farlo in C++, e la differenza principale con la programmazione su un procio tradizionale è che qui ci sono delle librerie che introducono funzioni per il calcolo SIMD. Si può programmare un spe come se fosse un processore normale, solo che i veri vantaggi li vedi utilizzandoli per calcoli simd con le apposite librerie, altrimenti la mancanza dell'esecuzione out-of-order, del register renaming e di tutte le altre ottimizzazioni per l'esecuzione general purpose si fanno sentire pesantemente.

Io credo che la rincorsa agli n core di un processore general purpose soprattutto in ambito desktop sia un po' una presa in giro. A parte il supporto dal lato software generico ci vuole anche un buon supporto del sistema operativo e da questo punto di vista XP e compagnia bella fanno finta di garantirla.

L'idea invece dei coprocessori ha molto senso, ma sempre non in ambito home. Sono molto utili per applicazioni specifiche specialmente in ambiente sever. Basta pensare a una macchina che deve gestire la crittografia per un ambiente protetto quanto potrebbe guadagnare da un coprocessore che esegue esclusivamente calcoli crittografici.

Non per niente AMD ha previsto nelle future architetture slot e connessioni dedicate a coprocessori.http://www.theinquirer.net/gb/inquirer/news/2007/02/09/meet-larrabee-intels-answer-to-a-gpu

http://www.theinquirer.net/gb/inquirer/news/2007/02/09/meet-larrabee-intels-answer-to-a-gpu

"What are those cores? They are not GPUs, they are x86 'mini-cores', basically small dumb in order cores with a staggeringly short pipeline. They also have four threads per core, so a total of 64 threads per "CGPU". To make this work as a GPU, you need instructions, vector instructions, so there is a hugely wide vector unit strapped on to it. The instruction set, an x86 extension for those paying attention, will have a lot of the functionality of a GPU."..

"You use the same tools to program the GPU as you do the CPU, using the same mnemonics, and the same everything. It also makes things a snap to use the GPU as an extension to the main CPU."

E' l'anti Cell per antonomasia ma credo sia un'idea abbastanza impraticabile perchè avresti in partenza una cpu più lenta delle attuali e una gpu più lenta delle attuali, troppo ambiziosa come idea,
fusion è più interessante da questo punto di vista, anche se molti ci vedono un qualcosa di low cost (tipo le gpu integrate di adesso) a ben guardare risolve la necessità di una unità gp ottimizzata che si appoggia (tramite i driver) a delle unità dedicate quando gli servono calcoli di un certo tipo.. larabee non mi pare ne carne ne pesce insomma.. :banned:

programmare gli spe non è poi così difficile. E' possibile farlo in C++, e la differenza principale con la programmazione su un procio tradizionale è che qui ci sono delle librerie che introducono funzioni per il calcolo SIMD. Si può programmare un spe come se fosse un processore normale, solo che i veri vantaggi li vedi utilizzandoli per calcoli simd con le apposite librerie, altrimenti la mancanza dell'esecuzione out-of-order, del register renaming e di tutte le altre ottimizzazioni per l'esecuzione general purpose si fanno sentire pesantemente.

Oppure devi fare i salti mortali per ottimizzare il codice, vettorializzare gli algoritmi non "simd-friendly" (come nel caso dell'esplorazione del grafo), mascherare le latenze della memoria, e tirare fuori delle prestazioni decenti, cioè in tutti quei campi in cui non puoi fare una vettorializzazione spinta (e avvantaggiarti delle istruzioni simd) programmare le unità spe diventa difficile :p

Poi, trascuri forse un po' il problema della gestione della piccola ram privata di una spe, ma questo fa parte in fondo delle questioni relative alla programmazione "non-simd addattata all'unità simd", perchè in tutti quei casi in cui le unità simd sono vantaggiose avrai generalmente a che fare con blocchi continui di dati, di cui puoi semplicemente prenderne delle "porzioni" di dimensioni opportune e "schiaffarle" nel local storage per l'elaborazione. E guarda caso, stiamo parlando, in pratica, di tutte le applicazioni in cui si elaborano immagini, suoni, video e simili ;)

larabee non mi pare ne carne ne pesce insomma..

A me invece disporre di molti core semplici ma duttili (nel senso di gp) mi ispira alcune idee, anche se in un contesto diverso.

Prima faccio un "piccolo" preambolo. Come, mi pare, ho accennato in precedenza, lo sfruttamento di molti core non è banalmente possibile per tutti gli algoritmi, perchè non tutti si prestano facilmente ad una parallelizzazione spinta, ma in generale, per sfuttare molti core bisogna elaborare molti task in contemporanea. La situazione si complica per le unità vettoriali (simd), perchè queste "impongono" una parallelizzazione non a livello di "blocchi funzionali", ma di istruzioni indipendenti e per di più uguali su dati diversi (è il concetto di single instruction - multiple data); di conseguenza, al di fuori di pochi ambiti ristretti, potrebbero avere un senso nell'esecuzione parallela di più compiti uguali e semplici (ad esempio, per più "utenti", da intendere anche come processi, thread o agenti, in una architettura software di tipo master-slave, che ha senso in alcuni ambiti dell'ubiquitous computing).

Questo se vediamo la questione dalla prospettiva della programmazione lineare e deterministica; ma se pensiamo alla logica fuzzy e alle tecniche di intelligenza artificiale, e alla programmazione non deterministica con linguaggi come il prolog, allora il discorso potrebbe cambiare.

Ad esempio, se con un processo di miniaturizzazione spinta (e altri accorgimenti tecnici) potessimo realizzare a basso costo un chip, sulla falsariga di larrabee, con un centinaio di questi piccoli x86 (mantenendo i 4 thread a testa), e disponendo di una memoria sufficientemente veloce ed economica, potremmo pensare di esplorare in parallelo i vari rami di un branch e, con degli accorgimenti opportuni, l'albero di backtracing nella ricerca delle relazioni (e quindi dei risultati) corretti.

Con l'approccio simd, penso che si possano implementare reti neurali (meglio se già addestrate) tuttosommato elementari (ma non troppo), accorpando in una singola istruzione il calcolo del contributo parziale a un output di un input di ciascun neurone artificiale, per un gruppo di elementi di un certo livello della rete (cioè, preso un livello della rete, supposto che la mia pipeline simd sia in grado di elaborare un'istruzione float su 8 reali a 16bit, prendo 8 elementi del livello e accorpo i loro input in dei vettori da 128bit, così con una singola istruzione elaboro un risultato parziale per tutti gli 8 elementi, e ripeto fino a costruire il vettore degli output; oppure, elaboro un solo neurone alla volta, ma costruisco in un colpo solo l'intero vettore degli output di quel neurone).

Ma tutto ciò assumerà veramente un senso solo se e quando disporremo di computer quantistici, con la tecnologia attuale pensare di ricondurre praticamente tutto alla programmazione logica e alle reti neurali è un discorso che lascia un po' il tempo che trova...

Pensate forse che Ubuntu e Vista siano davvero nomi migliori?
;-)