Newsgroup: it.comp.os.dibattiti
Titolo: Curiosità sui server IBM con processore Cell

Qualcuno di voi ha mai avuto occasione di vedere/usare un IBM Blade QS21 ? 
Sono i blade server di IBM che montano i processori Cell (usati nella 
Playstation 3).
Penso che siano utilizzabili solo con Linux, ma chi li compra cosa ci fa 
girare? Che tipo di applicazioni? Sono ottimizzate per il processore Cell 
fino a che punto?
Le mie sono solo curiosit� perch� questo procesore mi ha sempre affascinato 
sin dall'inizio del suo sviluppo .. Mi sarebbe piaciuto vederlo anche in 
sistemi desktop, magari sarebbe stato interessante vedere le performance con 
programmi CAD/rendering ..
Grazie per le risposte 

 programmi CAD/rendering ..
Una mezza SPE riesce a fare quello che ad un core2
non riesce...
Esiste un demo, di IBM, dove Cell fa, mi pare ray
tracing, in tempo reale, di una sequenza con un
automobile rossa fiammante... :-)
bye,
-- 
piergiorgio

 non riesce...
certo, per quanto riguarda solo e soltanto i calcoli in floating point 
*NON* double.
Un processore x desktop deve fare anche altre cose, non penso che un 
dekstop con cell avrebbe tutte ste prestazioni. Un'architettura simile 
serve nelle GPU magari... ma infatti gia' si parla di GPU x accelerare 
il floating point! :-)

 il floating point! :-)
E` alquanto diverso, dato che le GPU sono estremamente e
strettamente parallele, ma solo parallele.
Cell e` un pelo piu` complesso, puo` operare in parallelo,
ma anche in "pipeline", per cosi` dire.
Inoltre, il fatto che ogni SPE abbia una sua memoria
locale e` sicuramente un vantaggio rispetto ad una GPU.
bye,
-- 
piergiorgio

 fino a che punto?
Servono per i tornei aziendali di SuperMario!

 locale e` sicuramente un vantaggio rispetto ad una GPU.
Mbeh e' risaputo che le GPU odierne hanno *pipeline* multiple, anche se 
ovviamente non sono prestanti come gli SPE se usate come processori per 
il floating point: del resto per ora e' un utilizzo secondario, 
principalmente sono progettate per la grafica. Anche se in futuro le 
cose probabilmente cambieranno... :-)

 locale e` sicuramente un vantaggio rispetto ad una GPU.
Non per dire, ma anche una scheda video ha memoria locale, in genere.
Siamo in pieno NUMA, ma conviene abituarcisi.
-- 
-riko

 siano degli sprovveduti (ma anche in AMD e Intel), e non e' cosi'! :-)
Allora, per prima cosa l'OP chiedeva proprio di calcolo
scientifico, secondo, l'architettura x86, visto che
continui a tirarla in ballo, e` la piu` *scadente* che
esista sulla piazza per qualunque uso.
Quindi non mi azzarderei a fare un confronto con questi,
dato che si perde su tutti i fronti: potenza di calcolo
vs. silicio usato, mips vs. consumi, etc.
In generale, Cell e` stato progettato con uno scopo ben
preciso, cioe` quello di massimizzare la capacita` di
calcolo puro a parita` di silicio usato.
La soluzione che implementano non e` nuova, e` noto da
anni o forse decenni, che il multicore dedicato e` il
metodo migliore per tale scopo (TMS320C80).
Tanto e` vero che anche intel si sta muovendo in
quella direzione.
E persino le GPU possono essere considerate, pur nelle
loro limitate applicazioni, una soluzione del genere.
E nota che le GPU non credo abbiano branch prediction,
anzi, forse non hanno neanche branch...
D'altro canto un Cell ha un PPC che, bene o male, si
puo` usare per uso desktop, anche se non ne vedo il
motivo, dato che occupa circa 1/3 del silicio sul chip.
bye,
-- 
piergiorgio

 Non per dire, ma anche una scheda video ha memoria locale, in genere.
Ma e` condivisa con *tutte* le unita` di calcolo.
bye,
-- 
piergiorgio

 vs. silicio usato, mips vs. consumi, etc.
sulla carta sono completamente d'accordo, anche se x86 ha
una desitï¿œ di codice maggiore dei risc concorrenti in virtï¿œ
della sua codica a lunghezza variabile, e questo fa in
modo che mediamente piï¿œ codice risieda in cache. Una
caratteristica negativa che ha un risvolto positivo.
In ogni caso, Intel&AMD con quello che c'hanno speso e continuano
a spenderci sono riuscite letteralmente a far volare un elefante
e sotto alcuni aspetti anche meglio degli altri volatili..

 e sotto alcuni aspetti anche meglio degli altri volatili..
Questo sicuramente, se gli stessi investimenti si
fossero avuti, chesso`, sui 68000, oggi sarebbero
sicuramente ad altissimo livello.
bye,
-- 
piergiorgio

 motivo, dato che occupa circa 1/3 del silicio sul chip.
