Discussion :

[DSGSLA]

Bonjour à tous,

La question que je vous soumets est valable pour les systèmes *Unix, Linux, MacOS et Windows. Elle est très générale

Y-a-t-il une différence de performance entre un processus et un thread ? Quelles sont les contraintes pour les meilleures performances ?

Je dois faire une application parallélisée où la performance est critique. De plus les threads/processus doivent communiquer en permanence de grandes quantités de données.

Question subsidiaire, peut-on connaître la consommation CPU d'un thread ?

[ram-0000]

A mon avis, un thread est plus performant qu'un processus.

D'abord, c'est une structure plus light pour le noyau, le temps de création et d'instanciation doit être rapide. Ceci n'a peut être pas trop d'importance si les thread ou les process sont créés au début.

Ensuite, le temps de swap d'un thread à l'autre doit être plus rapide que entre 2 process car justement comme l'espace mémoire est partagé, il n'y a pas besoin de le changer.

Tu peux echanger des donnés entre thread avec des mécanismes plus simple inter thread comme les section critiques qui n'existent pas en inter process.

Le problème d'un thread, c'est que si l'un d'eux par en cacahuètes et corromp la mémoire, il risque d'impacter les autres.

[moldavi]

Bonjour.

Y-a-t-il une différence de performance entre un processus et un thread ?

La question n'a pas vraiment lieu d'être car le processus est simplement l'unité qui représente l'ensemble des threads du programme (plus d'autres informations).

Donc la comparaison des performances entre processus/threads est contradictoire, puisque les threads du programme sont une composante du processus. Les performances du processus sont le reflet des performances des threads sous-jacents.

[Steph_ng8]

Je pense que la question (par rapport aux performances) était du genre :
« Si on a X tâches à effectuer en parallèle, quelle différence de performances y aura-t-il entre utiliser X threads et utiliser X processus ? »

[moldavi]

Certainement.

Et ram-0000 a très bien répondu à cette question.

J'ai pris la question de DSGSLA sur les performances processus/threads Brut de Brut.

[DSGSLA]

Je pense que la question (par rapport aux performances) était du genre :
« Si on a X tâches à effectuer en parallèle, quelle différence de performances y aura-t-il entre utiliser X threads et utiliser X processus ? »

Effectivement c'est à ça que je pensais.
Merci pour vos réponse.

Cependant peut-on évaluer la consommation CPU d'un thread, ou son ratio par rapport au processus père ? J'ai besoin d'évaluer les goulets d'étranglement dans le flux.

[moldavi]

Sous windows seven tu as le moniteur de ressouces, mais au mieux tu peux voir la gestion sur chaque processeur.

Je pense, mais sans en être certain, qu'il y a une API dans le dernier windows SDK pour gérer cela. Sinon il existe des outils : http://msdn.microsoft.com/en-us/libr...=VS.60%29.aspx

Pour les autres OS, je ne sais pas.

Sinon le cas classique, c'est de mesurer les performances à l'intérieur des threads dans le code.

[DSGSLA]

Sinon le cas classique, c'est de mesurer les performances à l'intérieur des threads dans le code.

Je ne vois pas comment on fait cela.

Une autre question m'est venue à l'esprit sur le sujet : sur un machine multiprocesseur/multicœur les différents threads d'un même processus s'exécutent-ils sur le même cœur que le processus père ou l'OS les répartit sur les cœurs selon les ressources disponibles ? Cela altère-t-il les communications inter-thread ?

[moldavi]

Bonjour.

Votre question à l'origine est très délicate, parce qu'elle est très large.

Avez-vous identifié tous les problèmes de performance en question (accès disque, accès mémoire, calcul intensif, réseau, etc...).

Difficile de répondre clairement à une question large.

Une fois les problèmes identifiés, quelles solutions. Pour du calcul intensif par exemple vous avez Cuda, DirectCompute, librairie de tâche parallèles, codes optimisés, langage, compilateur, etc...

Ensuite selon l'OS, comportement différent. Par exemple windows seven c'est 10 ms avant le basculement de contexte, pour windows server 2008 c'est 15 ms.

Ensuite votre optimisation devra-t-elle s'appuyer uniquement sur le hardware, ou une résolution logicielle sera-t-elle nécessaire voir à additionner.

Bref un sujet tellement vaste, qu'il est impossible de dire "il faut faire comme ça et c'est bon".

De plus les technologies concernant le développement parallèle (multi-coeur, Cuda, etc...) sont en phase de pleine évolution.

Bref je ne vous donne que quelques éléments de réflexion, c'est certainement incomplet et ça ne peut pas répondre à une question au sens large.

Je ne vois pas comment on fait cela.

On prend un chronomètre et on mesure le temps d'exécutions des threads, surtout là où on pense que ça va être gourmand.

[DSGSLA]

Je compte réaliser une application multiplateforme, donc je dois prendre en considération les OS majeurs. Ce qui étend la portée du problème évidemment.
Les machines cibles sont multiprocesseurs et multicoeurs. Je ne prends pas en compte pour le moment les GPU. Le langage est le C++. Il n'y a pas d'utilisation de bibliothèques particulières tel que OpenMP, OpenCL et consort. La parallélisation se fait uniquement par l'architecture de l'application.


Je reprends la question

Une autre question m'est venue à l'esprit sur le sujet : sur un machine multiprocesseur/multicœur les différents threads d'un même processus s'exécutent-ils sur le même cœur que le processus père ou l'OS les répartit sur les cœurs selon les ressources disponibles ? Cela altère-t-il les communications inter-thread ?

[Médinoc]

Je ne connais pas *n*x là-dessus, mais sous Windows, c'est réglable, avec des fonctions comme SetProcessAffinityMask(), SetThreadAffinityMask() et SetThreadIdealProcessor().

Mais normalement, Windows répartit dynamiquement et un thread n'est pas verrouillé sur un processeur.
C'est pourquoi quand tu as un programme "normal" avec qui fait une boucle infinie sur un bi-coeur, tu n'as pas forcément un coeur à 100% et l'autre à 0%: Le thread peut être déplacé après chaque quantum, ce qui met les deux coeurs à environ 50%.

PS: Sous *n*x, ça dépend entre autres de la version: Avant la NPTL, le kernel ne savait même pas ce qu'était un thread, et c'était la partie User du processus qui réglait ça elle-même. Depuis la NPTL, les threads font honneur à leur nom français de "processus légers", et vus du kernel, plusieurs threads d'un même processus sont en fait plusieurs processus partageant leurs ressources.

[DSGSLA]

Merci à tous pour vos réponses.
J'ai assez de matière pour commencer un proto.
Je clos donc le fil.