Discussion :

[komando]

Voila, j'ai un grand tableau de double qu'on notera data,
J'applique un traitement lourd sur chaque element du data

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
double[] data;
remplirData();
for(int i=0 ; i<data.length; i++){
double resultat = traitementlourd(data[i]);
}

Afin d'optimiser ce traitement qui dure quelques secondes (15s), j'ai pensé à utiliser le multi-threading, çad diviser le traitement sur plusieurs threads et chaque thread pas s'occuper d'une partie du tableau;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
ouble[] data;
remplirData();
ExecutorService executor = Executors.newFixedThreadPool(2);
int size = data.length;
TraitementWorker worker1 = new TraitementWorker(0, size / 2);
TraitementWorker worker2 = new TraitementWorker(size /2 +1 ,size - 1);
executor.execute(worker1);
executor.execute(worker2);
executor.shutdown();

Je croyais que ce code va parralléliser les traitements et j'obtiendrai un certain gain de perfs. Mais voilà, les deux threads s'executent chaqune en 15 secondes . Lorsque je lance un seul : 7s

Est-ce que mon raisonnement est faux ou c'est qq chose d'autre ?

[natha]

L'idéal serait que tu t'informes sur le fonctionnement du multi-threading en java. Pour ton traitement, sur un PC mono-proc, tu ne risques pas d'avoir un gain de perf car au lieu de faire 1x le même traitement, tu le fais 2 fois (ça augmente le nombre d'objet instanciés par exemple).

Un autre exemple : j'avais une fois 4 gros objets à créer, chacun prenant dans les 4 secondes si je les faisais l'un à la suite. J'ai pensé au multi-thread et résultat : le premier prenais 5 secondes, le second 9s, le troisième 13s et le dernier 16s. Au total ça ne changeait rien (je rappelle que 4x4=16 ). Le truc c'est que le traitement du 4e objet est ralenti par le traitement en parallèle des 3 autres.

[deltree]

- Vérifie que ton executor te lance bien les Worker dans 2 Thread séparés.
(mettre un break point sur le Worker, les 2 Threads doivent s'arrêter)
- Regarde si ton traitement n'utilise pas des objets synchronisés?

- effectivement, c'est mieux d'avoir un dual core pour ça, c'est bien le cas?

[komando]

Merci pour vos réponses,

non je n'ai pas de dual core et je vais pas tarder à faire un test dessus (théoriquement je dois observer un gain cette fois )

je n'utilise pas des objets synchronisés, j'ai même divisé l'entrée des 2 threads en 2 tableaux séparés histoire d'être sûr.

je vais me documenter encore plus sur le sujet et je vous informe si je trouve qq chose. (Il y a bien la bibliothèque javolution mais c'est un autre sujet)

Si je résume bien, ma démarche n'est valide que sur des système multi-processeurs?

[natha]

Si je résume bien, ma démarche n'est valide que sur des système multi-processeurs?

Même pas forcément. Dans ton cas je vois pas l'utilité. Un multi-proc ne te donnera pas un gain significatif. Splitter un traitement long en 2 n'est pas efficace. Peut-être que ça serait plus efficace si tu le splittes en 10 par exemple.

[deltree]

Si je résume bien, ma démarche n'est valide que sur des système multi-processeurs?

Rien ne t'empêche de mettre au point tes Thread sur un mono-proc (il faut t'assurer que les Thread tourne bien en parallèle)
par contre l'accélération ne sera possible qu'en multi-proc (tu a un risque de ralentir au contraire sur un monoproc)

Même pas forcément. Dans ton cas je vois pas l'utilité. Un multi-proc ne te donnera pas un gain significatif. Splitter un traitement long en 2 n'est pas efficace. Peut-être que ça serait plus efficace si tu le splittes en 10 par exemple.

Je ne suis pas sûr de comprendre pourquoi 10 Thread?
Sur un plan théorique: 2 Thread de 15 secondes seront plus rapides qu'un seul de 30.
Dans la pratique, il y a le risque que les Thread ne soient pas bien répartis entre processeurs, Augmenter leur nombre permet sans doute de palier à ce risque, mais c'est à verifier par expérimentation, et au cas par cas selon l'algo.

Pour bien faire, il faudrait adapter le nombre de Thread au nombre de proc:4, 8 ou plus:sur les serveurs, ça peut arriver, et dans l'avenir, on aura plus couramment des quad-core.