alla luce di tutto quanto ho scritto io come desktop preferisco un 
processore AMD o Intel!! :-)

 processore AMD o Intel!! :-)
Nessuno ti nega questo diritto... :-)
D'altro canto non mi pare vi siano cosi` grandi
differenze tali da preferire uno o l'altro.
Voglio dire, Atom, PPC, MIPS, ARM, non mi pare, per
uso "desktop", siano cosi` abissalmente diversi.
bye,
-- 
piergiorgio

 Ma e` condivisa con *tutte* le unita` di calcolo.
Ni. Il processore in genere non ha accesso *diretto* alla ram della GPU,
afaik. Se parli di tutte le unita' di calcolo della GPU, si, e' vero. 
-- 
-riko

 uso "desktop", siano cosi` abissalmente diversi.
Mah non penso che sugli Atom Windows giri come sui Core2!! :-)

 Mah non penso che sugli Atom Windows giri come sui Core2!! :-)
Ma cosa deve fare questo Windows?
Pare che l'attivita` principale sia fare chissa` cosa,
non meglio definito, che pero` non usa FP, non usa int,
non usa niente della CPU.
Quando gestisci 4 interrupt in croce e` finita, cosa
ha di tanto CPU-intensive Windows che necessita`
addirittura di un core2?
Quando, invece, funziona perfettamente su di un P3...
Se per aprire una finestra ci mette 0.2 secondi,
invece di 0.1, cambia qualcosa?
Perche` questi sono gli ordini di grandezza, mica
secondi o minuti.
E tra le altre cose, le prestazioni "desktop" aumentano
sensibilmente con la velocita` dell'HDD e la quantita` di
RAM, non certo con la CPU.
Chiunque creda che la CPU sia rilevante ha solamente
mangiato troppa pubblicita`.
bye,
-- 
piergiorgio

 afaik. Se parli di tutte le unita' di calcolo della GPU, si, e' vero. 
La seconda, ovviamente, dato che questo e` il
parallelo piu` calzante con le SPE.
bye,
-- 
piergiorgio

 mangiato troppa pubblicita`.
guarda io attualmente sono su un vecchio AthlonXP a 32 bit con un hard 
disk veloce perche' l'ho appena cambiato che mi si era fuso, e con 2 
giga di ram e non swappa mai, ma ti assicuro che la differenza di 
velocita' tra questo e un Core2 con stessa ram e HD si vede a occhio 
nudo, sia con Ubuntu che con WindowsXP.
Stesso discorso per la differenza tra il vecchio Pentium3 che avevo 
prima e questo Athlon: quando sono passato da uno all'altro all'inizio 
ho mantenuto l'hard disk e avevo 1GB di ram su entrambi ma la differenza 
si vedeva eccome.
Dai su, stai esagerando tu :-)

 Dai su, stai esagerando tu :-)
Allora, io ho visto incrementi di prestazioni, in ambito
desktop, soprattutto aumentando la RAM e, in primis,
passando ad HDD piu` veloci (o RAID-0).
Insomma, il tempo di "apertura" di un programma mi cambia
per l'HDD, piu` che per la CPU.
Certo, quando parte qualche task che usa la CPU al 100% la
differenza di sente. Ma quando succede? Forse un encoding xvid?
Per le applicazioni "standard" (browser, office, etc.), non
mi cambia quasi nulla dal P3 al X2.
Se provi un netbook con Atom e winXP non mi pare sia cosi`
inusabile, tra l'altro l'Atom a 1.6GHz, single core e senza
out-of-order execution.
Certo, se fai partire, sullo stesso, un folding o simile,
la CPU "leggera" si sente.
bye,
-- 
piergiorgio

 ovviamente escludendo in entrambi i casi l'uso della GPU.
toglimi una curiositï¿œ: quante risorse servono per fare un encoder H.264 
D1 o Full HD, preferibilmente main profile (ovvero con le B e non solo 
le P)?

> Grazie per le risposte
ehm .. ne � venuta fuori una  bella discussione ..
si potrebbe aggiungere benzina sul fuoco:
- dicendo che Apple prima di decidere di usare Intel aveva valutato anche 
Cell, e purtroppo non se ne � fatto nulla ...  probabilmente perch� il fatto 
di poter "provare" MacOS sui pc con i vari crack che imperversano su torrent 
� un bel modo di attirare possibili clienti in futuro (la pirateria come 
sistema di propagazione dell'os, fino all'assueffazione dell'utente, roba 
gia vista!).
- dicendo che se ti compri una Ps3 ci puoi agevolmente installare linux e 
usarla come PC desktop con il cell che spaccherebbe il mondo, mah ... visto 
che le ps3 le vogliono vendere (in perdita) per *vendere i giochi* e non per 
combattere il mercato desktop l'accesso all'hardware � in qualche modo 
limitato, e quindi il tutto si riduce a tempo perso per tutto il mondo
- dicendo che in un sistema desktop, 2ndo me, il cell andrebbe benone, 
esempi? genericamente la gente col pc desktop a casa ci guarda le foto 
(facendo gli zoom) e ci guarda i film (e per vedere i bluray serve una 
scheda video mediamente buona) e ci ascolta gli mp3, guarda i dvx, va su 
youtube ecc e non dimentichiamo che ci si gioca anche 

 automobile rossa fiammante... :-)
Avendolo usato (sul simulatore perche` i Cell costeno!), e leggendo le 
bestemmie di chi ci sviluppa, i Cell devono avere una SDK migliore 
altrimenti li brucerei tutti. E` un bagno-di-sangue svilupparci sw 
sopra, sw che usi le possibilita` del Cell e non lo usi come un misero 
ppc.
Idea carina, ma uso agghiacciante.
-- 
Sensei�<Sensei's e-mail is at Mac-dot-com>
Research (n.): a discovery already published by a chinese guy one month
� � � � � � �� before you, copying a russian who did it in the 60s.

 la CPU "leggera" si sente.
