Newsgroup: it.lavoro.informatica
Titolo: programmazione concorrente

prendendo spunto dalla discussione sulle startup, a proposito di
erlang, m'e' venuta questa domanda, magari qualcuno di voi ne sa
qualcosa.... e se e' OT, se mi indicate un NG adatto mi fate una
cortesia. Come premessa, e' giusto dire che di programmazione
concorrente ho solo dei ricordi ammuffiti di "sistemi operativi" dai
tempi dell'uni.
Veniamo al problema. Ultimamente la mole di dati su cui sto lavorando
e' un po' grandicella (si aggira attorno ai 20-30 giga), e per
elaborare il tutto il mio povero macinino ci mette 3 giorni
abbondanti: il che si traduce in 10 minuti di lavoro e 3 giorni di
cazzeggio :-D. Purtroppo allora (maledetto Carter, m'hai fregato anche
stavolta LOL) mi hanno fornito l'accesso ad un macinone da 10
trillioni di operazioni al secondo, e m'hanno "gentilmente suggerito"
di usarlo.
Per poter usare appieno le capacita' pero' dovrei "parallelizzare" (o
demandare a terzi) del codice (principalmente operazioni a virgola
mobile e trasformate inverse di fourier).
Banalmente (e da semi-ignorante), vorrei sapere, quanto sbattimento
c'e' dietro al parallelizzare? Sarebbe interessante cogliere
l'opportunita' e lavorarci un po' su, pero' se lo sbattimento e'
troppo... demando a terzi! Principalmente sto lavorando in C++ e
linux, quindi qualcosa che possa essere usata agevolmente da C++.
Qualcuno ha esperienze in merito? ricordo male o anta-anni fa FabMind
aveva parlato di qualcosa del genere?
thank you

 essere usata agevolmente da C++. Qualcuno ha esperienze in merito?
Molto dipende dagli algoritmi che stai usando.
Parallelizzare un algoritmo non è banale, a meno che non sia 
"naturalmente" parallelo.
Ad esempio per la trasformata di Fourier esiste 
http://www.fftw.org/
, 
che, come documentato da
http://www.fftw.org/fftw3_doc/Multi_002dthreaded-
FFTW.html#Multi_002dthreaded-FFTW
supporta architetture multiprocessore a memoria condivisa.
Ciao  Manlio

 supporta architetture multiprocessore a memoria condivisa.
grazie per il link! Interessante!

 
allora forse considera di laciare piu' istanze del processo con una base di
dati ridotta. Mi spiego meglio:
se hai che so 10 immagini da processare fai uno script che fa partire il tuo
applicativo 10 volte in parallelo con una sola immagine da processare... 
Il sistema si occupera' di usare i nodi (cpu) meno usate per te... 
E tu non dovrai neanche modificare il codice...
Ciao 

> applicativo 10 volte in parallelo con una sola immagine da processare...
Ma che accrocchio ! Va bene se queste operazioni le devi fare una
volta, non certo come soluzione definitiva.
La complessità di modificare l'applicazione per farla diventare
concorrente su threads dipende dalla tecnologia, su .net è banale
dividere il carico sia sulla stessa macchina sia su più macchine, in c+
+ è un incubo.

 + � un incubo.
ah ecco perche' non capivo la difficolta'(ho avuto a che fare con sta 
roba con c#)!! :-D

 mobile e trasformate inverse di fourier).
Fallo in TSQL... :P 
-- 
__________________________________
Luc (36, CO)
25 years uninterrupted programming
__________________________________

 Il sistema si occupera' di usare i nodi (cpu) meno usate per te...
Piu' che altro il problema e' un altro: mi hanno "caldamente
suggerito" di rendere il codice parallelo (l'avevo gia' proposta una
cosa del genere). Diciamo che c'e' da scrivere un articolo per
giustificare il fatto che m'hanno dato l'account, e -dicono- che
parallelizzando in questo modo non porta alcun contributo alla
ricerca... e bla bla bla
La mia idea e' di fare qualcosa che comunque funzioni in multithread
per trovare una soluzione al welch (ed altri kernel simili) in
parallelo (applicati al problema specifico, probabilmente un welch
parallelizzato gia' esiste! mhmmmmmmm good point.... google!)...
grazie per lo spunto!

 Fallo in TSQL... :P
il generatore dei test l'ho scritto in php, non vedo cosa ci sia di
male! ;-)
Il codice finale in C++ e' una scelta mia, ma le librerie che uso
supportano ampiamente il python (tra gli altri), e volendo avrei
potuto fare tutto in python (giusto per non darla vinta ad una mia
collega che sta sempre a frignare su quanto sia bello il python...
contrariamente alla mia tesi -ironica- secondo la quale chi non sa
usare i puntatori non sa programmare, pero' mica vado a dire che il
python non e' un linguaggio di programmazione... e che e' allora? una
motobicicletta?)

 mobile e trasformate inverse di fourier).
