Newsgroup: it.comp.lang.c++
Titolo: parallel programming a multicore features

Qualcuno di voi ha esperienze di sviluppo codice che sfrutta una cpu 
multicore? E di programmazione parallela? (Mi riferisco alle specifiche 
openMP)
Ciao
-- 
Morde

 openMP)
Minima minima.
Immagino ci sia chi ne ha piu' di me... pero' prova a chiedere...
  bye
	av.

 Immagino ci sia chi ne ha piu' di me... pero' prova a chiedere...
Mi piacerebbe iniziare a fare qualche esperimento in tal senso, e 
trovare qualcuno che abbia giï¿œ fatto qualcosa, ï¿œ sempre un buon punto 
da cui partire :)
Di preciso cosa hai realizzato a livello implementativo ?
ciao
-- 
Morde


Avevo una libreria che faceva operazioni su una bitmap (diciamo cosi' 
per semplificare): praticamente due for uno dentro l'altro (uno per le X 
e uno per le Y).
Messo OpenMP e su due core ci mette la meta' (cosa che non speravo).
Insomma, qualcosa di MOLTO banale.
  bye
	av.

 Insomma, qualcosa di MOLTO banale.
Non dovresti sminuire cosï¿œ quello che hai fatto, quanti programmatori 
possono dire di aver realizzato codice funzionante in openMP ? :-)
Ho trovato in rete un pï¿œ di slide propedeutiche, le riporto qui per 
condividere e diffondere, se tu hai altro materiale pubblicabile e ti 
accodi sei il benvenuto :-D
http://www.caspur.it/~lanucara/lanucara_files/OpenMP-Intro1.pdf
http://www.caspur.it/~lanucara/lanucara_files/OpenMP-Intro2.pdf
http://openmp.org/mp-documents/ntu-vanderpas.pdf
http://www.hpc.lsu.edu/training/20090304/presentations/parallelTrain-v1.0.pdf
ovviamente: 
http://openmp.org/wp/
ciao
-- 
Morde

 ovviamente: 
http://openmp.org/wp/
No, direi che non ho altro.
  bye
	av.

Sono 5 anni che non le uso ma qualcosa mi ricordo!


 ciao
Ma si tratta di programmazione concorrente giusto?
Ovvero della sua modellizzazione tramite una libreria/set di pragma...
Anzi, in questo modo secondo me bisogna stare molto piï¿œ attenti, in 
quanto non si "percepiscono" i concetti alla base di un algoritmo 
parallelo piuttosto che procedurale puro.
Ma magari non ho capito niente delle prime due/tre slide di 
OpenMP-Intro1.pdf che ho letto in 10 secondi per curiositï¿œ :)
ciao!


Solitamente scalare linearmente nel processing di immagini è molto 
facile. Questo perché è molto facile avere thread completamente 
indipendenti all’interno dei quali non c'è bisogno di utilizzare 
variabili condivise e quindi mutex.
In tali casi ci si aspetta che fino a 12/16 core.
Ovviamente ci sono due cose da dire.
Istanziare processi su più core ha un costo computazionale che nel caso 
di piccole immagini/matrici può compromettere le prestazioni globali 
(tempo di calcolo).
Ex:
se instanzi su 12 core un calcolo su una immagine 10x10 pixel otterrai 
un tempo computazionale maggiore di un singolo core.
A mio avviso la prima cosa da fare è imparare a usare le istruzioni sse 
e mmx che permette di parallelizare i conti anche su cpu modeste.
Ricordo che attualmente la gente ha 2 core e se si utilizzano bene le 
sse si è in grado di avere una potenza simile a un quad.
Per ora i tempi sono immaturi ma ritengo probabile che se dovessi 
ricominciare a lavorare su HPC inizierei a guardarmi opencl.
Ad esempio per AMD, l'opencl può fruttare simultaneamente le prestazioni 
di un opteron sfruttando sia sse che la parallelizazione dei vari core.
Ma attualmente l'opencl è poco documentato e non vi sono strumenti 
consolidati.
Xeus32

 Ma si tratta di programmazione concorrente giusto?