ecco appunto, non ho mai detto che e' inusabile, dico che la differenza 
tra le varie CPU si nota. :-)

 Certo se mi confronti il Cell col 386 vince il Cell! Che scoperta!
A parita` di rotture di cazzo per usare tutto del processore pero` 
vince il 386 :)
-- 
Sensei�<Sensei's e-mail is at Mac-dot-com>
Basic research is what I am doing when I don't know what I am doing.
(Wernher von Braun)

 cantiere e vedremo cosa uscira'.
Per adesso e` uscita la serie tesla di nvidia :D...
http://www.nvidia.com/object/tesla_computing_solutions.html
Ne abbiamo pure presa una, ma per adesso non abbiamo ancora trovato una
scheda madre su cui possa andare comoda (e` decisamente un catuoio)...
Saluti ;)
-- 
                          |  Del resto mimporta 'nasega sai
\|/ ____ \|/   \ ||_|     |  Ma fatta bene
"@'/ ,. \`@"    \|| |     |  Del resto mimporta 'nasega sai
/_| \__/ |_\ Vax Headroom |  Ma fatta bene che non si sa mai
   \__U_/                 |  Che non si sa mai, che non si sa mai

 scheda madre su cui possa andare comoda (e` decisamente un catuoio)...
mi riferivo a Fusion perche' dovrebbe portare l'architettura ibrida in 
un singolo processore...
Cmq di analogo al Tesla c'e' anche l'ATI FireStream:
http://ati.amd.com/products/streamprocessor/specs.html
tutta roba interessante! :-)
Cmq in verita' anche i prossimi processori Intel basati su Nehalem 
(l'architettura del core i7), nel tentativo di anticipare AMD pare che 
avranno la grafica integrata e delle istruzioni per accelerare la 
crittografia: ma non e' ben chiaro cosa cio' significhi, grafica 
integrata puo' voler dire tante cose, anche gli AMD Geode hanno la 
grafica integrata (e accelerano la crittografia), e pure il VIA 
CoreFusion, e inoltre Intel non e' per niente al top della tecnologia GPU.
Ha tutta l'aria di essere una sorta di processore con northbridge 
integrato (tipico da sistemi embedded) in versione "vitaminizzata" per 
uso desktop.
Io ho il vago sospetto che sia la solita mossa "di facciata" per cercare 
di rincorrere AMD, cmq staremo a vedere! :-)

 il 386 :)
LOL! :-)

 di rincorrere AMD, cmq staremo a vedere! :-)
Noi siamo qui e aspettiamo...
-- 
                          |
\|/ ____ \|/   \ ||_|     | Un programma fa quello che gli dici,
"@'/ ,. \`@"    \|| |     | non quello che vuoi
/_| \__/ |_\ Vax Headroom |
   \__U_/                 |           Terza Legge di Greer

 prestazioni aveva un costo inferiore.
no, x86 ha vinto perche' le applicazioni che girano su x86 NON girano
su itanium. Per girare devono essere almeno ricompilatie (se va bene,
altrimenti bisogna riscriverle).
Quindi se chi scrive applicazioni non supporta l'itanium, l'itanium
non vende.
Ciao Jack

 non vende.
Itanium e' stato pensato per server, quando e' uscito sul mercato era 
gia' ampiamente supportato da Linux con tutte le applicazioni 
ricompilate, da Windows con Windows 2000 Server (e successivamente anche 
da windows Server 2003 e 2008) con l'IIS e tutti i vari server della 
Microsoft, e anche da Oracle coi suoi databese, e sicuramente mi 
dimentico qualcun altro.
Il lancio di Itanium e' stato preparato a regola d'arte e fin 
dall'inizio era supportato con *TUTTO* quello che puo' servire lato 
server su ben *DUE* piattaforme, ed era spinto dalle principali aziende 
del mondo server, guarda questo paper di Oracle del novembre 1999:
http://www.dig64.org/specifications/BldgBlocks.pdf
Itanium era ed e' piu' veloce dei processori IA-32 del'epoca... il 
problema e' che non avevano calcolato Opteron con AMD64, che gli ha 
fatto un paiolo cosi'.

 youtube ecc e non dimentichiamo che ci si gioca anche 
Non serve la scheda video "buona", serve una scheda che abbia il decoding
in hardware oppure un computer con buona potenza di processore. Comunque
si, in un uso desktop il cell andrebbe bene, esattamente come l'Atom va
bene nei netbook. Pero` il cell e` PPC e il software per desktop e`
quasi totalmente x86(-64), convertire il software a PPC non lo fa
nessuno e quindi il cell e` semplicemente inesistente.
-- 
Valentino Volonghi aka Dialtone
http://stacktrace.it
 -- Aperiodico di resistenza informatica
Blog: 
http://www.twisted.it/
Public Beta: 
http://www.adroll.com/

 Idea carina, ma uso agghiacciante.
No, deve avere un linguaggio migliore, non un SDK migliore. Il C non va
bene, e` un sistema diverso e va usato in modo diverso. Dovrebbero ad
esempio concentrarsi sullo sviluppo di linguaggi piu` simili a erlang[1]
piuttosto che al C.
[1]: erlang 
http://erlang.org/
     clojure 
http://clojure.org/
     scala 
http://www.scala-lang.org/
     cilk 
http://supertech.csail.mit.edu/cilk/
Ogni altro tentativo e` semplicemente ridicolo e fallira`. Non mi e`
particolarmente difficile immaginare un erlang in cui lo scheduler gira
sullo SPE mentre i singoli processi girano su ciascun PPE. L'altra cosa
che sarebbe da cambiare e` creare degli scheduler a livello applicativo
e non solo a livello kernel perche` possono fare un lavoro molto
migliore avendo piu` conoscenza di contesto.


 migliore avendo piu` conoscenza di contesto.
Questo pero` non deve essere fatto dal programmatore a manovella (vedi su).
-- 
Sensei�<Sensei's e-mail is at Mac-dot-com>
UNIX: The world's first computer virus.
(The UNIX Haters Handbook)

 Noi siamo qui e aspettiamo...
:-)

  il linguaggio *per se* e` immateriale.
Buona notte. 
Il linguaggio (sia naturale che di programmazione) influenza perfino
*come* si pensa (e alcuni arrivano pure a dire *cosa* si pensa). 
-- 
-riko



Si certo, non lo metto in dubbio. Alla fine pero` devi comprendere che 
sotto c'e` Assembly. E se le routine di base sono un bagno di sangue 
sei fottuto, qualunque linguaggio sia.
Secondo te questi sono cosi` diversi? (Erlang/C++)
initSPE(Fun) ->
   spawn(?MODULE, Fun, []).
pid_t initSPE(function_t Fun)
{
   return SPE::spawn(Fun);
}
Se ci fosse una libreria piu` ad alto livello di quella fornita dalla 
SDK del Cell, avrebbe vinto. E veramente non importa se poi usi i 
bindings Erlang, C, Java, Lua, Lisp o Assembly.
Poi ci sono in giro cose che confermano la mia idea, e parlo di livelli 
pseudo-competitivi come RapidMind. Poi usi il linguaggio che piu` ti si 
addice e si addice al problema, ma senza le librerie sei fottuto.
-- 
Sensei�<Sensei's e-mail is at Mac-dot-com>
Java is the most distressing thing to happen to computing since MS-DOS.
(Alan Kay)

 bindings Erlang, C, Java, Lua, Lisp o Assembly.
Chiaro che una libreria aiuterebbe, meglio ancora aiuterebbe il
linguaggio, certe operazioni sono troppo delicate per basarsi solo e
unicamente sulla propria attenzione o disciplina. Non si sta parlando di
confronto tra tipi ma di operazioni che falliscono in modo non
deterministico e assolutamente non ripetibile.


 di fare puttanate coi puntatori non c'e` disciplina che tenga.
giusto, diciamo che pero' se lo sviluppatore sa programmare col
paradigma giusto, qualsiasi linguaggio va bene: chiaramente poi gli
tornera' piu' comodo Erlang se ha liberta' totale di scelta di linguaggio.
Cmq anche se lo sviluppatore sa programmare col giusto paradigma, la
giusta disciplina eccetera, mi domando: e' possibile parallelizzare
qualunque cosa? Mboh...

 qualunque cosa? Mboh...
Domanda retorica, nessuno dice che si possa parallelizzare tutto. Il
punto pero` e` saper capire cosa puo` diventare un servizio a parte che
viaggia in parallelo.
Ci sono, tra le tante, due tendenze in informatica: quella a cercare di
trattare sistemi sempre piu` grossi come un unico sistema virtuale, e
quella invece di trattarli come unione di tante parti con un unico punto
di accesso.
Il primo caso e` quello tipico dei 'Big Iron' dove macchine con 2
bananozilioni di processori e 700 catriliardi di GB di RAM vengono
gestite (male) da un unico sistema operativo che, trasparentemente e
senza avere la minima conoscenza di cosa sta facendo eseguire, dovrebbe
ottimizzare al massimo l'utilizzo e limitare al minimo i problemi di
tale sistema.
L'altro caso e` quello invece di avere 2 bananozilioni di macchine con
uno sputo di risorse, ognuna che fa bene "una" cosa sola e poco piu`
concentrandosi di piu` sul flusso dell'informazione all'interno del
sistema, siccome c'e` relativamente poca enfasi sul sistema operativo e`
abbastanza ininfluente quanto ottimizzato sia, basta anche il modello
basic per pirla.
Nel caso del CELL abbiamo un sistema in cui i programmatori si aspettano
che il compilatore C (analogo del sistema operativo) sappia generare
codice in grado di usare efficientemente tutti i core, partendo da
un punto iniziale in cui il programmatore non ha fatto questo sforzo
perche` il suo linguaggio non l'ha obbligato o la sua disciplina non
l'ha supportato.
Buona fortuna con la parallelizzazione di codice generico (e c'e` tanta
ricerca in informatica per questi sistemi che sono spesso usati,
appunto, nei supercomputer). Se col CELL non si capisce che questa
strada e`, per il momento, ancora fallimentare, c'e` poco da lamentarsi
che manca l'SDK o la libreria ecc ecc, e` proprio il mezzo che e`
sbagliato. La programmazione concorrente e la programmazione parallela
sono campi impestati neri perche` sono non deterministici (altrimenti un
compilatore ottimizzerebbe tutto senza problemi dato un input), pensare
di riuscire a cavare un ragno dal buco con sistemi automatici senza
condizioni al contorno e` come lottare contro i mulini a vento.
Piu` informazioni su Concepts Techniques and Models of Computer
Programming.


 deterministico e assolutamente non ripetibile.
Una cosa utile ad esempio e` LLVM. Chi se ne fotte di quale linguaggio 
usi, io ottimizzo. Buona idea. Se il Cell avesse qualcosa che 
ottimizzasse per il processore sarebbe opportuno. Poi se vuoi scrivere 
un parser usi lex, se vuoi fare una GUI usi C++, se vuoi usi clojure o 
commonlogic. Il backend e` comune, ma tu sei libero di scegliere il 
linguaggio che e` piu` opportuno.
-- 
Sensei�<Sensei's e-mail is at Mac-dot-com>
$ cd /pub
$ more beer

 l'ha supportato.
Pero` hanno ragione. E non e` colpa del C, e` colpa di IBM (barra Sony 
barra Toshiba). Non puoi rilasciare quella micragnosa SDK che da tutti 
viene maledetta.
Non e` possibile parallelizzare automaticamente tutto, son d'accordo 
con te, ma alcune cose si possono fare gia`. Non puoi pretendere che io 
non bestemmi se non mi dai funzioni d'accesso ad alto livello a tutta 
la memoria, ma son io che devo dire da dove prendere i dati... Certe 
cose possono evitarle.
-- 
Sensei�<Sensei's e-mail is at Mac-dot-com>
Basic research is what I am doing when I don't know what I am doing.
(Wernher von Braun)

 bindings Erlang, C, Java, Lua, Lisp o Assembly.
