The_ouroboros
27-11-2008, 13:26
Chi mi sa dire di sull'argomento Parallel computing..
E soprattutto, oltre a OpenMp che in gcc è supportato... esiste altro?
Grazie
E soprattutto, oltre a OpenMp che in gcc è supportato... esiste altro?
Grazie
View Full Version : [Generico]Parallel computing
The_ouroboros
09-12-2008, 19:27
up
cdimauro
09-12-2008, 21:22
M'era sfuggito questo thread. Ecco qui: http://docs.python.org/library/multiprocessing.html#module-multiprocessing
The_ouroboros
09-12-2008, 23:39
quanto amo il python :D
gugoXX
10-12-2008, 15:07
Per C#, oltre alle altre varie cose native, c'e' anche il PLINQ.
P.es. se si volesse calcolare il massimo valore di un vettore (molto lungo...)
// Codice normale
int max = Vect.Max();
/Codice parallelo
int max = Vect.AsParallel().Max();
Se invece vuoi renderizzare un'immagine, passando attraverso uno dei modelli tipo Phong o Radiosity (o una qualsiasi funzione lenta da ripetere piu' volte con input diversi)
// Codice normale
for(int y=0; y<maxY; y++)
{
for(int x=0; x<maxX; x++)
{
Pixel[y,x] = Radiosity(map, y, x);
}
}
//Codice Parallelo
Parallel.For(0, MaxY, y=>
{
for(int x=0; x<maxX; x++)
{
Pixel[y,x] = Radiosity(map, y, x);
}
});
P.es. se si volesse calcolare il massimo valore di un vettore (molto lungo...)
// Codice normale
int max = Vect.Max();
/Codice parallelo
int max = Vect.AsParallel().Max();
Se invece vuoi renderizzare un'immagine, passando attraverso uno dei modelli tipo Phong o Radiosity (o una qualsiasi funzione lenta da ripetere piu' volte con input diversi)
// Codice normale
for(int y=0; y<maxY; y++)
{
for(int x=0; x<maxX; x++)
{
Pixel[y,x] = Radiosity(map, y, x);
}
}
//Codice Parallelo
Parallel.For(0, MaxY, y=>
{
for(int x=0; x<maxX; x++)
{
Pixel[y,x] = Radiosity(map, y, x);
}
});
malocchio
10-12-2008, 23:27
Non per tirarmela, ma Java ha una gestione del multi-threading invidiata da tutti.
prevedo risposte astiose :mad:
prevedo risposte astiose :mad:
gugoXX
10-12-2008, 23:47
Non per tirarmela, ma Java ha una gestione del multi-threading invidiata da tutti.
prevedo risposte astiose :mad:
Una volta.
prevedo risposte astiose :mad:
Una volta.
^TiGeRShArK^
11-12-2008, 00:11
Non per tirarmela, ma Java ha una gestione del multi-threading invidiata da tutti.
prevedo risposte astiose :mad:
prova a fare in java, in maniera semplice, qualcosa di equivalente a quello che ha scritto gugoxx fatto in C# con il PLINQ e posta il codice ;)
prevedo risposte astiose :mad:
prova a fare in java, in maniera semplice, qualcosa di equivalente a quello che ha scritto gugoxx fatto in C# con il PLINQ e posta il codice ;)
banryu79
11-12-2008, 09:35
prova a fare in java, in maniera semplice, qualcosa di equivalente a quello che ha scritto gugoxx fatto in C# con il PLINQ e posta il codice ;)
Quoto, e guardando il codice per il parallellismo in C# postato da GugoXX, invidio questa caratteristica (lavoro in Java).
In Java hai il multithreading, è vero, ma non hai il parallellismo ne lo puoi implementare facilmente.
Creare più thread non significa che in una macchina dual core, ad esempio, i thread verranno ripartiti su entrambe le cpu: dato che appartengono comunque allo stesso processo che li ha creati (la nostra applicazione) andranno in esecuzione comunque su una singola cpu (anche perchè essendo dei Thread e non dei Processi, condividono appunto lo stesso contesto e lo spazio di memoria allocato per il Processo da cui vengono creati).
Io almeno la sapevo così.
@EDIT (per i posteri):
Ho detto cazzate, questo mio post è fuffa.
Quoto, e guardando il codice per il parallellismo in C# postato da GugoXX, invidio questa caratteristica (lavoro in Java).
In Java hai il multithreading, è vero, ma non hai il parallellismo ne lo puoi implementare facilmente.
Creare più thread non significa che in una macchina dual core, ad esempio, i thread verranno ripartiti su entrambe le cpu: dato che appartengono comunque allo stesso processo che li ha creati (la nostra applicazione) andranno in esecuzione comunque su una singola cpu (anche perchè essendo dei Thread e non dei Processi, condividono appunto lo stesso contesto e lo spazio di memoria allocato per il Processo da cui vengono creati).
Io almeno la sapevo così.
@EDIT (per i posteri):
Ho detto cazzate, questo mio post è fuffa.
^TiGeRShArK^
11-12-2008, 09:39
Quoto, e guardando il codice per il parallellismo in C# postato da GugoXX, invidio questa caratteristica (lavoro in Java).
In Java hai il multithreading, è vero, ma non hai il parallellismo ne lo puoi implementare facilmente.
Creare più thread non significa che in una macchina dual core, ad esempio, i thread verranno ripartiti su entrambe le cpu: dato che appartengono comunque allo stesso processo che li ha creati (la nostra applicazione) andranno in esecuzione comunque su una singola cpu (anche perchè essendo dei Thread e non dei Processi, condividono appunto lo stesso contesto e lo spazio di memoria allocato per il Processo da cui vengono creati).
Io almeno la sapevo così.
no, i thread girano su + core dato che sono definiti come la minima unità di esecuzione sequenziale o qualcosa del genere :p
Infatti se provi a lanciare il codice di gugoxx vedi nel task manager un unico processo, ma il lavoro è suddiviso in n thread :p
questa limitazione invece c'è in python, ma è dovuta + che altro al global interlock..o come diamine si chiama :D
In Java hai il multithreading, è vero, ma non hai il parallellismo ne lo puoi implementare facilmente.
Creare più thread non significa che in una macchina dual core, ad esempio, i thread verranno ripartiti su entrambe le cpu: dato che appartengono comunque allo stesso processo che li ha creati (la nostra applicazione) andranno in esecuzione comunque su una singola cpu (anche perchè essendo dei Thread e non dei Processi, condividono appunto lo stesso contesto e lo spazio di memoria allocato per il Processo da cui vengono creati).
Io almeno la sapevo così.
no, i thread girano su + core dato che sono definiti come la minima unità di esecuzione sequenziale o qualcosa del genere :p
Infatti se provi a lanciare il codice di gugoxx vedi nel task manager un unico processo, ma il lavoro è suddiviso in n thread :p
questa limitazione invece c'è in python, ma è dovuta + che altro al global interlock..o come diamine si chiama :D
gugoXX
11-12-2008, 09:44
Si, vero, per fortuna i Thread vengono ripartiti tra le CPU. Condividono si' la stessa memoria, che appunto e' unica per tutta la macchina.
Diverso e' il discorso delle cache dedicata ad ogni singolo core/processore, e li' appunto si annida qualche problema del parallelismo.
Diverso e' il discorso delle cache dedicata ad ogni singolo core/processore, e li' appunto si annida qualche problema del parallelismo.
banryu79
11-12-2008, 09:50
snip
Ok, mi hanno raccontato mezza fuffa allora, o son io che mi ricordo male e ho fatto un pastrocchio in testa :D
Ok, mi hanno raccontato mezza fuffa allora, o son io che mi ricordo male e ho fatto un pastrocchio in testa :D
^TiGeRShArK^
11-12-2008, 09:50
Si, vero, per fortuna i Thread vengono ripartiti tra le CPU. Condividono si' la stessa memoria, che appunto e' unica per tutta la macchina.
Diverso e' il discorso delle cache dedicata ad ogni singolo core/processore, e li' appunto si annida qualche problema del parallelismo.
tipo quello che avevi detto che ti era capitato per via delle dipendenze nascoste create implicitamente da plinq?
ma cos'era capitato di preciso?:stordita:
Diverso e' il discorso delle cache dedicata ad ogni singolo core/processore, e li' appunto si annida qualche problema del parallelismo.
tipo quello che avevi detto che ti era capitato per via delle dipendenze nascoste create implicitamente da plinq?
ma cos'era capitato di preciso?:stordita:
banryu79
11-12-2008, 09:55
Si, vero, per fortuna i Thread vengono ripartiti tra le CPU. Condividono si' la stessa memoria, che appunto e' unica per tutta la macchina.
Diverso e' il discorso delle cache dedicata ad ogni singolo core/processore, e li' appunto si annida qualche problema del parallelismo.
Um, ok adesso mi è più chiaro, grazie.
Diverso e' il discorso delle cache dedicata ad ogni singolo core/processore, e li' appunto si annida qualche problema del parallelismo.
Um, ok adesso mi è più chiaro, grazie.
cdimauro
11-12-2008, 10:01
no, i thread girano su + core dato che sono definiti come la minima unità di esecuzione sequenziale o qualcosa del genere :p
Infatti se provi a lanciare il codice di gugoxx vedi nel task manager un unico processo, ma il lavoro è suddiviso in n thread :p
questa limitazione invece c'è in python, ma è dovuta + che altro al global interlock..o come diamine si chiama :D
Sì (si chiama GIL: Global Interpreter Lock), ma una limitazione che è stata superata in Python 2.6 e 3.0 con l'uso della libreria multiprocessing di cui ho postato il link prima. ;)
Infatti se provi a lanciare il codice di gugoxx vedi nel task manager un unico processo, ma il lavoro è suddiviso in n thread :p
questa limitazione invece c'è in python, ma è dovuta + che altro al global interlock..o come diamine si chiama :D
Sì (si chiama GIL: Global Interpreter Lock), ma una limitazione che è stata superata in Python 2.6 e 3.0 con l'uso della libreria multiprocessing di cui ho postato il link prima. ;)
gugoXX
11-12-2008, 10:02
tipo quello che avevi detto che ti era capitato per via delle dipendenze nascoste create implicitamente da plinq?
ma cos'era capitato di preciso?:stordita:
La dipendenza era implicita ma a livello hardware. PLINQ poteva farci poco ed era colpa mia.
Era capitato che, nello scrivere il risultato vettoriale di un processo in un array di interi a 32bit, avessi spaccato il ciclo in 2, scrivendo semplicemente con un thread negli indici pari del vettore, e con un altro thread negli indici dispari.
In teoria tutto bene, gli indici erano deterministicamente suddivisi, non c'era condivisione di memoria e non c'era quindi da piazzare nessun lock esplicito.
Ma non c'era nessuna differenza con il singolo thread. Anzi, c'era addirittura un peggioramento e non capivo il perche'.
Leggendo qua e la' ho poi capito il perche'.
Le linee di cache del mio microprocessore sono a 64bit. Capitava quindi che nello scrivere un int32 da parte del processo del core che scriveva sugli indici pari nella propria cache, si attivasse il processo di snooping hardware che lockava la cella corrispondente nella cache dell'altro core, che corrispondeva guarda caso proprio all'indice dispari che sarebbe stato scritto da questo core in questo ciclo.
Peggio che un processo monothread.
Soluzione: Spaccare il ciclo in 2, assegnando il lavoro 0 -> N/2 al primo core e N/2 -> N al secondo core.
Nei parallelismi in cui si sfrutta il parallelismo per eseguire tante operazioni semplici, non bisognerebbe quindi mai spaccare pari/dispari o consecutivi.
Nel caso di parallelismi in cui si sfrutta il parallelismo per eseguire poche operazioni complesse questo effetto e' invece mascherato e si puo' ignorare.
ma cos'era capitato di preciso?:stordita:
La dipendenza era implicita ma a livello hardware. PLINQ poteva farci poco ed era colpa mia.
Era capitato che, nello scrivere il risultato vettoriale di un processo in un array di interi a 32bit, avessi spaccato il ciclo in 2, scrivendo semplicemente con un thread negli indici pari del vettore, e con un altro thread negli indici dispari.
In teoria tutto bene, gli indici erano deterministicamente suddivisi, non c'era condivisione di memoria e non c'era quindi da piazzare nessun lock esplicito.
Ma non c'era nessuna differenza con il singolo thread. Anzi, c'era addirittura un peggioramento e non capivo il perche'.
Leggendo qua e la' ho poi capito il perche'.
Le linee di cache del mio microprocessore sono a 64bit. Capitava quindi che nello scrivere un int32 da parte del processo del core che scriveva sugli indici pari nella propria cache, si attivasse il processo di snooping hardware che lockava la cella corrispondente nella cache dell'altro core, che corrispondeva guarda caso proprio all'indice dispari che sarebbe stato scritto da questo core in questo ciclo.
Peggio che un processo monothread.
Soluzione: Spaccare il ciclo in 2, assegnando il lavoro 0 -> N/2 al primo core e N/2 -> N al secondo core.
Nei parallelismi in cui si sfrutta il parallelismo per eseguire tante operazioni semplici, non bisognerebbe quindi mai spaccare pari/dispari o consecutivi.
Nel caso di parallelismi in cui si sfrutta il parallelismo per eseguire poche operazioni complesse questo effetto e' invece mascherato e si puo' ignorare.
The_ouroboros
11-12-2008, 10:02
Sì (si chiama GIL: Global Interpreter Lock), ma una limitazione che è stata superata in Python 2.6 e 3.0 con l'uso della libreria multiprocessing di cui ho postato il link prima. ;)
ho gia detto che amo il python?:D
ho gia detto che amo il python?:D
^TiGeRShArK^
11-12-2008, 10:07
Sì (si chiama GIL: Global Interpreter Lock), ma una limitazione che è stata superata in Python 2.6 e 3.0 con l'uso della libreria multiprocessing di cui ho postato il link prima. ;)
mmmm...
non mi pare..
quella non serve per creare + processi?
La limitazione sui thread in parallelo c'è sempre, quello che è stata aggiunta è la possibilità di utilizzare più facilmente dei processi in parallelo se non ricordo male :p
mmmm...
non mi pare..
quella non serve per creare + processi?
La limitazione sui thread in parallelo c'è sempre, quello che è stata aggiunta è la possibilità di utilizzare più facilmente dei processi in parallelo se non ricordo male :p
^TiGeRShArK^
11-12-2008, 10:11
La dipendenza era implicita ma a livello hardware. PLINQ poteva farci poco ed era colpa mia.
Era capitato che, nello scrivere il risultato vettoriale di un processo in un array di interi a 32bit, avessi spaccato il ciclo in 2, scrivendo semplicemente con un thread negli indici pari del vettore, e con un altro thread negli indici dispari.
In teoria tutto bene, gli indici erano deterministicamente suddivisi, non c'era condivisione di memoria e non c'era quindi da piazzare nessun lock esplicito.
Ma non c'era nessuna differenza con il singolo thread. Anzi, c'era addirittura un peggioramento e non capivo il perche'.
Leggendo qua e la' ho poi capito il perche'.
Le linee di cache del mio microprocessore sono a 64bit. Capitava quindi che nello scrivere un int32 da parte del processo del core che scriveva sugli indici pari nella propria cache, si attivasse il processo di snooping hardware che lockava la cella corrispondente nella cache dell'altro core, che corrispondeva guarda caso proprio all'indice dispari che sarebbe stato scritto da questo core in questo ciclo.
Peggio che un processo monothread.
Soluzione: Spaccare il ciclo in 2, assegnando il lavoro 0 -> N/2 al primo core e N/2 -> N al secondo core.
Nei parallelismi in cui si sfrutta il parallelismo per eseguire tante operazioni semplici, non bisognerebbe quindi mai spaccare pari/dispari o consecutivi.
Nel caso di parallelismi in cui si sfrutta il parallelismo per eseguire poche operazioni complesse questo effetto e' invece mascherato e si puo' ignorare.
ah ok capito + o -..
anche se mi sfugge il fatto per cui venisse bloccato l'indice corrispondente alla stessa linea di cache nell'altro core..:fagiano:
Era capitato che, nello scrivere il risultato vettoriale di un processo in un array di interi a 32bit, avessi spaccato il ciclo in 2, scrivendo semplicemente con un thread negli indici pari del vettore, e con un altro thread negli indici dispari.
In teoria tutto bene, gli indici erano deterministicamente suddivisi, non c'era condivisione di memoria e non c'era quindi da piazzare nessun lock esplicito.
Ma non c'era nessuna differenza con il singolo thread. Anzi, c'era addirittura un peggioramento e non capivo il perche'.
Leggendo qua e la' ho poi capito il perche'.
Le linee di cache del mio microprocessore sono a 64bit. Capitava quindi che nello scrivere un int32 da parte del processo del core che scriveva sugli indici pari nella propria cache, si attivasse il processo di snooping hardware che lockava la cella corrispondente nella cache dell'altro core, che corrispondeva guarda caso proprio all'indice dispari che sarebbe stato scritto da questo core in questo ciclo.
Peggio che un processo monothread.
Soluzione: Spaccare il ciclo in 2, assegnando il lavoro 0 -> N/2 al primo core e N/2 -> N al secondo core.
Nei parallelismi in cui si sfrutta il parallelismo per eseguire tante operazioni semplici, non bisognerebbe quindi mai spaccare pari/dispari o consecutivi.
Nel caso di parallelismi in cui si sfrutta il parallelismo per eseguire poche operazioni complesse questo effetto e' invece mascherato e si puo' ignorare.
ah ok capito + o -..
anche se mi sfugge il fatto per cui venisse bloccato l'indice corrispondente alla stessa linea di cache nell'altro core..:fagiano:
das
11-12-2008, 11:31
La dipendenza era implicita ma a livello hardware. PLINQ poteva farci poco ed era colpa mia.
Era capitato che, nello scrivere il risultato vettoriale di un processo in un array di interi a 32bit, avessi spaccato il ciclo in 2, scrivendo semplicemente con un thread negli indici pari del vettore, e con un altro thread negli indici dispari.
In teoria tutto bene, gli indici erano deterministicamente suddivisi, non c'era condivisione di memoria e non c'era quindi da piazzare nessun lock esplicito.
Ma non c'era nessuna differenza con il singolo thread. Anzi, c'era addirittura un peggioramento e non capivo il perche'.
Leggendo qua e la' ho poi capito il perche'.
Le linee di cache del mio microprocessore sono a 64bit. Capitava quindi che nello scrivere un int32 da parte del processo del core che scriveva sugli indici pari nella propria cache, si attivasse il processo di snooping hardware che lockava la cella corrispondente nella cache dell'altro core, che corrispondeva guarda caso proprio all'indice dispari che sarebbe stato scritto da questo core in questo ciclo.
Peggio che un processo monothread.
Soluzione: Spaccare il ciclo in 2, assegnando il lavoro 0 -> N/2 al primo core e N/2 -> N al secondo core.
Nei parallelismi in cui si sfrutta il parallelismo per eseguire tante operazioni semplici, non bisognerebbe quindi mai spaccare pari/dispari o consecutivi.
Nel caso di parallelismi in cui si sfrutta il parallelismo per eseguire poche operazioni complesse questo effetto e' invece mascherato e si puo' ignorare.
Come hai fatto ad accorgertene ?
Era capitato che, nello scrivere il risultato vettoriale di un processo in un array di interi a 32bit, avessi spaccato il ciclo in 2, scrivendo semplicemente con un thread negli indici pari del vettore, e con un altro thread negli indici dispari.
In teoria tutto bene, gli indici erano deterministicamente suddivisi, non c'era condivisione di memoria e non c'era quindi da piazzare nessun lock esplicito.
Ma non c'era nessuna differenza con il singolo thread. Anzi, c'era addirittura un peggioramento e non capivo il perche'.
Leggendo qua e la' ho poi capito il perche'.
Le linee di cache del mio microprocessore sono a 64bit. Capitava quindi che nello scrivere un int32 da parte del processo del core che scriveva sugli indici pari nella propria cache, si attivasse il processo di snooping hardware che lockava la cella corrispondente nella cache dell'altro core, che corrispondeva guarda caso proprio all'indice dispari che sarebbe stato scritto da questo core in questo ciclo.
Peggio che un processo monothread.
Soluzione: Spaccare il ciclo in 2, assegnando il lavoro 0 -> N/2 al primo core e N/2 -> N al secondo core.
Nei parallelismi in cui si sfrutta il parallelismo per eseguire tante operazioni semplici, non bisognerebbe quindi mai spaccare pari/dispari o consecutivi.
Nel caso di parallelismi in cui si sfrutta il parallelismo per eseguire poche operazioni complesse questo effetto e' invece mascherato e si puo' ignorare.
Come hai fatto ad accorgertene ?
gugoXX
11-12-2008, 13:54
Come hai fatto ad accorgertene ?
Avevo messo il parallelismo sperando in tempistiche migliori, e invece i tempi erano aumentati...
Avevo messo il parallelismo sperando in tempistiche migliori, e invece i tempi erano aumentati...
cdimauro
11-12-2008, 14:36
ho gia detto che amo il python?:D
:p
mmmm...
non mi pare..
quella non serve per creare + processi?
Sì.
La limitazione sui thread in parallelo c'è sempre, quello che è stata aggiunta è la possibilità di utilizzare più facilmente dei processi in parallelo se non ricordo male :p
Mea culpa, dovevo essere più chiaro. La limitazione della GIL ovviamente permane per i thread associati al singolo processo.
Con Python ciò che mancava era la possibilità di sfruttare più core, e adesso ciò è possibile. :)
ah ok capito + o -..
anche se mi sfugge il fatto per cui venisse bloccato l'indice corrispondente alla stessa linea di cache nell'altro core..:fagiano:
Perché la linea di cache è a 64 bit, per cui in una linea di cache trovi 2 interi a 32 bit memorizzati: il primo che riguarda il primo indice e il secondo che riguarda il secondo indice, appunto. Poiché il primo thread accede al primo indice e il secondo thread al secondo, c'è chiaramente un conflitto d'accesso e da lì scatta il meccanismo dello snooping.
:p
mmmm...
non mi pare..
quella non serve per creare + processi?
Sì.
La limitazione sui thread in parallelo c'è sempre, quello che è stata aggiunta è la possibilità di utilizzare più facilmente dei processi in parallelo se non ricordo male :p
Mea culpa, dovevo essere più chiaro. La limitazione della GIL ovviamente permane per i thread associati al singolo processo.
Con Python ciò che mancava era la possibilità di sfruttare più core, e adesso ciò è possibile. :)
ah ok capito + o -..
anche se mi sfugge il fatto per cui venisse bloccato l'indice corrispondente alla stessa linea di cache nell'altro core..:fagiano:
Perché la linea di cache è a 64 bit, per cui in una linea di cache trovi 2 interi a 32 bit memorizzati: il primo che riguarda il primo indice e il secondo che riguarda il secondo indice, appunto. Poiché il primo thread accede al primo indice e il secondo thread al secondo, c'è chiaramente un conflitto d'accesso e da lì scatta il meccanismo dello snooping.
^TiGeRShArK^
11-12-2008, 14:48
Perché la linea di cache è a 64 bit, per cui in una linea di cache trovi 2 interi a 32 bit memorizzati: il primo che riguarda il primo indice e il secondo che riguarda il secondo indice, appunto. Poiché il primo thread accede al primo indice e il secondo thread al secondo, c'è chiaramente un conflitto d'accesso e da lì scatta il meccanismo dello snooping.
vero...se il primo è pari il secondo è dispari :doh:
si vede che non ho chiuso occhio per tutta la notte, vero :stordita:
vero...se il primo è pari il secondo è dispari :doh:
si vede che non ho chiuso occhio per tutta la notte, vero :stordita:
cdimauro
11-12-2008, 15:03
A chi lo dici: è da un più di un mese che mio figlio ha deciso di svegliarsi puntualmente nel bel mezzo della notte. Dormiree... che bella parola...
vBulletin® v3.6.4, Copyright ©2000-2026, Jelsoft Enterprises Ltd.