Si, si.. hai compreso benissimo il senso. :)
Si tratta di programmazione a memoria condivisa: stesso codice eseguito 
da piï¿œ thread contemporaneamente. I pragma marcano e pilotano il flusso 
di esecuzionee di regioni di codice in parallelo. Tu hai un flusso 
principale che ï¿œ il thread della tua applicazione, poi tramite pragma 
imponi alla cpu di eseguire un fork del processo in n threads, tanti 
quanti core hai a disposizione.
Per "stesso codice" mi riferisco proprio al fatto che piï¿œ thread 
eseguono lo stesso blocco di istruzioni contemporaneamente, da non 
confondersi col multithread che ï¿œ la copia e l'esecuzione multipla 
dello stesso blocco di istruzioni in uno spazio di memoria dedicato ad 
ogni thread.
Un esempio per semplificare: dato un ciclo for che va da 1 a 10mila, tu 
puoi far eseguire contemporaneamente a quattro core lo stesso ciclo ma 
ogni core esegue 2500 iterazioni diverse sulla stessa variabile.
Il primo esegue da 1 a 2500,contemporaneamente il secondo da 2501 a 
5000, e cosï¿œ via..
Si rivela utile proprio per calcoli matriciali e complesse funzioni 
matematiche.
Nello scrivere questo post, ho trovato un'altro link di spiegazioni 
molto semplice, eccolo:
http://bisqwit.iki.fi/story/howto/openmp/#ParallelPragma
ciao
-- 
Morde

 tempo computazionale maggiore di un singolo core.
Si sono d'accordo. L'OpenMP dovrebbe essere usata proprio per calcoli 
di enorme complessitï¿œ, anche perchï¿œ penso che non sia semplice isolare 
codice e scriverlo per essere parallelizzato.
ciao
-- 
Morde

 ogni thread.
Non ho capito cosa intendi: anche nel "multithread" hai un unico spazio di 
memoria (quello del processo), semplicemente ogni thread ha il suo stack 
dedicato. Ma lo heap e le variabili globali sono condivisi da tutti i 
thread.
Pleg

 thread.
Grazie per la correzione, te ne sono grato :)
Il parallel processing esegue lo *stesso codice* contemporaneamente, 
utilizzando valori differenti sulla stessa variabile "globale".
Il multithreading, invece, condivide la stessa variabile globale ma non 
puï¿œ accedervi in modo safe se non utilizzando tecniche di concorrenza.
Esempio: col parallel processing tu ottieni, in un'intervallo di tempo, 
10 cicli for sulla variabile I che va da 1 a 10, e contemporaneamente 
(nello stesso medesimo intervallo di tempo) un altro thread esegue gli 
*stessi* 10 cicli ma con la I che va da 11 a 20. Hai quindi un 
raddoppio di performance perchï¿œ vengono eseguito 20 cicli nello stesso 
intervallo di tempo.
Se tu tenti di fare la stessa cosa col multithreading, accedendo alla 
stessa variabile globale, potresti anche arrivare ad ottenere ottime 
performances, ma ti dovresti gestire tu l'accesso concorrente sulla 
stessa variabile, e dovresti scrivere codice aggiuntivo per decidere 
quali valori assegnare alla variabile (ad esempio per il thread 1 i 
primi 10 valori, per il secondo gli ultimi 10) e codice di cleanup per 
chiudere il thread aggiunto.
Col parallel processing tu ottieni che il codice funziona lo stesso sia 
che hai un solo thread sia che hai un multicore, perchï¿œ la libreria 
parallel gestisce per te tutto il codice negli altri core.
Per te il vantaggio enorme, oltre al raddoppio delle prestazioni sul 
codice, ï¿œ che non tocchi niente e il codice funziona sia in parallelo 
che no.
A proposito di multithreading, se hai voglia di leggere un trattato 
scientifico molto interessante e completo, ma non leggerissimo, prova a 
scaricare il pdf linkato nella pagina seguente :
http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.html
*Personalmente* parlando: dopo averlo letto e compreso quanta 
componente indeterministica ï¿œ racchiusa nei sistemi multithreading, ora 
ho una maggior consapevolezza nelle potenzialitï¿œ del parallel 
processing e nei rischi della scrittura e nell'uso indiscriminato di 
sistemi multithreading.
Ciao
-- 
Morde

 gestisce per te tutto il codice negli altri core.
Attenzione: non l'ho scritto, ma  ï¿œ implicito che devi scrivere codice 
di gestione per il parallel processing! Una volta scritto, viene 
eseguito sia su un solo core che su molti.
ciao
-- 
Morde

 che no.
