Version imprimable
Bonjour, j'ai beaucoup de threadPool que sont en cour exécution.
Ces thread pool sont instanciés au démarrage de l'application donc leurs utilisation n'est pas pénalisé par leurs création.
Par contre au niveau processeur, est ce que le processeur est pénalisé par la gestion multitâches?
Est ce que vous avez une idée?
Merci.
Bonjour.
Je présume que tu veux dire que tu as placé beaucoup d"items dans la file du ThreadPool. Alors, non, ils ne consomment que de la mémoire et n'ont aucune impact sur les performances. Ce qui importe en terme de performances, c'est le nombre réel de threads utilisés et qui est défini par ThreadPool.Get/SetMaxThreads(). L'optimum serait un nombre égal au nombre de coeurs disponibles mais, par défaut, cette valeur est égale à 25 afin de garantir une plus grande souplesse aux consommateurs de la classe(*), au léger détriment des perfs.
La valeur par défaut est acceptable. Si ton scénario le permet toutefois et que tu veux soigner les choses pour le confort de l'utilisateur final, tu peux envisager d'utiliser une valeur égale au nombre de coeurs. Attention, tenter d'assigner une valeur inférieure au nombre de coeurs (ou processeurs ?) lève une exception.
(*) Une appli pourrait utiliser le ThreadPool depuis plusieurs points, certains étant situés dans des biblios dont le développeur final n'aurait pas conscience qu'elles utilisent le ThreadPool. Si ce dév final venait à mettre en fil de très longs traitements, une valeur basse pour MaxThreads empêcherait les traitements mis en file par les biblios de s'exécuter.
Un petit bemol toutefois : il semblerait que les allocations mémoires occasionnent des lock qui ne permettent pas d'utiliser toute la puissance des CPU en multi-core. Sur un bi-core en travaillant en mémoire pure, j'ai jamais pu dépasser 80% de taux d'utilisation CPU dans une applio, quand les thread allouaient de la mémoire pour conserver des résultats détaillés du traitement.Citation:
Alors, non, ils ne consomment que de la mémoire et n'ont aucune impact sur les performances.
Bonjour,
Merci Pour vos repenses bien déaillées
Avant le lancement de mon traitement : J'ai un nombre max de Threads = 50 dont 50 sont disponibles.Citation:
Envoyé par DonQuiche
Donc, mon traitement va consommer les 50 Threads.
Ces 50 threads vont être lancés sur une machine BiProcesseur(simple ou dual core)
et on plus il vont gèrer un lock sur une liste partagé pour y insérer leurs résultats. --> Je dois diminuer le nombre de Threads pour éviter cette attente suite au lock.
Sans les threads je mets 2min/ traitement
Avec les Thrads je mets 1min:38sec/traitement
L'utilisation de 50 threads ne m'a pas permis de gagner même la moitié du temps!!
Citation:
Envoyé par smaouiomar
:yaisse1:Citation:
Envoyé par Mon equipe
Citation:
Envoyé par smaouiomar
ca dépend de plein de choses
en théorie sans lock avec 2 threads sur un bicore on devrait se rapprocher de la moitié du temps
un lock ca fait attendre, voir si tu peux utiliser un readerwriterlock/slim à la place qui permet dans certains cas de gagner des perfs
ensuite il faut voir la charge des threads, si tes threads ne font que travailler, avoir plus de threads que de cores ralenti le traitement *
il y a une propriété static quelque part dans le framework pour connaitre le nombre de core logique, qu'il faut alors définir sur le max du threadpool
les scénarios qui autorisent d'avoir jusqu'à des centaines de threads même sur un monocore sont des cas où les threads ne bossent pas à plein temps (.sleep(x), manualresetevent.wait, autrethrad.join etc...)
* : windows a des centaines de threads à faire tourner, c'est chacun leur tour quelques nanosecondes
pour passer d'un thread à un autre, il vide le cache du core, le rempli avec les données du thread suivant
Si tu veux augmenter les performances:
* Un thread par coeur, sur un bi-coeur, ça veut dire "2". Ici, dans la mesure où on a déjà un thread cerbère et que les threads peuvent passer du temps à attendre le cerbère, le mieux est de tester des valeurs de 1 à 5 threads et voir ce que ça donne.
* Des traitements longs par rapport au temps nécessaire pour passer d'un Workitem à un autre. Cette opération n'est certainement pas gratuite. Au besoin, essaye de regrouper plusieurs opérations en un seul Workitem.
Le ThreadPool n'est pas le coupable. Ce n'est simplement pas une baguette magique, il nécessite d'être compris, comme tout ce qui touche au parallélisme.
@Graffito
Veux-tu dire que la mise en file de nouveaux Workitems a un coût non-négligeable, ou bien que tu as eu un scénario où le passage d'un Workitem à un autre bouffait 20% des perfs (ce qui n'a rien de surprenant si les Workitems sont courts). ?
Je pense que je ne peux pas utliser readerwriterlock/slim car je fait toujours le lock pour ecriture (Pas de lecture) et je suis sur le .Net2.0Citation:
Envoyé par Pol63
Oui j'ai plus de traitement que de lock.Citation:
Envoyé par Pol63
//Traitement ......
//Lock(Loker){maliste.Add(resultat);}
Quand le traitement commance, l'utilisation de CPU passe de 1% à 100%!!
Il existe aussi des structures concurrentes lock-free comme ConcurrentBag<T>.
En fait, ce qui semble empêcher l'utilisation de tout le CPU disponible est un "engorgement" au niveau des allocations mémoires. Ce phénomène disparait lorsqu'on limite la quantité totale d'objets alloués.Citation:
@Graffito : Veux-tu dire que la mise en file de nouveaux Workitems a un coût non-négligeable, ou bien que tu as eu un scénario où le passage d'un Workitem à un autre bouffait 20% des perfs (ce qui n'a rien de surprenant si les Workitems sont courts). ?
Je n'ai pas réélement évalué les performances, mais simplement constaté que l'utilisation du CPU n'était pas optimale.
Je te remercie, je case ça dans un coin de ma tête, je ferai quelques tests sur ce point la prochaine fois que j'aurai un ThreadPool avec de nombreux éléments.
bonsoir,
Je vous remercie pour vos remarques très intéressantes.
Je vais essayer de tester avec 2 à 4 Threads debut de la semaine prochaine.
Je vous donnerai une petite comparaison des résultats.
Un petit conseil : lors de la simulation éviter de remplacer un calcul par un thread.Sleep :
Avant de commencer le développement des Threads, j'ai essayer de simuler sur un petit projet de test en remplaçant la méthode gourmande en terme de calculs par Tread.Sleep(1000);
La simulation m'a donné un très bon résultat avec un grand nombre de Threads ce qui ne sera pas le cas dans lorsque je lance le vrai calcul.
BonjourCitation:
Envoyé par Graffito
J'ai fait un constat sur l'utilisation du CPU similaire. Mais je ne dirai pas que c'est de la faute des lock, mais des objets de lock système.
En effet sur un traitement paralléliser, avec des lock j'avais constater une utilisation de 76-80% du CPU sur un dual-core sous XP.
Le simple fait de passer sous 7 (bon y'a aussi un quad-core) et le même traitement monte à 96% de charge.
J'aurais donc plutôt tendance a dire que les objet de synchro sous 7 sont meilleur que sous XP
la gestion des threads a aussi bien évolué entre xp vista et 7
vista s'en sort déjà beaucoup mieux
et 7 sait faire la différence entre un core physique et un core logique qui vient d'un hyperthreading
7 évite aussi de déplacer des threads d'un core à un autre sans raison