Stai mettendo insieme *due* problemi distinti, poiche' sei ancora
nell'illusione de "il linguaggio non conta". La mia idea e' che per te
non conta il linguaggio, perche' di fatto usi tutti i linguaggi come se
fossero il tuo linguaggio favorito, *senza* cambiare la forma mentale
soprastante.
*Se* lavori cosi'  hai torto per il motivo opposto: il linguaggio
*conta* e *NON* *devi* usare Erlang (o Python o ...) perche' scriverai
del pessimo Erlang (o Python) mentre scriveresti dell'ottimo [C?].
Io invece mi adatto tantissimo al linguaggio, al punto da faticare ad
usare certi linguaggi quando mi rendo conto che lo stile "naturale" mi
fa schifo e che dovrei "piegare" il linguaggio per scrivere in un altro
stile.
Oltretutto c'e' *tantissima* ricerca basata sull'idea di usare linguaggi
di alto livello, tipicamente dichiarativi, perche' l'espressione
sostanzialmente formale della soluzione ad un problema e' spesso ben
trattabile da una macchina virtuale conscia dell'hardware.
Per esempio se in C++ per parallelizzare certi algoritmi devi riscrivere
il codice, potresti avere un problema a vincoli automaticamente e
naturalmente parallelizzato dal sistema. Nota, la libreria parallela per
i vincoli potresti averla anche in C++ o in Java... ma con certi
linguaggi hai *tutto* parallelo.
poi ci sono linguaggi come Erlang in cui scrivi *naturalmente* codice
parallelo. Di fatto ti viene naturale come e' naturale usare un
puntatore in C o una funzione in scheme. E a questo punto hai anche per
le cose non automaticamente parallelizzabili una formulazione parallela
(perche' e' *naturale* scriverlo cosi').
Un esempio? Una chat multicast in C++ te la insegno dopo avere speso
lezioni a trattare socket, poll, threading, etc etc etc. Diciamo che mi
ci vanno almeno 4 lezioni prima e paginate di codice. In Python ho
bisogno di una lezione in cui ti spiego come funziona Twisted e te la
butto li il giro dopo. In Erlang te la faccio nella seconda ora del
seminario dopo averti insegnato per la prima volta il linguaggio. Oppure
non te la faccio affatto perche' se e' anche solo un "secondo seminario
su Erlang" e' troppo banale.
-- 
-riko

 Programming.
bel libro.

 essere parallelizzato per sfruttare Cell?
Sono tanti gli algoritmi almeno parzialmente parallelizzabili. Se ho un
dual core relativamente veloce per singolo core, magari il costo di
scrivere parallelo non me lo pago. Se pero' il "core centrale" fa schifo
e ho un po' di core esterni... beh, allora *devo* parallelizzare.
-- 
-riko

 e ho un po' di core esterni... beh, allora *devo* parallelizzare.
Ok ma chiedo l'esempio perche' qua si diceva che il Cell si puo' 
sfruttare meglio parallelizzando del software ceh *ATTUALMENTE* non e' 
parallelizzato. Ok. Per esempio? :-)

 occupi di parallelizzare la decodifica.
