Discussion :

[sone47]

Bonjour a tous,

Une question un peu générale sur le sujet du multithread.
Actuellement une application lance de nombreux calculs (indépendants ou non les uns des autres) de manière séquentielle.

Le but, les lancer en parallèle pour optimiser les temps de calculs.

L'environnement: Windows/Linux (Visual2010 - GCC4? [j'aurai demain l'indice])

2 approches: multithread ou multiproc.

- Multithread
La solution vers laquelle je me tournais instinctivement.
Venant du monde de l'embarqué, je travaillais sur une bibliothèque perso basée su pthread pour gérer des classes qui héritait de ma classe thread (et redefinir mon run etc)
Maintenant je vois qu'il y ici et la d'autres lib (boost, opentop etc..) voir même (mieux?) std::thread de C++11 (si géré par le systeme)

- Multiproc
Une appli manager qui s'occupe de lancer N process de calculs.



Chaque calcul reçoit en entrée un jeu de paramètre en lecture, et fournit en sortie un jeu de paramètre qui peut lui même être l’entrée de N autres calculs.

Ma question est un peu basique, bien que j'ai lu de nombreux posts ici et la sur le sujet mais C++11 peut peut être changer la donne:

Quels aspects doivent être parfaitement étudiés pour pouvoir faire le choix entre multithread/multicœur pour pouvoir lancer ces jeux de calculs dans les 2 systèmes et avoir un gain de perfs.
Est ce qu'en faisant un process qui lance N process le système s'occupe de les placer sur différents cœurs (comme les threads ?) ?
J'ai pu voir certaines discussions sur la remise en cause des perfos du multithreading, est ce qu'en multithreadant une appli séquentielle qui lance ces N calculs à la suite on est certains d'avoir un gain de temps d’exécution ?
Et pour finir, la place du C++11 dans ces 2 environnements.

Merci a vous pour votre retour sur le sujet si vous êtes déjà passé par la.
Bonne fin de journée

[Emmanuel Deloget]

std::thread est basé sur pthread (en fait, si tu regardes l'interface de la classe, tu le verras très nettement). Du coup, ta lib perso fera l'affaire si la version de gcc que tu utilises n'as pas le support complet de std::thread (qui est assez récent). Sous Windows, std::thread est censé fonctionner de manière similaire - mais en même temps, l'API de gestion des threads est simpliste sous Windows, donc tu peux l'encapsuler comme tu l'as fait pour pthread.

Pour ce qui est de ton gain de temps, il sera au plus égal à Tmono - (Tseq + (Tthread / Nthread)), ou Tmono est le temps de calcul actuel ; Tseq est le temps que tu dois passer à faire des calculs séquentiellement ; Tthread est le temps cumulé réparti sur les thread hardware et Nthread est le nombre de thread hardware. Si Tseq est faible, alors ton gain de temps sera non négligeable.

Que tu crée des thread ou des process, le scheduler de l'OS est censé prendre en charge la répartition sur les thread hardware (normalement, il y en a 2 par cœur sur les processeurs Intel récents). Rappel : sur Linux, les threads et les process sont des kthread - la différence étant le fait qu'un process tiens une configuration de MMU qui lui est propre ; celle-ci étant lourde, le switch de context sera plus lourd que dans le cas d'un thread.

Tu n'es pas censé te mêler de la politique de scheduling (au delà de la notion de priorité, bien sûr), à moins d'avoir une bonne raison de croire que tu peux battre le processeur à son propre jeu (difficile, crois moi).

[sone47]

Bonjour et merci pour cette reponse,

Apres verification la version que j'ai de visual et de gcc (4.1.2) ne gere pas std::thread..
Je n'ai plus acces a la lib que j'avais auparavant non plus.
Pensez vous qu'il soit plus rapide de recoder une surcouche a pthread et winthread ou d'utiliser directement une autre librairie (je vois beaucoup de boost thread) ?

Est ce que l'utilisation de boost thread nécessitera une install particulière sur la machine windows/Linux qui fera tourner le soft ?

Merci d'avance

[Emmanuel Deloget]

Bonjour et merci pour cette reponse,

Apres verification la version que j'ai de visual et de gcc (4.1.2) ne gere pas std::thread..
Je n'ai plus acces a la lib que j'avais auparavant non plus.
Pensez vous qu'il soit plus rapide de recoder une surcouche a pthread et winthread ou d'utiliser directement une autre librairie (je vois beaucoup de boost thread) ?

La question revient donc à : est-ce qu'il est plus rapide de recoder quelque chose qui existe déjà ? La réponse est assez évidente : non, c'est plus long Si tu n'as pas envie de perdre les 2/3 jours au recodage d'une lib portable, alors boost.thread est une bonne alternative (c'est sur boost.thread qu'a été modélisée std::thread ; il y a quelques modifications (move ctor, qui ne sont pas supportés par gcc 4.1.2 de toute façon), mais rien de bien complexe).

Est ce que l'utilisation de boost thread nécessitera une install particulière sur la machine windows/Linux qui fera tourner le soft ?

Nope. boost.thread encapsule les thread natives via des header C++, et - à ma connaissance - ne nécessite pas l'installation d'une librairie spécifique.

[gbdivers]

D'après la doc, boost.thread utilise d'autres modules de boost qui ne sont pas header only. Il y a des options pour ne pas les utiliser et pourvoir utiliser boost.thread en header only. Voir la doc : http://www.boost.org/doc/libs/1_52_0...ead/build.html

[sone47]

Merci pour vos retours,
Je vais regarder ça de plus près.

J’hésitais entre OpenTop et Boost mais si le standard est repartit de boost autant prendre boost, la maintenabilité sera plus facile.

Je vais voir la solution pour ne pas avoir a charger d'autres libs, ca m'arrange.

Merci