Bonjour tous,
Je programme une application de traitement d’image en java et comme ça prend du temps je tente de faire du multithreading ,je suis novice en la matière ,voila j’ai une matrice a parcourir j’applique une fonction sur la valeur de chaque case et je range le résultat dans une nouvelle matrice de même dimension ,ma question est ce que je peux lancer plusieurs threads qui vont se partager la matrice ,appliquer la fonction et ranger dans la nouvelle matrice ?,chaque thread a sa portion de lignes donc il n’ ya pas de conflit normalement ,mais est que le fait que tt les thread sollicite tous en même temps la première matrice pour lire et la deuxième pour écrire n’alourdit pas l’execution,est ce que je devrai pas plutôt recopier la portion de la matrice que le thread traite au sein d’une matrice locale du thread pour qu’il travail tranquillement ?
Merci de d’avance

Alors, pour faire une réponse simple, oui c'est possible. Mais non, ça ne sert a RIEN.

Avoir plus d'un thread pour faire un traitement n'accélère pas le traitement, et bien au contraire le ralentit (Puisqu'un thread prend de la place en mémoire (1), et que qui dit plusieurs threads dit ordonnanceur => du temps pour switcher entre différents threads).
De toute manière, un seul processeur (même si dual ou quad core, dû au verrou que tu devra mettre sur ta structure et au copies de données entre les threads pour éviter les conflits) une seule chose se passe à la fois, même si on ne le remarque pas forcément.

comme dit précédemment ...
ton processeur n'est pas une boite magique!
tu sais faire X calcules à la seconde!! pas plus ...
donc faire plusieurs thread sert à faire des choses en parallèle. pas a aller plus vite (sauf si multis core mais ça se complique)

que tu fasse
Y calcul d'un coup
ou Y1 calcul dans un premier thread
et Y2 dans un deuxieme,
au final ton processeur fera Y1+Y2=Y calcules
et il mettra (si il sait faire X calcules par secondes)
Y*X=(Y1+Y2)*X ms

Et s'il a plusieurs cœurs ou qu'il peut bénéficier d'une autre unité de calcul (par exemple sa carte graphique ou un autre poste accessible sur le réseau) ?

wildthing, en l'état actuel des choses on ne peut pas savoir si ça peut t'aider (ça dépend du matériel ainsi que des optimisations que fera la JVM). Si la matrice est vraiment grosse, oui, mais parfois on trouve des algorithmes de calcul sur une seule unité traitante qui sont plus efficaces que les versions naïves…

si il a 2 cœurs il peut faire 2 thread
quad core 4 thread ...
mais je sais plus si java gere le multiscore ou pas :s

C'est toujours mieux de faire des threads vu qu'il existe plein de pc aujourd'hui avec n coeurs.
Mais ne l'utilise que si tu pense bien pouvoir les gerer. C'est pas aussi évident.

Justement j'ai une question, j'ai un processeur dual core, y'a t'il moyen en Java que je fasse en sorte que certains traitements soient fait par un core et les autres par un autre core, parce que un étudiant de stage m'a dis que window ne gérait pas encore trop bien les processeur à plusieurs cores.

Citation : willard

C'est toujours mieux de faire des threads vu qu'il existe plein de pc aujourd'hui avec n coeurs.
Mais ne l'utilise que si tu pense bien pouvoir les gerer. C'est pas aussi évident.

Oula, connerie. Il faut minimiser au maximum le nombre de Thread que l'on utilise. C'est même dit sur le site officiel de Java. Pour limité, il y a même des threadpool et executors qui permette une gestion plus haut niveau des thread.

Si vous voulez vous convaincre que les thread c'est le mal (mais bien souvent nécessaire) en terme de performance, je peux vous ressortir les statistiques d'un programme sensé faire des opérations sur des liste chainé avec et sans thread. Serieusement, les thread doivent être évité dès que possible, il prennent beaucoup de ressources et il y a un temps pour switcher de l'un à l'autre. De plus, certes on a tous des dual ou quad core, mais ça n'enlève rien au fait qu'il y a aussi d'autre programme et un OS qui tourne sur la machine.

EDIT : Lolilolight > Il y a en C dans la librairie windows des appelles pour assigner à ton thread une affinité vers un core de ton processeur. Ca ne reste qu'une affinité, il est possible que le thread s'execute ur d'autre core dans certaines conditions, mais globalement, il s'executera sur le core demandé. Savor si cet appel existe en Java, je ne pense pas parce qu'il faudrait qu'il existe pour tous les OS, et je n'en suis pas sûr => A vérifier.

Dalshim, qu'est-ce qu'il faisait ton programme sur la liste chaînée ? Parce que tous les problèmes ne peuvent pas être décomposés parallèlement, ça c'est certain. La loi d'Amdahl exprime cette possibilité.

Le multi-cœur, c'est l'avenir… en tout cas c'est vers des processeurs à beaucoup d'unités traitantes que l'on se dirige actuellement. Ça m'étonnerait que la JVM actuelle soit si incapable de profiter de l'opportunité de plusieurs unités traitantes que tu le dis.

C'était un programme de test. Le but était de faire un programme tout con qui avait autant de thread que de coeur sur la machine. Chaque thread devait aléatoirement ajouter ou supprimer des valeurs dans une liste chainé partagé par tous. Il fallait utiliser deux méthodes, une avec des verrous (donc un thread voulant accéder à la structure ne pouvait le faire si un autre la tenait déjà), un autre sans (il existe des méthode pour ne pas utilisé de verrous, mais elles sont très (vraiment très) compliqués pour ce qu'elles offrent (c'était la conclusion du test)). Après ces deux implémentation, on a lancé le programme avec un seul thread (donc sans verrou), et le résultat était sans appel.

Ensuite, je ne vois nulle part dit que je suis contre le multi-coeur. Moi aussi, je pense que c'est ce vers quoi on tend et que c'est même une très bonne chose vu le nombre d'application que l'on execute en même temps sur nos ordi. Je ne vois nulle part non plus dit que la JVM soit incapable de profiter de l'opportunité de plusieurs unitées traitantes. J'ai juste dis que je ne pensais pas qu'il existe un appel permettant d'attribuer à un thread une affinité vers un coeur comme il en existe dans la librairie windows.h en C (Si tu me prouves le contraire, j'en serais ravi).

En revanche, j'ai dit et je maintiens que faire trop de thread, c'est le mal. Faire un thread pour un thread, c'est bête, l'ordinateur à déjà des dizaines voire centaines de processus et thread à faire tourner, ne t'inquiète pas, les deux cœurs sont utilisés. S'il y a partage de ressources, utilisé plusieurs threads ne rime que très peu souvent avec bonnes performances. Tu trouvera même sur les tutos officiels du site de sun qu'ils déconseillent l'utilisation de trop de thread car c'est mauvais pour les performances.

Ah mais Dalshim c'est normal, les verrous on sait tous que ça fout la merde, et ça empêche le vrai parallélisme. Par contre dans le cas d'une matrice, si toutes les opérations sont indépendantes, pas de verrou à poser (enfin, je ne pense pas) et donc pas de perte d'efficacité. Non j'avais pas compris que tu parlais de verrous, mais effectivement ça présente aucun intérêt de mettre des trucs à tourner en parallèle si y'a des accès concurrents trop fréquents.

Ba pour le cas présent, il a une matrice qui doit surement être un tableau à 2 dimensions. S'il veut partager le travail entre différent thread, il va falloir soit mettre un verrou sur le tableau, soit qu'il copie les parties voulues dans des sous-tableaux pour que chaque thread fasse son traitement. De même, il y aura conflit (donc verrou) pour écrire dans la matrice finale. Bref, j'ai des (très) gros doute sur l'utilité de plusieurs thread dans son cas.

Ok, ça par contre j'en ai aucune idée je sais pas comment ce qu'il utilise gère les accès concurrents.