Domani. Se mio nonno aveva 2 gambe era un maratoneta.


 Domani. Se mio nonno aveva 2 gambe era un maratoneta.
Boh, io nn capisco cosa vuoi dire.

Valentino Volonghi aka Dialtone ha scritto:
 >>> Il primo caso e` quello tipico dei 'Big Iron' dove macchine con 2
 >>> bananozilioni di processori e 700 catriliardi di GB di RAM vengono
 >>> gestite (male) da un unico sistema operativo che, trasparentemente e
 >>> senza avere la minima conoscenza di cosa sta facendo eseguire, dovrebbe
 >>> ottimizzare al massimo l'utilizzo e limitare al minimo i problemi di
 >>> tale sistema.
 >> perche' gestite "male"?
 >
 > Mai provato a fare ricerche sulle prestazioni dei sistemi operativi che
 > gestiscono macchine con piu` di 32-64 core?
Sinceramente no. Cmq 32/64 mi sembrano gia' tanti.
 >> Il problema e' che la macchinetta con uno "sputo" di risorse, l'anno
 >> prossimo sara' sul mercato allo stesso prezzo un "sputo+X" risorse,
 >> quindi riprende in modo naturale la tendenza che a te non piace.
 >> Lo stesso processo ha piu' risorse e viene eseguito piu' velocemente,
 >> non e' che viene ulteriormente parallelizzato.
 >
 > Perche` e` un problema?
