Discussion :

[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 ?

[boulo]

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.

[hegros]

Quelle version du framework ?

[boulo]

Quelle version du framework ?

Framework 3.5 !

[hegros]

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...

[boulo]

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.

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%.

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.

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

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

[hegros]

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.

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.

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)

[boulo]

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.

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.

[hegros]

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

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.

[boulo]

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.

[boulo]

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).

[hegros]

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

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 ?

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

[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

[Jerede]

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 :

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

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

[hegros]

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.

[moldavi]

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.

[boulo]

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

Bien vu moldavi
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 ...

[hegros]

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

[moldavi]

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).

[Mat.M]

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