[JAVA] Ottimizzazione del Multithreading

[Lim]

Salve,
ho scritto un software in JAVA che simula un ambiente fisico.
Ad ogni step temporale è necessario manipolare un elevato numero di oggetti (decine di migliaia) e quindi ho pensato di utilizzare i thread per cercare di parallelizzare il lavoro, mediante il seguente approccio:

Ad ogni step temporale vengono instanziati un numero predeterminato di Thread (ad esempio 4), quindi ogni Thread manipolerà un quarto degli elementi.
I Thread vengono avviati simultaneamente e vengono sincronizzati (Thread.join()) per far sì che la simulazione proceda verso le operazioni successive soltanto se tutti i thread hanno completato il loro lavoro.
Mi sono reso conto, che con questo approccio i miei due core vengono impegnati circa al 40-50% l'uno (ovviamente l'ideale sarebbe impegnarli al 100%).
Come potrei fare per migliorare le prestazioni? E' possibile che il problema dipenda dal fatto che ad ogni step temporale instanzio 4 nuovi Thread? oppure è ininfluente?

E' possibile, inoltre, che l'occupazione dei core risulti scarsa perché devono restare in attesa che il thread + lento termini l'elaborazione? (in linea di massima hanno tutti lo stesso numero di elementi da manipolare).

Ogni suggerimento è ben accetto!

[lefantome]

Originariamente inviato da Lim

Salve,
ho scritto un software in JAVA che simula un ambiente fisico.
Ad ogni step temporale è necessario manipolare un elevato numero di oggetti (decine di migliaia) e quindi ho pensato di utilizzare i thread per cercare di parallelizzare il lavoro, mediante il seguente approccio:

Ad ogni step temporale vengono instanziati un numero predeterminato di Thread (ad esempio 4), quindi ogni Thread manipolerà un quarto degli elementi.
I Thread vengono avviati simultaneamente e vengono sincronizzati (Thread.join()) per far sì che la simulazione proceda verso le operazioni successive soltanto se tutti i thread hanno completato il loro lavoro.
Mi sono reso conto, che con questo approccio i miei due core vengono impegnati circa al 40-50% l'uno (ovviamente l'ideale sarebbe impegnarli al 100%).
Come potrei fare per migliorare le prestazioni? E' possibile che il problema dipenda dal fatto che ad ogni step temporale instanzio 4 nuovi Thread? oppure è ininfluente?

E' possibile, inoltre, che l'occupazione dei core risulti scarsa perché devono restare in attesa che il thread + lento termini l'elaborazione? (in linea di massima hanno tutti lo stesso numero di elementi da manipolare).

Ogni suggerimento è ben accetto!

ma questi oggetti non interagiscono tra di loro?

[WarDuck]

Istanziare nuovi thread comporta un dispendio di tempo, dai un'occhiata a questo:

http://download.oracle.com/javase/tu...ncy/pools.html

[Gin&&Tonic]

Sicuro che non dipendi anche dal S.O. ? se è a 32 bit (e quindi per forza la JVM è a 32 bit) più di 1.6-1.8GB di ram totali NON puoi usare (condivisi tra tutti i programmi Java in esecuzione parallela ).

[Lim]

Originariamente inviato da lefantome

ma questi oggetti non interagiscono tra di loro?

Si, interagiscono, ma non in quella fase, quindi li posso "elaborare" simultaneamente.

Originariamente inviato da WarDuck

Istanziare nuovi thread comporta un dispendio di tempo, dai un'occhiata a questo:

http://download.oracle.com/javase/tu...ncy/pools.html

Grazie, gli darò un'occhiata.

Originariamente inviato da Gin&&Tonic

Sicuro che non dipendi anche dal S.O. ? se è a 32 bit (e quindi per forza la JVM è a 32 bit) più di 1.6-1.8GB di ram totali NON puoi usare (condivisi tra tutti i programmi Java in esecuzione parallela ).

Uso prevalentemente S.O. a 64 bit, anche se ho avviato simulazioni anche a 32 bit. La memoria viene consumata in effetti ma non supera, di norma, 500-800 MB, ben al di sotto di 1.6 GB!

[FabryHw]

Originariamente inviato da Lim

Ogni suggerimento è ben accetto!

Non sono un esperto di multithreading sotto Java ma visto che parli di migliaia di oggetti e di voler saturare i processori, potrei suggerirti di guardare anche il nuovo modello di Threading presente in Java 7.0.

Sto parlando del Fork-Join che naturalmente scaricando una libreria da Oracle utilizzabile anche sotto Java 6.0

Magari fa al caso tuo.

[clockover]

Originariamente inviato da WarDuck

Istanziare nuovi thread comporta un dispendio di tempo, dai un'occhiata a questo:

http://download.oracle.com/javase/tu...ncy/pools.html

Più che dargli un'occhiata io userei proprio queste tecniche qui consigliate da WarDuck... ti cambierà il tutto dalla notte al giorno... in particolar modo tutto il package java.util.concurrent contiene interfacce e classi che dovrebbero fare al caso tuo.. dagli una bella letta

[Lim]

Originariamente inviato da FabryHw

Non sono un esperto di multithreading sotto Java ma visto che parli di migliaia di oggetti e di voler saturare i processori, potrei suggerirti di guardare anche il nuovo modello di Threading presente in Java 7.0.

Sto parlando del Fork-Join che naturalmente scaricando una libreria da Oracle utilizzabile anche sotto Java 6.0

Magari fa al caso tuo.

Originariamente inviato da clockover

Più che dargli un'occhiata io userei proprio queste tecniche qui consigliate da WarDuck... ti cambierà il tutto dalla notte al giorno... in particolar modo tutto il package java.util.concurrent contiene interfacce e classi che dovrebbero fare al caso tuo.. dagli una bella letta

Grazie ad entrambi!!!
Me le studierò sicuramente!


In ogni caso, qualsiasi altro suggerimento è sempre ben accetto!

[Lim]

Negli ultimi giorni stavo cercando di implementare anche le librerie OpenMP/JaMP.
Tramite delle direttive inserite nel codice consente di parallelizzare l'elaborazione di alcuni blocchi di codice, senza la necessità di utilizzare in modo esplicito i Thread (la direttiva è simile a //#omp parallel):

...
//#omp parallel for
for (int i=0;i<100000000;i++){
...
}
...

Non l'ho ancora applicata al mio codice, ho solo fatto delle classi di test.
Riesco a tenere impegnati tutti i core al 100%, ma l'elaborazione risulta molto più lenta della versione senza OpenMp...

C'è qualcuno che ha già utilizzato con successo questa tecnica?

[PGI-Bis]

Usa un profiler - nel jdk c'è jvisualvm - sul programma originale e vedi se e dove si verifica un problema.

Dalla descrizione del programma, il comportamento ottimale sarebbe rappresentato da N user thread "verdi" e uno user thread "giallo" (quello che attende che gli altri abbiano terminato il proprio compito).

Il fatto che i core non siano impegnati al 100% dovrebbe invece essere testimoniato da almeno tre user-thread in attesa che uno termini.

Esiste anche la possibilità che l'occupazione parziale delle cpu sia semplicemente dovuto ad una scarsità di istruzioni da eseguire: se il core è multithread potrebbe esserci uno slot libero, se non lo è potrebbero esserci delle pipeline non occupate.

Oppure potrebbero esserci una valanga di cache-miss dovute ad un problema di località dei dati: non ne sono certissimo ma credo che anche questo porterebbe ad un disimpegno dei core in attesa che il bus trasferisca i dati dalla memoria periferica a quella locale.