Invece di parallelizzare ulteriormente, si velocizza il singolo thread. 
Tu non eri per la parallelizzazione?
 >> Per seguire continuamente la tendenza che a te piace, ci vorrebbero
 >> processori sul mercato che ad ogni nuovo modello invece di salire di
 >> clock moltiplicano i core continuamente: impossibile, bisognerebbe
 >> ridisegnare continuamente l'architettura, con costi improponibili.
 >> Ci vorrebbero software che vengono continuamente modificati per
 >> parallelizzare ulteriormente, ad ogni step, le operazioni da svolgere.
 >> Mi sembra impossibile tutto cio'.
 >
 > Dillo a Intel: 
http://en.wikipedia.org/wiki/Larrabee_(GPU)
 >
 > Che avendo capito l'andazzo si sta concentrando sempre piu` in
 > processori x86 stupidissimi ma che consumano veramente poco in modo da
 > poterne mettere 70-80 sullo stesso die.
 >
 > Tra l'altro... Il Pentium M (predecessore della serie Core della Intel)
 > commercializzato nel 2003 per la prima volta aveva una frequenza massima
 > di 2.26Ghz. Il Core 2 Duo, introdotto nel 2006 e tutt'ora
 > commercializzato, ha una frquenza massima di 3.33Ghz. In 6 anni di
 > sviluppo hanno guadagnato 1Ghz e grazie al fatto che il pentium M era da
 > notebook e non poteva consumare 60-70W come il Core 2 Duo da 3Ghz. Il
 > Core i7, successore del Core 2 Duo, arriva per ora anche lui al massimo
 > a 3.33Ghz.