Ni: devi comunque dire a OpenMP quanti thread deve usare. E allora e' come 
dire a pthreads quanti thread lanciare.
Pleg

 stessa cosa.
Ti ringrazio, Pleg, per le spiegazioni: quello che mi manca ï¿œ il tempo 
per provare con del codice, sto lavorando con delphi e sto passando 
consegne, quindi non posso ancora dedicarmi come vorrei al c++ e alle 
mie ricerche. Mi devo basare solo sulla teoria, e mi ricordo di aver 
letto dei grafici dove il guadagno prestazionale dell'archittettura 
openmp verso il multithread tradizionale sia di diversi ordini 
maggiore.
Nel tuo followup ti riferischi alla classe pthread che ï¿œ nativa POSIX e 
credo che sia molto piï¿œ performante del threading model di windows 
kernel, che io conosco e utilizzo.
Ho googlato con il classico "pthreads vs openmp" e ho recuperato questo 
link:
http://software.intel.com/en-us/articles/threading-models-for-high-performance-computing-pthreads-or-openmp/
uno dei tanti che meritano una lettura.
Quello che desidero, oltre a potermi documentare, ï¿œ qualche riscontro 
pratico e oggettivo di qualcuno che abbia provato "sul campo" openmp.
Mi rendo conto che parlare di una cosa avendola solo studiata ï¿œ un pï¿œ 
limitativo, ma per ora non posso fare altro che basarmi su quello che 
mi viene detto dagli altri qui sul ng.
Se hai altri contenuti ed esperienze che vuoi portare in questo thread 
mi farebbe veramente piacere leggerti.
un saluto :)
-- 
Morde

 uno dei tanti che meritano una lettura.
Dice qyello che ho detto prima: pthreads e' piu' complesso e difficile da 
usare ma piu' flessibile, mentre OpenMP si applica solo alla 
parallelizzazione di cicli, ma in quel caso e' semplicissimo da usare e ha 
molto meno impatto sul codice (che puo' essere molto importante).
Pleg

 dovrebbe essere uguale (se sono entrambi implementati bene).
Ho controllato, ho ripreso i documenti scaricati dal sito 
openmp.org
, 
ed i benchmark ai quali sono riferiti riguardano l'applicazione *del 
solo openMP in funzione dei cores*.
Un esempio di grafico c'ï¿œ in questo pdf:
http://openmp.org/mp-documents/ntu-vanderpas.pdf
Il buon google mi ha restituito anche altri documenti interessanti di 
confronto pthreads-openmp, ad es. 
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.13.1493&rep=rep1&type=pdf
ma quello che non emerge ï¿œ la netta superioritï¿œ di uno rispetto 
all'altro, anche se in certi documenti viene suggerito openmp in virtï¿œ 
della miglior manutenzione del codice da effettuare.
Ad esempio, questo
http://www.springerlink.com/content/gy154arx5vule13n/
pur essendo a pagamento, dall'abstract si capisce che hanno fatto dei 
test di una certa consistenza e propendono per OpenMP ma anche qui si 
parla di un una migliore gestione del codice, piï¿œ che di migliori 
performances.
Il resto dei documenti che ho trovato conferma quanto detto da te.
Ciao
-- 
Morde

 della miglior manutenzione del codice da effettuare.
Su questo non posso che concordare.
Se ti interessano altri modelli per applicazioni parallele, prova a dare 
un'occhiata a map-reduce di google (credo ci sia una versione opensource 
chiamata hadoop, che pero' e' in java). Per certe applciazioni puo' essere 
una manna.
Pleg

 dovrebbe essere uguale (se sono entrambi implementati bene).
Sempre per la mia limitatissima esperienza, confermo la parita' di 
prestazioni fra i due (con due core e due thread).
  bye
	av.

 impressioni sbagliate.
Ma come hai fatto a mettere le mani su un Niagara? Ho letto che sono 
ottimi processori anche se da quello che ricordo non sono molto adatti 
al calcolo parallelo ma ideali per la gestione di servizi tipo db, 
webserver, VM ....
Alla fine quante thread hai usato?
Ieri mi sono messo a fare qualche esperimento con le openCL ma sono 
veramente dure da digerire.

 Alla fine quante thread hai usato?
Da 1 a 32m cioe' tutti quelli hardware, per controllare lo scaling. In 
alcuni casi era piuttosto buono, in altri era limitato dalla cache, in altri 
era disastroso ma non abbiamo mai capito perche'.
Pleg