Multi-thread n'utilise que partiellement les ressources CPU MultiCore

Bonjour,

Après des tas d'essais, il semblerait que la gestion de tableaux ou de listes de grandes tailles ne permet pas d'utiliser la totalité des ressources CPU du PC.
Pas de problème pour d'autres opérations de calcul.

On arrive à contourner ce problème en gérant des Tableaux de Tableaux ou des listes de listes (par exemple au lieu de gérer une liste de 1 million d'éléments, on traite 1000 listes de 1000 éléments).

Auriez-vous une idée de la raison pour laquelle il y aurait un effet de "lock" inter-process lorsqu'on gère des grandes listes ?

Finalement, la gestion des listes ou des tableaux n'est pas en cause. La division en tableaux de tableaux ne résoud rien.

Le problème vient de l'allocation mémoire, dès lors qu'on conserve des quantité importantes d'objets, queque soit la façon dont on les organise.

Donc, pas de solution, sinon à faire en sorte de limiter la quantité d'objets simultanément alloués dans les threads (dans chaque thread ou dans l'ensemble des threads ?).

Dans les tests, j'alloue en parrallèle quelques centaines de milliers d'objets par thread, chaque objet comportant une trentaine de variables (string, int ou char). Je précise que je ne sature pas la mémoire.

Quelle version du framework ?

Citation:

---

Quelle version du framework ?

---

Framework 3.5 !

Qu'est-ce que tu entends par "ne permet d'utiliser la totalité des ressources" ? Et comment tu t'en aperçois en regardant dans le gestionnaire des tâches ? Et pourquoi cela devrait utiliser 100% de CPU ? Puisque tu parles de quantité d'objet alloué c'est plus la ressource mémoire que CPU qui doit être évalué non ?

Puis c'est un multicore pas un multiprocesseur si je comprends bien donc...

Citation:

---

Envoyé par hegros

Qu'est-ce que tu entends par "ne permet d'utiliser la totalité des ressources" ? ?...

---

Je le constate effectiverment en regardant dans le gestionnaire des tâches.

Citation:

---

Et pourquoi cela devrait utiliser 100% de CPU ?

---

Si je rajoute une boucle pour traiter n fois chaque objet (au lieu de le traiter une fois) l'utilisation des ressources CPU tend vers 100%.

Citation:

---

Puisque tu parles de quantité d'objet alloué c'est plus la ressource mémoire que CPU qui doit être évalué non ?

---

Je n'ai aucun problème de saturation des ressources mémoires (toujours -de 50% de mémoire utilisée). C'est "seulement" le taux d'utilisation du CPU qui ne tend pas vers 100% en raison apparament du nombre d'objets alloués et non libérés durant le traitement opéré par chaque thread.

Citation:

---

Puis c'est un multicore pas un multiprocesseur si je comprends bien donc

---

Oui, je fais les tests de performance sur un MultiCore.

Citation:

---

Envoyé par boulo

Si je rajoute une boucle pour traiter n fois chaque objet (au lieu de le traiter une fois) l'utilisation des ressources CPU tend vers 100%.

---

Comme pour une boucle for qui ne fait qu'incrémenter une variable.

Citation:

---

Envoyé par boulo

C'est "seulement" le taux d'utilisation du CPU qui ne tend pas vers 100% en raison apparament du nombre d'objets alloués et non libérés durant le traitement opéré par chaque thread.

---

Je ne comprends pas pourquoi cela devrait tendre vers 100%. Cela tends vers 100% lorsque tu as un problème dans le code ou le design. De plus l'allocation d'objet n'influence pas plus que cela le CPU c'est plutôt la mémoire qui est influencée.

Citation:

---

Envoyé par boulo

Oui, je fais les tests de performance sur un MultiCore.

---

Donc c'est 1 thread à la fois qui travaille et qui prends la ressource CPU pas les 1000 ou 10000 thread à la fois.

Je n'arrive pas à comprendre pourquoi allouer beaucoup d'objet devrait influencer le CPU ? Et pourquoi des centaines de milliers devrait faire travailler le CPU à 100%. D'ailleurs un CPU ce n'est pas fait pour tourner à 100% cela indique effectivement que tu utilises toute la puissance mais en général cela ne se fait pas (mise à part problème dans le code)