Per un'architettura del genere 1 GHz non e' mica poco!
 > Cosa e` cambiato dal Core 2 Duo top di gamma al Core i7 top di gamma?
 > Semplice: invece di essere dei quad core doppio die, i Core i7 sono dei
 > quad core a die unico, hanno ridisegnato il processore per aumentare i
 > core nel die!
Che aumentino i core non c'e' ombra di dubbio, ma non e' che ad ogni 
nuovo modello aumentano i core... quando si puo' introdurre la nuova 
architettura casomai (infatti, da Core2 a Nehalem)....
E tra parentesi Intel nel multicore corre dietro ad AMD, un processore a 
doppio die in sostanza sono *due* processori sullo stesso package...
e anche Larrabee e' una mossa per inseguire l'acquisizione di ATI da 
parte di AMD...
Ad ogni modo, Larrabee non e' ancora uscita, e riguardo ad Intel fino al 
Core2 eravamo fermi alle CPU dual core (il doppio die sono 2 cpu), ergo 
non mi pare che riguardo ai core siamo ancora alla moltiplicazione dei 
pani e dei pesci... si va con calma...
 > Io non saro` bravo in matematica, ma a me sembra che Intel faccia
 > _esattamente_ quello che tu dici e` impossibile. O meglio, cio` che tu
 > dici che e` impossibile perche` non afferri che cio` che e` veramente
 > ridicolo e` il software che cerca di parallelizzare automaticamente o la
 > programmazione multithread shared-state/"tradizionale".
mbah Intel introduce via via piu core ma mica ad ogni modello di CPU...
ci sono mano a mano incrementi di clock...
Cmq io non ho mai parlato di "parallelizzare automaticamente" o di 
"multithread tradizionale", � che qua non � ben chiaro cosa ci sia 
bisogno di fare per sfruttare sto Cell..,. sembra quasi che sia ovvio ma 
non lo fa nessuno... strano! O no?
 >> Tra l'altro il fatto di mettere tutto in una macchina virtuale che
 >> gira su un maxiserver ha il vantaggio non indifferente di slegare in
 >> un certo senso la tua architettura dall'hardware sottostante, se devi
 >> migrare migri la macchina virtuale su un nuovo server e sei a
 >> posto... eccetera eccetera cioe' i vantaggi non sono certo
 >> indifferenti...
 >
 > Non puoi slegare l'architettura dall'hardware. Non e` un vantaggio, e`
 > una boiata che funzionicchia quando ci sono 2 o 4 core, quando ce ne
 > sono 20-30 sfioriamo il ridicolo.
Se hai dei server su cui girano mediamente 4-5 macchine virtuali, 
tipicamente ognuna delle macchine virtuali puo' indifferentemente girare 
su un server o su un altro. La cosa dei 20-30 che si sfiora il ridicolo 
mi e' oscura.
 >> Io non ho mai programmato sul cell, mi aspetto che ovviamente il
 >> programamtore debba sviluppare un software multithread per sfruttare i
 >> core del Cell.
 >
 > E` irrilevante. Se due thread usano una risorsa condivisa possono anche
 > essere 300 mila che tanto esegue uno solo per volta e tu hai modellato
 > male il tuo sistema. E` necessario fare un saltino in piu` a livello di
 > astrazione e cercare di imparare cosa sono gli actor e avere un
 > linguaggio e un compilatore che li integrino come concetto di base in
 > modo da poter fare ottimizzazioni e parallelizzare usandoli.
Qual'e' un esempio di codice non parallelizzato che potrebbe/dovrebbe 
essere parallelizzato per sfruttare Cell?
 >> Poi ad esempio se io ho una libreria di "alto" livello per sfruttare
 >> il Cell, ad esempio per la decodifica video, mi aspetto di poterle
 >> dare in pasto uno stream dal mio programma single-thread, e che lei si
 >> occupi di parallelizzare la decodifica.
 >
 > Domani. Se mio nonno aveva 2 gambe era un maratoneta.
Boh, io nn capisco cosa vuoi dire.

 Boh, io nn capisco cosa vuoi dire.
Il che non mi stupisce a questo punto :).


 parallelizzato. Ok. Per esempio? :-)
