Torna indietro   Hardware Upgrade Forum > Software > Programmazione

Sony INZONE H6 Air: il primo headset open-back di Sony per giocatori
Sony INZONE H6 Air: il primo headset open-back di Sony per giocatori
Il primo headset open-back della linea INZONE arriva a 200 euro con driver derivati dalle cuffie da studio MDR-MV1 e un peso record di soli 199 grammi
Nutanix cambia pelle: dall’iperconvergenza alla piattaforma full stack per cloud ibrido e IA
Nutanix cambia pelle: dall’iperconvergenza alla piattaforma full stack per cloud ibrido e IA
Al .NEXT 2026 di Chicago, Nutanix ha mostrato quanto sia cambiata: una piattaforma software che gestisce VM, container e carichi di lavoro IA ovunque, dall’on-premise al cloud pubblico. Con un’esecuzione rapidissima sulle partnership e sulla migrazione da VMware
Recensione Xiaomi Pad 8 Pro: potenza bruta e HyperOS 3 per sfidare la fascia alta
Recensione Xiaomi Pad 8 Pro: potenza bruta e HyperOS 3 per sfidare la fascia alta
Xiaomi Pad 8 Pro adotta il potente Snapdragon 8 Elite all'interno di un corpo con spessore di soli 5,75 mm e pannello LCD a 144Hz flicker-free, per un tablet che può essere utilizzato con accessori dedicati di altissima qualità. Fra le caratteristiche esclusive, soprattutto per chi intende usarlo con la tastiera ufficiale, c'è la modalità Workstation di HyperOS 3, che trasforma Android in un sistema operativo con interfaccia a finestre
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 27-03-2011, 13:15   #1
Lim
Senior Member
 
L'Avatar di Lim
 
Iscritto dal: Dec 2000
Messaggi: 501
[JAVA] Ottimizzazione del Multithreading

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!
Lim è offline   Rispondi citando il messaggio o parte di esso
Old 27-03-2011, 14:39   #2
lefantome
Member
 
Iscritto dal: Dec 2007
Messaggi: 284
Quote:
Originariamente inviato da Lim Guarda i messaggi
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?
lefantome è offline   Rispondi citando il messaggio o parte di esso
Old 27-03-2011, 14:56   #3
WarDuck
Senior Member
 
L'Avatar di WarDuck
 
Iscritto dal: May 2001
Messaggi: 12966
Istanziare nuovi thread comporta un dispendio di tempo, dai un'occhiata a questo:

http://download.oracle.com/javase/tu...ncy/pools.html
WarDuck è offline   Rispondi citando il messaggio o parte di esso
Old 27-03-2011, 15:43   #4
Gin&&Tonic
Member
 
L'Avatar di Gin&&Tonic
 
Iscritto dal: Aug 2010
Messaggi: 138
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 ).
Gin&&Tonic è offline   Rispondi citando il messaggio o parte di esso
Old 27-03-2011, 19:26   #5
Lim
Senior Member
 
L'Avatar di Lim
 
Iscritto dal: Dec 2000
Messaggi: 501
Quote:
Originariamente inviato da lefantome Guarda i messaggi
ma questi oggetti non interagiscono tra di loro?
Si, interagiscono, ma non in quella fase, quindi li posso "elaborare" simultaneamente.


Quote:
Originariamente inviato da WarDuck Guarda i messaggi
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.

Quote:
Originariamente inviato da Gin&&Tonic Guarda i messaggi
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!
Lim è offline   Rispondi citando il messaggio o parte di esso
Old 27-03-2011, 21:23   #6
FabryHw
Bannato
 
Iscritto dal: Apr 2006
Messaggi: 5857
Quote:
Originariamente inviato da Lim Guarda i messaggi
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.
FabryHw è offline   Rispondi citando il messaggio o parte di esso
Old 28-03-2011, 00:26   #7
clockover
Senior Member
 
L'Avatar di clockover
 
Iscritto dal: Oct 2004
Messaggi: 1945
Quote:
Originariamente inviato da WarDuck Guarda i messaggi
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
clockover è offline   Rispondi citando il messaggio o parte di esso
Old 28-03-2011, 07:41   #8
Lim
Senior Member
 
L'Avatar di Lim
 
Iscritto dal: Dec 2000
Messaggi: 501
Quote:
Originariamente inviato da FabryHw Guarda i messaggi
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.
Quote:
Originariamente inviato da clockover Guarda i messaggi
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 è offline   Rispondi citando il messaggio o parte di esso
Old 28-03-2011, 07:51   #9
Lim
Senior Member
 
L'Avatar di Lim
 
Iscritto dal: Dec 2000
Messaggi: 501
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):

Codice:
...
//#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?
Lim è offline   Rispondi citando il messaggio o parte di esso
Old 28-03-2011, 13:54   #10
PGI-Bis
Senior Member
 
L'Avatar di PGI-Bis
 
Iscritto dal: Nov 2004
Città: Tra Verona e Mantova
Messaggi: 4553
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.
__________________
Uilliam Scecspir ti fa un baffo? Gioffri Cioser era uno straccione? E allora blogga anche tu, in inglese come me!
PGI-Bis è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


Sony INZONE H6 Air: il primo headset open-back di Sony per giocatori Sony INZONE H6 Air: il primo headset open-back d...
Nutanix cambia pelle: dall’iperconvergenza alla piattaforma full stack per cloud ibrido e IA Nutanix cambia pelle: dall’iperconvergenza alla ...
Recensione Xiaomi Pad 8 Pro: potenza bruta e HyperOS 3 per sfidare la fascia alta Recensione Xiaomi Pad 8 Pro: potenza bruta e Hyp...
NZXT H9 Flow RGB+, Kraken Elite 420 e F140X: abbiamo provato il tris d'assi di NZXT NZXT H9 Flow RGB+, Kraken Elite 420 e F140X: abb...
ASUS ROG Swift OLED PG34WCDN recensione: il primo QD-OLED RGB da 360 Hz ASUS ROG Swift OLED PG34WCDN recensione: il prim...
Ecovacs presenta la gamma 2026: paviment...
Efficienza energetica fino a 2.000 volte...
Lenovo 360: il programma di canale dell'...
Appena 10.000 qubit per rompere la critt...
Analisi dei transistor durante il funzio...
Attacco informatico a Booking.com: espos...
A quattro mesi dal divieto dei social ne...
NVIDIA GeForce RTX 5060 e 5060 Ti: in ar...
Rebellions, Arm e SK Telecom, nuova alle...
Modernizzazione delle app: Red Hat OpenS...
Nel mirino di Google c'è il back ...
PRAGMATA in bundle con GeForce RTX 5000:...
Le novità MOVA per il 2026: robot e impi...
Windows, stop all'attivazione telefonica...
ASUS porta la serie TUF nel formato Mini...
Chromium
GPU-Z
OCCT
LibreOffice Portable
Opera One Portable
Opera One 106
CCleaner Portable
CCleaner Standard
Cpu-Z
Driver NVIDIA GeForce 546.65 WHQL
SmartFTP
Trillian
Google Chrome Portable
Google Chrome 120
VirtualBox
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 07:22.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Served by www3v