Citation:

---

Je n'arrive pas à comprendre pourquoi allouer beaucoup d'objet devrait influencer le CPU ?

---

Moi non plus : c'est bien à ce sujet que je voudrais avoir une explication.

Citation:

---

D'ailleurs un CPU ce n'est pas fait pour tourner à 100% cela indique effectivement que tu utilises toute la puissance mais en général cela ne se fait pas (mise à part problème dans le code)

---

C'est pourtant courant dans les traitement scientifiques : je lance parfois des traitement entiérement en mémoire qui tournent tout le week-end.

Citation:

---

Envoyé par boulo

Moi non plus : c'est bien à ce sujet que je voudrais avoir une explication.

---

Manifestement ce n'est pas ton cas puisque tu n'utilises pas 100% des ressources

Citation:

---

Envoyé par boulo

C'est pourtant courant dans les traitement scientifiques : je lance parfois des traitement entiérement en mémoire qui tournent tout le week-end.

---

Et qui passe tout le week-end à consommer 100% de CPU ?

En fait c'est assez partagé, plus tu utilises le CPU (tends vers 100%)plus tu exploites au maximum les capacités de ce dernier et tu es censé faire plus de calcul ce qui est quand même un but recherché. Mais en général utiliser 100% de CPU c'est plutôt vu comme un problème de design. C'est discutable.

Citation:

---

Donc c'est 1 thread à la fois qui travaille et qui prends la ressource CPU pas les 1000 ou 10000 thread à la fois.

---

Si seul 1 thread à la fois travaille sur un dual core, on ne pourrait pas dépaser 50% d'utilisation CPU.
J'approche 100% grace à l'utilisation de plusieurs thread en parallèle à condition de ne pas conserver beaucoup d'objets alloués dans chaque thread.
Sinon (beaucoup d'objets conservés avant d'être traités et libérés), je n'utilise que 65% CPU.

Citation:

---

Mais en général utiliser 100% de CPU c'est plutôt vu comme un problème de design.

---

Vrai, pour des programmes de gestion.
Faux, pour de la simulation de comportement de systèmes physiques (météo par exemple ou calculs de déformations).

Citation:

---

Envoyé par boulo

Si seul 1 thread à la fois travaille sur un dual core, on ne pourrait pas dépaser 50% d'utilisation CPU.

---

D'où tu sors cela ? Je t'ai donné un exemple avec 1 thread qui fait une simple boucle pour incrémenter une variable est qui atteint 100% de CPU.

Je ne comprends pas ton affirmation

Citation:

---

Envoyé par boulo

J'approche 100% grace à l'utilisation de plusieurs thread en parallèle à condition de ne pas conserver beaucoup d'objets alloués dans chaque thread.
Sinon (beaucoup d'objets conservés avant d'être traités et libérés), je n'utilise que 65% CPU.

---

A mon avis tu montes à 100% quand tu ne conserves pas beaucoup d'objets parce que le système passe du temps à faire du swapping.

Quand tu ne libères pas les objets (et que la mémoire est suffisante ce que tu as l'air de confirmer) le système ne swappe pas. Hors swapper consomme de la ressource CPU.

D'ailleurs lorsqu'un système passe son temps à swapper il consomme toute la ressource. Une solution est d'augmenter la taille du swap. A combien est-elle aujourd'hui ?

Citation:

---

Envoyé par boulo

Vrai, pour des programmes de gestion.
Faux, pour de la simulation de comportement de systèmes physiques (météo par exemple ou calculs de déformations).

---

Ce n'est pas seulement vrai pour les programmes de gestion.

J'ai passé 5 années(c'est pas forcément beaucoup mais je continue) dans la simulation de système physique notamment en thermodynamique (certes c'est différent de la météo ou du calculs de déformation mais il y a une grosse partie graphique pour manger de la ressource en plus)

Bien que la ressource CPU était assez utilisée elle n'atteignait jamais la limite de 100% sauf problème de design et d'optimisation puisque l'on arrivé toujours à faire redescendre la consommation à des valeurs raisonnables et garder du mou (entre 30 et 70% pour le pire)

100% c'est la limite extrême, cela veut dire que ton algo et design devraient avoir besoin de plus d'un processeur mais tu ne peux pas le savoir puisque tu as atteint la limite :)

