Discussion :

[Battant]

Bonjour,

Comme les ordinateur on d'avantage de coeurs, je développe actuellement en multitread en créant une classe par fonction plutôt qu'une méthode si j'estime que celle-ci peut être exécuter en parallèle.

Maintenant, dans un formulaire, j'ai certain champs qui sont obligatoire ou doivent contenir un certain type de donnée s'il sont complété. Normalement, ce type de vérification et fait séquenciellemnent mais ai-je des avantage à implémenter ce genre de chose en multitheades ?

Si tel est le cas, je ne sais pas s'il est possible d'arrêter les thread dans le cas ou par exemple, l'utilisateur aurait oublier d'entrer des valeurs obligatoires avec quelque chose comme :

Code :

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

1
2
3
 
if (champ obligatoire vide ou incorrecte) 
executor.showtdown

ou est-ce mieux d'ajouter à coter de chaque champs un JLabel à côter de chaque champs ?

D'une manière générale, Est-ce toujours intéressant de programmer du multi-thread pour un processeur multi coeur ou arrive-t-il que la préparation des thread soit tellement couteuse en ressource qu'au final mon programme sera plus lent qu'une version monothread ?

Si on a une boucle par exemple, est-ce en remplaçant les itération par un nombre équivalant de thread, est-ce qu'on gagne en efficacité en admettant que l'on limite le nombre de thread exécuter à la fois avec executorservice ?

Salutations

[Elendhil]

En quoi ça va aider l'interface de ton programme , l'utilisation de threads pour vérifier des champs oO ?

On va utiliser les Threads uniquement sur des traitements long par exemple , tu clics sur un bouton derrière il y a un calcul qui peut durer plusieurs secondes cela évite que ton interface reste figée.

Sur des opérations qui sont instantanés cela ne sert à rien...

En règle général je dirais on programme toujours 'normalement' et si on a un besoin qui requiert forcement l'utilisation de plusieurs threads alors dans ce cas oui.

Mais faire du multi-threads pour du multi-threads , non !

Déjà parce-que c'est plus compliqué à programmer, qu'en plus cela va utiliser les ressources du système inutilement.

Si tu as une boucle avec 1000 itérations qui fait 2 additions et une multiplication sert à rien d'utiliser un thread pour cela , le calcul ce fera en moins d'une ms.

Par contre, si tu développes un jeu et que ce calcul est appelé des 100 de fois par seconde pendant que les utilisateurs continuent d’interagir avec le logiciel alors dans ce cas cela peut être intéressant d'en utiliser un pour ce calcul.

[tchize_]

Le thread seront intéressant pour paralleliser des opérations sur les collections, par exemple. Faire des projections et des calculs d'agrégation. Mais simplement paralleliser des tests de base ne sert à rien. L'initialisation et la mise en route du thread nécessitera a elle meme plus de temps que la vérification de l'ensemble du formulaire.

[adiGuba]

Salut,

Le thread seront intéressant pour paralleliser des opérations sur les collections, par exemple. Faire des projections et des calculs d'agrégation. Mais simplement paralleliser des tests de base ne sert à rien. L'initialisation et la mise en route du thread nécessitera a elle meme plus de temps que la vérification de l'ensemble du formulaire.

+1

Et surtout cela complexifie beaucoup de chose et augmente donc le risque d'erreur...


a++

[hwoarang]

Sans compter que si un jour le programme est maintenu par quelqu'un d'autre, ce sera compliqué à comprendre. Et meme peut etre par toi apres 1 ou 2 mois à ne plus utiliser...

[Battant]

Bonjour,

Il y a quelque chose que je ne comprends pas. Pourquoi avoir augmenter le nombre de processeurs alors que ça ne sert à rien de les utiliser. J'ai segmenté en thread la préparations de mes fenêtres. J'en tire deux avantage

S'il y a une exception dans un thread, les autre peuvent continuer ce qui fait que la fenêtre peut tout de même s'afficher.
2. Je suis certain d'utiliser tous les coeurs.

Mon problème c'est que j'ai et mal à évaluer le temps que demande une opération. En fait, il faudrait avoir un chronomètre pour savoir si le fait de créer des thread consomme prends plus de temps que de ne pas utiliser de thread.
Si c'est le cas, comment faire ?
Qu'en pensez-vous ?
Je suis débutant en matière d'optimisation. Je ne sais pas si utiliser systématiquement tous les coeurs via les thread est une bonne solutions pour optimiser les programme car, je le rappelle, je souhaite faire un programme le plus optimal possible.

Merci

Salutations

[Elendhil]

Il y a quelque chose que je ne comprends pas. Pourquoi avoir augmenter le nombre de processeurs alors que ça ne sert à rien de les utiliser.

Tout simplement qu'en général sur un ordinateur il n 'y a pas qu'un seul programme qui fonctionne mais une multitude !

Sinon quand tu utilises l'api Swing , il y a déjà plusieurs threads qui s'occupent de l'affichage , tu n'as donc pas besoin d'en ajouter inutilement.

Comme tout le monde te la dis , la programmation concurrente entraîne une complexité TRÈS importante dans la réalisation de ton programme. Donc on essaie d'utiliser cette façon de programmer si elle apporte un réel avantage , si l'interface de ton application ressemble a quelque chose de classique , il est inutile d'utiliser cette façon de programmer.

[tchize_]