No, da quello che ho capito (che poi e' quello che penso io) il cell si
puo' sfruttare *solo* parallelizzando. Siccome le performance della PPE
fanno schifetto, per velocizzare bisogna cercare il modo di sfruttarne
il parallelismo, punto. E in generale dammi un problema e ti vedro'
alcuni punti che su una CPU normale non c'e' bisogno di parallelizzare
(ha poco parallelismo *e* funziona veloce anche in singolo) e che vanno
fatti su Cell (ha molto parallelismo *e* funziona male in singolo).
-- 
-riko

 Sei un po' troppo giovane per dirmi queste cose. 
Io cerco sempre di essere informato per quanto mi e' possibile essendo 
interessato alla materia, coi miei umani limiti, ovvio.
Poi si discute NEL MERITO, c'e' chi ogni tanto ammette di aver torto, 
chi invece si arrampica sui vetri, ci puo' essere un po' di sarcasmo 
nelle parole e ok... e questa discussione era anche interessante, pero' 
se per discutere uno deve sentirsi dire certe cose (capitato piu' volte) 
allora non va bene.
Ho cercato di farlo notare senza gettare benzina sul fuoco e mi rispondi 
che sono troppo giovane per dirti queste cose, allora discuti con quelli 
della tua eta' o con chi ti pare, noi due non e' il caso che si prosegua 
oltre.

 Il che non mi stupisce a questo punto :).
E vabe', amen. :-)

 oltre.
Perche'? Guarda che sei tu che sei andato quasi costantemente sul
personale. Tipo "lascia perdere l'astio". Io non ho astio. Quando sono
incazzato, scrivo diverso, fidati. :)
-- 
-riko

 del pessimo Erlang (o Python) mentre scriveresti dell'ottimo [C?].
Ui` je` sui` d'accorr.

Vabe` occhei, ma secondo te alla gente non piacerebbe usare paradigmi 
dipo MPI in C, C++, Erlang, o altri? Sai e` questo di cui parlo: avere 
delle chiamate piu` alte che astraggano dal bare metal come e` nel Cell 
attualmente. Che dici jaa famo o nun jaa famo? Famo un referedu? (cit.)
-- 
Sensei�<Sensei's e-mail is at Mac-dot-com>
Research (n.): a discovery already published by a chinese guy one month
� � � � � � �� before you, copying a russian who did it in the 60s.

 (cit.)
Astrarre dal bare metal non significa astrarre dal layout del tuo
software. Tu stai cercando un oggetto che progetti per te il flusso di
dati della tua applicazione per essere il piu` efficiente possibile. Io
ti sto dicendo che questo oggetto non esiste e devi farti tu lo
sbattimento.


 sbattimento.
Beh dai, la realta` dei fatti e` che un "parallelizzatore" tout court 
e` impossibile, ma cose ben specifiche e` possibile automatizzarle. 
RapidMind vende a quanto pare queste "mirabili" SDK, certo non so con 
quale successo, magari sono gia` in fallimento... chi lo sa!
Le lamentele degli sviluppatori PS3 (l'unico prodotto consumer uscito 
da tempo) non le hai sentite? Non chiedevano poi cosi` tanto insomma.
Se non erro poi la versione di RedHat non sfrutta a pieno il Cell, 
almeno cosi` m'ha detto il commerciale? Puoi confermarmelo?
-- 
Sensei�<Sensei's e-mail is at Mac-dot-com>
43rd Law of Computing: Anything that can go wr
fortune: Segmentation violation
Core dumped

 almeno cosi` m'ha detto il commerciale? Puoi confermarmelo?
Il commerciale dice cagate. L'unica cosa che non funziona bene nella PS3
con Linux, per precisa scelta di Sony, e` la scheda video. La sua
memoria (scarsissimi 256MB di RAM) non e` accessibile e si resta solo
con i 256MB di memoria centrale per fare tutto. Se il tuo software sa
usare il Cell puoi farci tutto quello che vuoi. Linux non e` un software
per calcolo vettoriale e quindi fa un po' fatica a sfruttare la CPU di
per se`.


 Guardian (in uscita nel 2010).
Beh sostanzialmente e` a supporto della tesi mia, che la Sony doveva 
spenderci tempo per fare una cosa meno che-iddio-vi-strafulmini. Ma i 
giochi sfruttano a pieno il Cell? Insomma, come va da parte dello 
sviluppo? (se ci sviluppi attivamente)
-- 
Sensei�<Sensei's e-mail is at Mac-dot-com>
Beware of bugs in the above code; I have only proved it correct, not tried it.
(Donald Knuth)

 ciclo for puo` essere parallelizzato alla OpenMP. Certo nessuno
(eh che tristezza premere send...)
Certo nessuno pensa di far "gcc -Wall -pedantic -ansi -c 
-parallelize=Cell -fspu-cool-freaking-stuff my.c -o my.o".
-- 
Sensei�<Sensei's e-mail is at Mac-dot-com>
$ cd /pub
$ more beer