THREADS
Résolu
Java2386
Messages postés
27
Date d'inscription
lundi 17 septembre 2007
Statut
Membre
Dernière intervention
10 avril 2009
-
25 nov. 2007 à 19:13
cs_AlexN Messages postés 694 Date d'inscription lundi 5 décembre 2005 Statut Membre Dernière intervention 8 janvier 2014 - 25 nov. 2007 à 21:55
cs_AlexN Messages postés 694 Date d'inscription lundi 5 décembre 2005 Statut Membre Dernière intervention 8 janvier 2014 - 25 nov. 2007 à 21:55
2 réponses
cs_DARKSIDIOUS
Messages postés
15814
Date d'inscription
jeudi 8 août 2002
Statut
Membre
Dernière intervention
4 mars 2013
130
25 nov. 2007 à 20:04
25 nov. 2007 à 20:04
Salut,
Les threads ne sont pas des outils, ce sont des techniques de parallèlisation.
Avec les processeurs actuels, on voit de plus en plus l'intérêt d'utiliser des threads dans nos programmes : cela permet de parallèliser les calculs (d'exécuter plusieurs calculs en même temps). Exemple : un thread qui raffraîchit l'interface graphique pendant qu'un autre s'occupe de définir les nouvelles coordonnées d'un élément graphique.
Les processeurs actuels permettent maintenant de faire 2 voir 4 calculs en parallèle (selon le nombre de coeur du CPU), donc au lieu de faire un calcul après l'autre, l'intérêt et de lui demander d'en faire 2 ou 4 en même temps. En théorie, ton application tourne 2 à 4 fois plus vite... en théorie !
Par contre, la programmation parallèle demande de revoir l'architecture globale de son application pour une optimisation maximale : on ne peux pas tout parallèliser, et dans une application multi-thread, c'est bien souvent les bouts de code non parallèlisables qui prennent le plus de temps à s'exécuter, et c'est ce qui bride le coefficient multiplicateur de la programmation multi-thread !
Disons qu'en utilisant des threads sur une machine double-coeur, tu peux espérer accèlérer d'un facteur 1.5 en moyenne.
______________________________________
DarK Sidious
Les threads ne sont pas des outils, ce sont des techniques de parallèlisation.
Avec les processeurs actuels, on voit de plus en plus l'intérêt d'utiliser des threads dans nos programmes : cela permet de parallèliser les calculs (d'exécuter plusieurs calculs en même temps). Exemple : un thread qui raffraîchit l'interface graphique pendant qu'un autre s'occupe de définir les nouvelles coordonnées d'un élément graphique.
Les processeurs actuels permettent maintenant de faire 2 voir 4 calculs en parallèle (selon le nombre de coeur du CPU), donc au lieu de faire un calcul après l'autre, l'intérêt et de lui demander d'en faire 2 ou 4 en même temps. En théorie, ton application tourne 2 à 4 fois plus vite... en théorie !
Par contre, la programmation parallèle demande de revoir l'architecture globale de son application pour une optimisation maximale : on ne peux pas tout parallèliser, et dans une application multi-thread, c'est bien souvent les bouts de code non parallèlisables qui prennent le plus de temps à s'exécuter, et c'est ce qui bride le coefficient multiplicateur de la programmation multi-thread !
Disons qu'en utilisant des threads sur une machine double-coeur, tu peux espérer accèlérer d'un facteur 1.5 en moyenne.
______________________________________
DarK Sidious
cs_AlexN
Messages postés
694
Date d'inscription
lundi 5 décembre 2005
Statut
Membre
Dernière intervention
8 janvier 2014
19
25 nov. 2007 à 21:55
25 nov. 2007 à 21:55
Cette technique n'est pas utile pour certaines applications. Mais elle est VITALE pour d'autres.
Pour exemple, un projet sur lequel je travaille, dans une équipe, est le dévelopement d'un moteur de comparaison. Chaque requête d'un internaute est divisée en sous requêtes envoyées sur une moyenne de 15 sites / services web différents. Chaque sous requête peut mettre de 1 minute à répondre. Si le moteur tournait en environnement monothread, il faudrait faire les sous requêtes les unes après les autres. Un rapide calcul :
1 requête complète 15 sous requêtes x 1 minute 15 minutes.
Une seule requête utilisateur pourrait mettre plus de 15 minutes à répondre. En fait ce moteur fonctionne en environnement multithreads, chaque sous requête étant traitée dans un thread indépendant. Le tout controlé par un thread principal qui bride chaque thread de sous requête à 1 minute. Au final, une requête complète met au maximum 1 minute à répondre au lieu de 15.
Et si je rajoute la charge des machines : environ 4000 requêtes / heure. Si chaque serveur était monothreadé (une seule sous requête a la fois), et qu'une requête complète met 15 minutes, ca fait 4 requêtes de l'heure. Ca veut dire qu'il faudrait 1000 serveurs pour supporter cette charge.
Pour exemple, un projet sur lequel je travaille, dans une équipe, est le dévelopement d'un moteur de comparaison. Chaque requête d'un internaute est divisée en sous requêtes envoyées sur une moyenne de 15 sites / services web différents. Chaque sous requête peut mettre de 1 minute à répondre. Si le moteur tournait en environnement monothread, il faudrait faire les sous requêtes les unes après les autres. Un rapide calcul :
1 requête complète 15 sous requêtes x 1 minute 15 minutes.
Une seule requête utilisateur pourrait mettre plus de 15 minutes à répondre. En fait ce moteur fonctionne en environnement multithreads, chaque sous requête étant traitée dans un thread indépendant. Le tout controlé par un thread principal qui bride chaque thread de sous requête à 1 minute. Au final, une requête complète met au maximum 1 minute à répondre au lieu de 15.
Et si je rajoute la charge des machines : environ 4000 requêtes / heure. Si chaque serveur était monothreadé (une seule sous requête a la fois), et qu'une requête complète met 15 minutes, ca fait 4 requêtes de l'heure. Ca veut dire qu'il faudrait 1000 serveurs pour supporter cette charge.