Una tecnica che sta andando per la maggiore � l'uso delle schede
grafiche, di loro natura super parallele, per elaborazioni non
strettamente legate alla grafica 3D, ovvero il cosiddetto General
Purpose GPU.
Sulle schede grafiche pi� recenti di Nvidia si pu� usare CUDA, che � un
compilatore specializzato che permette di parallelizzare in modo
abbastanza semplice programmi scritti in un C arricchito.
Su quelle pi� vecchie si devono usare altri sistemi, come per esempio
certe estensioni speciali delle OpenGL, o il compilatore CG sempre di
Nvidia, per programmare la scheda grafica nel suo linguaggio "nativo",
trasformando grandi matrici di numeri decimali in finte texture che poi
la scheda elabora "come sa". Questo molto in breve.
In rete si trovano svariati esempi di applicazioni non strettamente
grafiche, per es. con l'uso del CG:
http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter40.html
 
Cuda comunque � pi� moderno e facile da usare.
Siccome poi parli di trasformate di Fourier, potrebbe essere che devi
elaborare proprio immagini, nel caso saresti ancora pi� facilitato.

 Fallo in TSQL... :P 
Si puï¿œ fare. Le stored procedure in SQL Server vengono eseguite in
thread separati. Ergo, basta scrivere un controller e demandare a T-SQl
il lavoro di gestione dei dati.
Nota peraltro che, a meno che il tuo codice non venga eseguito
direttamente sul server (ma allora hai a disposizione le CLR stored
procedures), una stored procedure ï¿œ il metodo piï¿œ veloce che esista per
eseguire elaborazione sui dati (ti eviti una valanga di round trips).
Perdona la curiositï¿œ, a che livello conosci T-SQL?
-- 
Ciao!
Luca

 elaborare proprio immagini, nel caso saresti ancora più facilitato.
Nvidia le Fourier le calcola in automatico con la libreria  CUFFT.

 elaborare proprio immagini, nel caso saresti ancora più facilitato.
si, si, sono immagini.

 che sono anche "forzato" ad usare questo supercomputer, 
certo, avendo un supercomputer a disposizione, chi se ne frega di
impiccarsi con le schede grafiche e le loro stranezze :-)

 Nvidia le Fourier le calcola in automatico con la libreria  CUFFT.
Infatti. E' una libreria basata proprio su Cuda. 

 impiccarsi con le schede grafiche e le loro stranezze :-)
sarebbe bello invece confrontarne le performances! In fondo le schede
grafiche sono economiche, e (di questo non sono sicuro, ma lo
immagino) se ne potrebbero installare piu' d'una in un PC migliorando
di parecchio le prestazioni! Pero' per quel che mi riguarda, "no
standard, no party" :-))

 sarebbe bello uno standard! Hai qualche link? 
Io conosco questa iniziativa:
http://www.khronos.org/opencl/
http://en.wikipedia.org/wiki/OpenCL
Sviluppato inizialmente da Apple.
Ciao  Manlio

 standard, no party" :-))
Certo, esistono gli standard di "schede parallele", SLI per Nvidia, Ati
ha il suo. Nascono per migliorare certi giochi 3D, ma probabilmente
Cuda e simili li pu� sfruttare.
Ti si � aperto un mondo davanti! :-)

 parallelamente TOT threads alla volta.
http://aws.amazon.com/elasticmapreduce/
 o 
http://hadoop.apache.org/
possono esserti utili ?
  ngw

 aveva parlato di qualcosa del genere?
Nel mio dominio mi è capitato spesso di dover parallelizzare, ma non
algoritmi, processi (stile eseguire system tests in 16 macchine
contemporaneamente).
Potrebbe ovviamente essere meno performante di un algoritmo parallelo
ad hoc, ma se invece che il codice, potessi parallelizzare i processi,
probabilmente la realizzazione potrebbe venirti meno complicata.
--
ale
http://ale.riolo.co.uk

 Perdona la curiosità, a che livello conosci T-SQL?
Basso, ho visto qualcosa in passato. Mi fermo ai cursori... :P 


 per trovare una soluzione al welch (ed altri kernel simili)
Io forse non ho capito bene una cosa....
ma se devi fare n-mila operazioni/sec => anche se ha 500 miliardi
di thread, che pero' devono girare tutti su uno stesso processore => quali
miglioramenti ottieni dalla parallelizzazione rispetto all'esecuzione in
sequenza ?
In genere di parallelizza quando accare qualcosa del genere
task 1
<elaborazione X>
<accedi a risorsa>
<usa risorsa>
<rilascia risorsa>
<elaborazione Y>
task 2
<elaborazione Z>
<accedi a risorsa>
<usa risorsa>
<rilascia risorsa>
<elaborazione K>
in modo tale che, magari mentre task 1 sta usando la risorsa, puo'
lasciare la CPU libera per task 2 (anche se task 2 non dovesse usare
alcuna risorsa, anzi probabilmente in quel caso a maggior ragione 
varrebbe la pena di parallelizzare).
Ma se, come mi pare di aver capito nel tuo caso, il problema e'
task1
<svolgi n miliardi di elaborazioni in virgola mobile>
task2
<svolgi m miliardi di elaborazioni in virgola mobile>
E si ha una sola CPU => 
sembra un po' difficile dare consigli se sia il caso di parallelizzare
o meno e come parallelizzare, senza entrare in merito molto specifico
del problema in esame.
E comunque se e' un problema aperto in ambito di ricerca, non so quanti
sul NG potranno essere in grado di aiutarti (io per primo, ovviamente)
Ciao,
Marco
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 [...]
Ciao  Manlio

 di thread pari al numero di processori, che eseguono i vari task.