ce n'est pas comme ça qu'on optimise un programme. Pour optimiser, on le fait plus ou moins correctement puis on le passe dans des profiler pour déterminer les "points chauds" et seulement une fois ces points déterminer, on cherche un stratégie d'optimisation.

"S'il y a une exception dans un thread, les autre peuvent continuer " -> avec des informations parcelaires ou un système bancal, ca va "mal" continuer. Si ce que fait thread 1 n'est pas important pour la suite ou pas catastrophique en cas d'erreur: ca peut aussi se gérer dans un thread unique.

Comme on l'a dit, pour tirer avantage des thread, il faut que chacun aie beaucoup de chose à faire. Démarrer un thread c'est
1) instancier un objet
2) verrouiller des données
3) risquer un changement de contexte (rien ne garnatit que ton deuxième thread tournera sur un coeur séparé), opération qui est couteuse car elle nécessite de sauver au niveau du noyau tout l'état du processeur.


Ensuite, tout ce qui concerne les fenetres et l'écran doit exclusivement se faire dans le thread de l'EDT, pas ailleurs en swing.

[hwoarang]

2. Je suis certain d'utiliser tous les coeurs.

Il me semble que tu fais une (grosse) confusion quand tu penses que creer un thread => utilisation d'un autre coeur. Ce n'est pas sur du tout. Le choix du coeur qui va etre utilisé n'appartient qu'à l'OS. S'il n'utilise qu'un coeur (parce qu'il tourne en mode batterie ou pour n'importe quelle raison), c'est son choix. S'il estime qu'il peut utiliser 2 coeurs, il le fait. Dans tous les cas, c'est pas toi qui decide.

De plus, il faut bien comprendre que si tes threads tournaient effectivement sur 2 coeurs différents, ils seraient obligés de passer par de la memoire partagée, plus lente à acceder.

S'il y a une exception dans un thread, les autre peuvent continuer ce qui fait que la fenêtre peut tout de même s'afficher.

Rien ne t'interdit de mettre plusieurs blocs try catch dans un meme thread... Et une exception autorisée ne devrait pas arreter le thread mais simplement etre recupérée dans un bloc try catch.

Et une fois encore, dans un milieu professionnel, ce n'est pas l'optimisation parfaite qui prime mais plutot la lisibilité. Mieux vaut un code comprehensible qui s'execute en 10ms plutot qu'un code incompréhensible qui s'execute en 8ms... Bien sur, dans certains cas critiques, on va essayer d'optimiser par exemple un bout de code appelé souvent et trop long. Mais dans le cas de la lecture d'un formulaire, si on commence deja avec un code qu'il faut 3 jours avant de comprendre... Sans parler de la complexité pour débugger...

[Battant]

Bonjour,

Utiliser du multi thead que pour de grosse opération d'accord cela veut dire que ma stratégie qui consistait à dire que chaque opération indépendante l'une de l'autre n'est pasy la bonne. En fait plutôt que d'utiliser par exemple 4 thread pour faire 4 petites opérations différentes, il vaut mieux en faire 2 grosses. Par exemple, il ne faudrait pas utiliser 2 thread pour ajouter des actionListener ou ne changer qu'une couleur de texte. Par comtre, pour un démarrage très lent où il faut une barre de progression, là il faut des threads,

Faut-il grouper les thread pour améliorer les performances et avoir des chances d'utiliser toutes la puissance de la machine et que le programme soit rapide ?

Mon ancienne philosophie consistait à mettre des méthode pour chaque opérations plutôt que des classe qui gère des thread. Est-ce une meilleures idée ?

Par contre, dans un ancien programme fait avec la philosophie des méthode, il arrive que, pour préparer l’impression cela soit très lent et le bouton reste enfoncé pendant environs 5 seconde. Faudrait-il dans ce cas, segmenter l'opération en plusieurs threads et mettre une barre de progression comme au démarrage de certain programmes ?

Salutations

[tchize_]

la barre de progression est toujours utile pour faire patienter l'utilisateur.

La parallélisation ne pourra se faire que si l'algorithme en question est parallélisable

[Elendhil]

Arrête les Threads !

Oubli ça de ton esprit pour le moment. Programme normalement en POO.

Maintenant sur ta fonction préparation de l'impression que tu appels en cliquant sur un bouton avant d'utiliser un thread pour exécuter cette fonction.

Tu vas regarder attentivement pourquoi elle met 5 secondes à s’exécuter , es ce normal ? y a t-il un bug ? es que je peux simplifier l'algo ? faire un profiling ect ...

Ensuite si effectivement c'est un comportement au quel on ne peut échapper alors oui dans ce cas la tu utiliseras un thread et un seul pas 2 ni 36 , ce serait inutile.

Et comme disait Tchize, tu ne peux pas interagir avec ton interface depuis un autre thread que le thread principal Event Dispatch Thread. Donc il faudra que tu lises cette article de romain guy :

http://gfx.developpez.com/tutoriel/j...ing-threading/

[Battant]

Bonjour,

Vous avez raison. J'ai sans doute meilleur temps de m'intéressé au profiling et pas forcément au thread. Maintenant, j'ai téléchargé un profiler pour éclipse et l'ai installé. Je vais voir comment l'utiliser mais d'une manière générale, quel est son principe de fonctionnement ?

Merci pour votre réponse

Salutations

[tchize_]

on le lance et il détermine, au choix, les zones les plus consommatrice en temps, les zones les plus consommatrice en mémoire, etc.