je devrai peut être refaire un test avant d'affirmer ce que qui va suivre mais.

un programme a beau lancer 1 ou 100 theads, il utilisera toujours un seul CPU.

pour utiliser le multicoeur il faut lancer plusieurs process et non plusieurs threads.

c'est ce qu'on m'a appri et que j'avais constaté en .net 2.0

Citation:

---

Envoyé par mickyoun

je devrai peut être refaire un test avant d'affirmer ce que qui va suivre mais.

un programme a beau lancer 1 ou 100 theads, il utilisera toujours un seul CPU.

pour utiliser le multicoeur il faut lancer plusieurs process et non plusieurs threads.

c'est ce qu'on m'a appri et que j'avais constaté en .net 2.0

---

La gestion du multithreading à beaucoup évolué depuis le 2.0.
Plusieurs threads conviennent parfaitement pour utiliser tous les cores.
Si tu veut profiter un maximum des processeurs multicoeurs je te conseille de t'orienter vers le framework 4.0
Par exemple:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

static void Main(string[] args) { //Task.Factory.StartNew(go); //Task.Factory.StartNew(go); //Task.Factory.StartNew(go); //Task.Factory.StartNew(go); Parallel.Invoke(go, go, go, go); Console.Read(); }   static void go() { int i = 0; while (true) { i++; Console.WriteLine(i); } }

---

Tu peut utiliser Task.Factory.StartNew() qui utilise un Pool de threads ( les threads sont réutilisés, c'est pratique si tu en lance beaucoup, qui dure peu de temps et souvent )

Si tu ne lance que peu de fois, Parallel.Invoke() est plus intéressant, tu lui donne un tableau de delegates en parametre et le framework s'occupe du reste.

Je te conseille de jeter un oeil içi : http://www.albahari.com/threading
Et plus particulièrement sur cette page
http://www.albahari.com/threading/part5.aspx

Un process ce n'est rien d'autre qu'un espace d'adressage mémoire pour y mettre l'exécutable, charger des bibliothèques etc... C'est une entité statique.

Un thread c'est une entité dynamique c'est elle qui prends et consomme la ressource CPU.

Bref, tout cela pour dire que c'est les threads qui sont dans les starting block et c'est eux qui sont parallélisables et non pas les processus.

Citation:

---

Envoyé par boulo

Bonjour,

Après des tas d'essais, il semblerait que la gestion de tableaux ou de listes de grandes tailles ne permet pas d'utiliser la totalité des ressources CPU du PC.
Pas de problème pour d'autres opérations de calcul.

On arrive à contourner ce problème en gérant des Tableaux de Tableaux ou des listes de listes (par exemple au lieu de gérer une liste de 1 million d'éléments, on traite 1000 listes de 1000 éléments).

Auriez-vous une idée de la raison pour laquelle il y aurait un effet de "lock" inter-process lorsqu'on gère des grandes listes ?

...

Finalement, la gestion des listes ou des tableaux n'est pas en cause. La division en tableaux de tableaux ne résoud rien.

---

Juste une idée comme cela. Gérer des grandes tailles de données peut vouloir dire que la plupart des données sont en mémoire vive (voir sur le disque dur...). Il n'y a pas assez de place en mémoire processeur pour les contenir toutes. Pour effectuer les traitements, le processeur doit swapper les données entre la mémoire vive et la mémoire proc. D'où interruption (si données sur disque dur -> interruption disque + interruption mémoire) et donc délai d'attente. Comme le processeur attends, il en fait moins, d'où impossibilité de monter en charge (100%).

Une idée à débattre, je ne suis pas spécialiste des processeurs , de la mémoire vive et du fonctionnement des OS.

PS : Connaître la taille de vos données. Connaître la taille des caches processeurs, mémoire vives, gestion mémoire framework .net, gestion mémoire de l'OS. Bref beaucoup de variables, si le problème vient de la taille des données.

PS2 : ma réponse part du principe que vous gérez de grande quantité de données et qui prennent beaucoup d'espace mémoire.

Citation:

---

Pour effectuer les traitements, le processeur doit swapper les données entre la mémoire vive et la mémoire proc.

---

Bien vu moldavi :ccool:
Il est bien possible que les swaps entre cache processeur et RAM, qui utiliseraient du DMA (donc en parallèle avec les core), soient la raison d'une utilisation des cores inférieure à 100%.
A confirmer ...

Tu vas avoir du mal à confirmer cette théorie en pratique...

Bonjour.

En partant de ce postulat et pour confirmer ceci, voici ce que je ferais (en gros avec les moyens du bord, sans spécialiste à portée de main...) :

J'essaierai de prendre deux processeurs complètement identiques, sauf une différence. L'un a plus de mémoire cache que l'autre. et hop, test.

Ceci dit, je pense que le problème est certainement plus complexe (beaucoup de variables interviennent = proc/mémoire/framework/OS).

Citation:

---

Envoyé par mickyoun

je devrai peut être refaire un test avant d'affirmer ce que qui va suivre mais.

un programme a beau lancer 1 ou 100 theads, il utilisera toujours un seul CPU.

pour utiliser le multicoeur il faut lancer plusieurs process et non plusieurs threads.

c'est ce qu'on m'a appri et que j'avais constaté en .net 2.0

---

oui c'est exact mais peut-être que pour optimiser les choses il faut passer par des API natives win32.
Il y a des API qui permettent de faire tourner un thread sur un processeur donné.
Ou bien peut-être que le dernier Framework .NET ( 4.0 je crois ) permette cela ,que l'on me corrige au besoin

http://msdn.microsoft.com/en-us/library/dd460693.aspx

Bonjour.

C'est l'éternel dilemme. Tu changes l'éléctronique (double/quadri processeurs), mais tu dois rester compatible avec les couches logicielles au-dessus...

Citation:

---

un programme a beau lancer 1 ou 100 theads, il utilisera toujours un seul CPU.
pour utiliser le multicoeur il faut lancer plusieurs process et non plusieurs threads.

---

En framework 3.5, nos essais sur un dual core montrent que l'on arrive à plus de 50% des ressources CPU (60% a 90% suivant les actions effectuées dans les threads), ce qui implique qu'un process avec plusieurs threads utilise les 2 cores.

Citation:

---

Envoyé par Mat.M

oui c'est exact mais peut-être que pour optimiser les choses il faut passer par des API natives win32.

---

Beh non ce n'est pas exact. Ce ne sont pas les processus qui sont parallélisables ce sont les threads qui le sont.

Citation:

---

Envoyé par boulo

En framework 3.5, nos essais sur un dual core montrent que l'on arrive à plus de 50% des ressources CPU (60% a 90% suivant les actions effectuées dans les threads), ce qui implique qu'un process avec plusieurs threads utilise les 2 cores.

---

Je fais un test là en .net 3.5 je reviens vers vous

Je viens de faire un test en mode console avec le framework 2 et 3.5
Le résultat est le même et contraire à mon idée, les deux core bosse à 100%.

Je serai curieux de voir ce que ça donne en C++.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46

using System; using System.Collections.Generic; using System.Text; using System.Threading;   namespace MultiThreadCons { class Program { static bool Actif = true; static void Main(string[] args) {   ThreadStart ts = new ThreadStart(Program.thread); Thread t = new Thread(ts); t.Start();   ts = new ThreadStart(Program.thread); t = new Thread(ts); t.Start();   ts = new ThreadStart(Program.thread); t = new Thread(ts); t.Start();   ts = new ThreadStart(Program.thread); t = new Thread(ts); t.Start();   ts = new ThreadStart(Program.thread); t = new Thread(ts); t.Start();   while(Console.ReadLine() != "exit");   Actif = false; }   static void thread() { while (Actif) ; }   } }

---

Dès l'instant ou il y'a plusieurs threads, le système peut décider de les répartir sur les cores à sont goût, ce qui n'est pas possible avec un seul thread évidemment. C'est pour ça que le développement d'une application multithreaded c'est d'abord une façon de coder.
Après la PFX et la TPL sont là pour permettre de mieux paralléliser et organiser tout ça, d'éviter que le système en fasse un peu à sa tête, et donc d'accroître les perfs.

la PFX et la TPL n'oblige pas le système à ne pas en faire à sa tête...

l'ordonnanceur des tâches du noyau système reste le maître absolu et en fera toujours à sa tête et pas à la tienne... les deux seules options possibles pour influer sur son comportement vis à vis de tes threads et de changer leur priorité et éventuellement leur affinité à un coeur/processeur.

effectivement dire que les threads ne sont pas gérés convenablement, est un peu abusé... aucun test réellement efficace ne permet de le déterminer, bien au contraire, des tests bien sentis auront plutot tendance à démontrer le contraire.

hors si dans dotnet 3.5 on arrive à démontrer qu'en développant en multithread on arrive à saturé tous les coeurs du processeur, il est indéniable que cet état de fait est également vrai pour dotnet 2, car entre dotnet 2 et dotnet 3.5SP1, il n'y a eu absolument aucune modification apportée à la CLR...
de toute façon la CLR recompile tout en natif, et une bonne partie des rouages que l'on prend pour acquis sont convertis en appels win32 implicites... par conséquent il aurait été assez ubuesque que les threads ne soient pas convenablement gérés.

Si l'expérience a été faite sur XP.. elle ne vaut rien, XP aillant une fâcheuse tendance à gérer les 2 cœurs (et pas 4 contrairement aux apparences... limitation d'XP oblige) n'importe comment.

quand à la division processus/thread pour la gestion de l'ordonnancement, dire que l'unité d'ordonnancement est le process et non le thread revient à se référer à quelque chose qui n'a été vrai que dans les toutes premières version de windows NT et jusque windows 95 pour le tout publique.

Croire que windows fait comme linux, (et encore linux en kernel antérieur au 2.6), est une idiotie sans nom, vu que rien que le modèle mémoire était, et est d'ailleurs toujours radicalement différent. Effectivement avant le kernel 2.6 et même encore après d'ailleurs, linux n'a jamais géré les threads... la lib pthread était une rustine, une surcouche, visant à faire croire au système que les threads étaient des processus.
L'unité atomique est bien le thread sous windows et donc dotnet, et sous de nombreux systèmes d'exploitations.

Donc effectivement, tu va te dire, oui mais il ordonne des processus, oui, quand les processus n'ont que le main thread à ordonnancer... et c'est encore assez souvent le cas dans les applications écrites en code natif.
En effet, dès lors que l'on travail en dotnet il est impossible de programmer en monothread... rien que dotnet travail lui même en multithread et utilise la threadpool, ce n'est pas pour rien qu'elle a été inventé.
toutes les tâches asynchrones se font en arrière plan dans des threads de la pool.
De plus à l'inverse d'une application standard winforms basique, où 1 main thread est utilisé pour pomper la file des messages, il faut savoir que tout applicatif en WPF utilise au minimum 2 threads.

Je doute que microsoft ait pris soin de multithreadé la plateforme, si la plateforme faisait un peu comme linux et gérait les threads elle même à la vas y que je te pousse... je sais que parfois ils ont des façons de faire étrange, mais tout de même... pas à ce point.

Citation:

---

Envoyé par mickyoun

Je serai curieux de voir ce que ça donne en C++.

---

Cela ne va rien changer. Que se soit en C# ou en C++ ou autre chose c'est toujours le noyau du système d'exploitation qui ordonnance les threads selon son algorithme. Donc à partir du moment où ton thread ou ton processus à consommer son quantum de temps il est endormi et un autre devient éligible.

Il n'y a de vrai parallélisation qu'avec des machines qui possèdent plusieurs processeurs. Avec un seul processeur dual ou quatri coeur la parallélisation n'est qu'un artifice. En .NET 4 ce qu'il y a en plus(en gros) c'est une meilleure distribution des threads sur les processeurs (lorsqu'il y en a plusieurs biensûr..)

Pour revenir sur le problème, tu n'utilises peut-être pas 100% du CPU parce que ton programme n'a pas besoin de toute la puissance de ton processeur. Tu atteins par contre 100% (lorsque tu libères les objets) parce que justement la libération des objets consomme de la CPU en plus. Donc bravo tu as optimisé ton algorithme, l'objectif n'est pas d'utiliser 100% du CPU mais d'effectuer ses calculs et traitements dans les temps voulus.