si pero' m'ha appena risposto il tipo, e c'ha ragione Marco, la
macchina e' veloce e parallelizzare non sempre ha successo (boh?!?
vabbe'), in piu' di processori me ne darebbero "solo" otto, ed in piu'
non e' detto che un singolo thread sia gestito da un singolo
processore... quindi alla fin fine ho deciso che non parallelizzo un
bel niente, uso il macinone per far finire prima i risultati e buona
li'.

 <svolgi m miliardi di elaborazioni in virgola mobile>
esatto!, ma di CPU ne avrei diverse!
Vabbe'... demando a terzi Anche il mio boss m'ha detto che non c'ho il
tempo mariale per star dietro all'implementazione concerrente! Peccato
pero'!

 Ti si è aperto un mondo davanti! :-)
ma anche no :-)
Oggi ne parlavo col boss, secondo lui le GPU usate per velocizzare tra
5 anni saranno storia passata, perche' se per velocizzare quello che
in realta' fanno e' il prefetching dei dati, arrivera' il momento che
se ne occupera' direttamente il compilatore/hardware di fare il
prefetching dove gli pare a lui: in buona sostanza inutile stare a
perderci tempo appresso... e -ti diro'- mi trova concorde al 100%

 perderci tempo appresso... e -ti diro'- mi trova concorde al 100%
Cosa vuoi dire con velocizzare con il prefetching?
A me risulta che sono realmente multiprocessore, con un numero
piuttosto elevato di CPU specializzate per i calcoli 3D.
Certo, tutti dicono che il passaggio dati dalla memoria di sistema a
quella della GPU � un collo di bottiglia, ed infatti al di sotto di
certe dimensioni di dati il gioco non vale la candela, specialmente con
le GPU pi� vecchie assolutamente non previste per il GP.
Posso concordare sul fatto che in generale � un vero "accrocchio"
tecnologico per spremere al massimo l'hardware di un normale pc. Ma il
bello � proprio questo sperimentalismo, no? Almeno, se puoi
sperimentare senza giocarti il posto ed il sonno :-)

 Basso, ho visto qualcosa in passato. Mi fermo ai cursori... :P 
E allora suggerimento amichevole. Nelle ultime versioni di SQL Server
lasciali perdere il piï¿œ possibile, che ci hanno dato una montagna di
grattacapi.
-- 
Ciao!
Luca

 piuttosto elevato di CPU specializzate per i calcoli 3D.
mi accodo, per quel poco che ho usato io le GPGPU sapevo che il punto forte
del discorso era quello di usare un hardware _pesantemente_ parallelo e
molto ottimizzato nei calcoli in virgola mobile...
quindi il prefetch che centra?
ilSimo
-- 
now playing: 
I believe what the prophets said
That the oceans hold their dead
But at night when the waves are near
They whisper... and I hear...
                                Savatage - The Wake Of Magellan

 quindi il prefetch che centra?
come dicevo nel post di partenza, ne so molto poco.
Quello che so lo so perche' un prof (univ.) che se ne occupa veniva da
noi a farci dei seminari per farci collaborare con lui sulle GPU, e mi
sono anche perso il primo. Lui menzionava sempre il prefetching: dei
blocchi di dati che venivano mandati alla GPU per farci dei calcoli, e
i dati "computati" venivano rispediti al processore centrale. Quindi
il processore nel frattempo faceva altro (e da qui veniva
l'efficienza). Come questi "prefetched" dati (forse prefetched in
effetti non e' il termine piu' adatto) venivano gestiti era mistero,
non 100% documentato, e diverso da GPU a GPU.
Il suo discorso non era comunque generico, ma applicato al problema
che voleva appiopparci (connected component analysis). Riguardo alle
GPU applicate al problema specifico, pero', devo dire che mi e'
sembrato tutto un accorcchio! Non sapendone molto -ripeto- e' soltanto
una sensazione, pero' condivisa con gli altri colleghi (che ne sanno
un po' piu' di me, ma neanche tanto di piu').

 l'efficienza). 
L'efficienza potrebbe anche venire dal fatto che la GPU per il calcolo
ci mette una frazione del tempo , rispetto a quello che userebbe il
processore. Quindi anche se quest'ultimo resta in attesa tutto il tempo
ci sarebbe un certo vantaggio, ma sempre superato un (non piccolo)
limite inferiore della mole di dati.