[Generico]Parallel computing

[The_ouroboros]

Chi mi sa dire di sull'argomento Parallel computing..
E soprattutto, oltre a OpenMp che in gcc è supportato... esiste altro?


Grazie

[The_ouroboros]

up

[cdimauro]

M'era sfuggito questo thread. Ecco qui: http://docs.python.org/library/multi...ultiprocessing

[The_ouroboros]

quanto amo il python

[gugoXX]

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);
   }
});

[malocchio]

Non per tirarmela, ma Java ha una gestione del multi-threading invidiata da tutti.


prevedo risposte astiose

[gugoXX]

Originariamente inviato da malocchio

Non per tirarmela, ma Java ha una gestione del multi-threading invidiata da tutti.


prevedo risposte astiose

Una volta.

[^TiGeRShArK^]

Originariamente inviato da malocchio

Non per tirarmela, ma Java ha una gestione del multi-threading invidiata da tutti.


prevedo risposte astiose

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]

Originariamente inviato da ^TiGeRShArK^

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.

[^TiGeRShArK^]

Originariamente inviato da banryu79

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
Infatti se provi a lanciare il codice di gugoxx vedi nel task manager un unico processo, ma il lavoro è suddiviso in n thread
questa limitazione invece c'è in python, ma è dovuta + che altro al global interlock..o come diamine si chiama

[gugoXX]

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.

[banryu79]

Originariamente inviato da ^TiGeRShArK^

snip

Ok, mi hanno raccontato mezza fuffa allora, o son io che mi ricordo male e ho fatto un pastrocchio in testa

[^TiGeRShArK^]

Originariamente inviato da gugoXX

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?

[banryu79]

Originariamente inviato da gugoXX

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.

[cdimauro]

Originariamente inviato da ^TiGeRShArK^

no, i thread girano su + core dato che sono definiti come la minima unità di esecuzione sequenziale o qualcosa del genere
Infatti se provi a lanciare il codice di gugoxx vedi nel task manager un unico processo, ma il lavoro è suddiviso in n thread
questa limitazione invece c'è in python, ma è dovuta + che altro al global interlock..o come diamine si chiama

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]

Originariamente inviato da ^TiGeRShArK^

tipo quello che avevi detto che ti era capitato per via delle dipendenze nascoste create implicitamente da plinq?
ma cos'era capitato di preciso?

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]

Originariamente inviato da cdimauro

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?

[^TiGeRShArK^]

Originariamente inviato da cdimauro

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

[^TiGeRShArK^]

Originariamente inviato da gugoXX

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..

[das]

Originariamente inviato da gugoXX

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 ?