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]

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