Programmez parallèle oui, mais avec quels outils ?

Il est certain que dès maintenant il faut commencer à sérieusement envisager la mise en oeuvre du parallélisme dans toute application dès qu'elle devient une consommatrice significative des ressources du système. Cette affirmation est tellement vraie qu'elle en devient un pléonasme. Ceci dit, oui, mais avec quels outils ? Comment intégrer du parallélisme dans une application ? Quels efforts faudra-t-il engager ? Et quels résultats envisager ? J'essayerai de répondre à ces questions mais dans le sens inverse.

Quels résultats envisager ?

Avant tout, rien ne peut remplacer une bonne connaissance de l'application. Donc à vous de déterminer quels sont les parties qui pourraient être parallélisées (boucles, tâches ?). Donc si 70% du temps de traitement peut être parallélisé et vous disposez de 4 cores, vous pourrez théoriquement passer, partant d'une base 100, de 30 + 70/4 = 47,5% de temps de traitement, ce qui représente une amélioration des temps de traitement d'environ 50%. Reste à savoir si le feu en vaut la chandelle.

Quels efforts faudra-t-il engager ?

Dans la vie rien n'est gratuit, il faut toujours payer, mais combien payer. Peu ou beaucoup ? La réponse dépend du rapport valeur de l'avantage acquis par rapport aux coûts engagés pour obtenir ces avantages. Le choix des techniques adoptées pour intégrer du parallélisme sera déterminant. Grosso modo, adopter des techniques simples et aboutir à un niveau de parallélisme acceptable à moindre coût ou alors adopter des techniques plus complexes et aboutir à plus de parallélisme ? Si avec la technique A on obtient 100% du potentiel de parallélisation à un coût de 100, ne faudrait-il pas mieux adopter la technique B qui apporte 70% de parallélisation à un coût de 10. Et oui, entre OpenMP et autres techniques, nous sommes bien dans de tels ratios. OpenMP est vraiment très simple, courbe d'apprentissage et de mise au point très faibles alors que d'autres techniques plus abouties présentent des courbes d'apprentissage et coûts de mise au point beaucoup plus forts.

Comment intégrer du parallélisme dans une application ?

Avant de pouvoir répondre à cette question, il faut définir le contexte : OS et langage de programmation - il faut que la chose soit possible. Si vous dites Windows/Visual Basic, je n'ai pas vraiment de solution. Si vous dites Linux/Fortran alors OK pour de l'OpenMP. Si vous dites Windows C++, je peux vous proposer 6 solutions : WinThreads, Posix, OpenMP , Threading Building Blocks (TBB) , la toute nouvelle Parallel Pattern Library (PPL) de Visual Studio 10 et Message Passing Interface (MPI). Voici donc en quelques mots les plus et les moins de chaque solution :

• WinThreads - Solution Microsoft de bas niveau - C++ non portable - difficile à mettre en oeuvre, courbe d'apprentissage longue et coûts de mise au point élevés.
• Posix - Comme WinThreads mais portable linux/unix/Mac.
• OpenMP - Très facile à mettre en oeuvre mais peut présenter des limites. OK pour C++, Fortran et autres langages Windows, linux/unix et Mac. Tout à fait adapté à une première approche à faibles coûts qui peut s'avérer être suffisante.
• Threading Building Blocks (TBB) - Portable Windows/linux/unix/Mac mais seulement C++. Trés puissant mais exige de solides compétences C++.
• Parallel Pattern Library (PPL) - Comme TBB mais uniquement Windows - il s'agit d'une solution propriétaire Microsoft donc à priori à proscrire car ni l'application, ni les compétances du programmeur ne sont portables.
• Message Passing Interface (MPI) - Cette API s'adresse plutôt à une programmation parallèle sur cluster, je l'écarte donc de la suite de mon article.

Il existe d'autres solutions mais elles sont relativement peu utilisées ou alors cantonées à des domaines particuliers.

Avec quels outils faire de la programmation parallèle ?

Ayant choisi une API, probablement OpenMP, la question posée sera quels outils choisir. La réponse à cette question passe par une analyse des différentes tâches à effectuer pour aboutir à une application qui tourne correctement sur des ordinateurs multicores/mutli processeurs quelque soit le nombre de cores (2, 4, 64, voir plus).

• Le compilateur - Que ce soit C++ ou Fortran il faut que le compilateur reconnaisse l'API mise en oeuvre, que ce soit des directives de compilation ou des bibliothèques de mise en oeuvre. Je recommande sans hesitation le compilateur Intel.
• Le débogage - un débogueur traditionnel n'est pas du tout adapté à découvrir des problèmes de parallélisatoin comme des conflits d'accès aux données, verrous... Pour cela il faut des outils spécialisés comme Intel Thread Checker.
• L'équilibrage de charge - Les conflits d'accès et les problèmes de verrous ayant été résolus, l'application utilise-t-elle les ressources de la machine correctement, notamment les cores ? La charge est-elle équilibrée correctement ? Pour cela Intel Thread Profiler ne trouve pas d'égal.
• Utilisation du système - Vous avez résolu tous les problèmes, la charge est correctement équilibrée mais l'application continue de ramer. Pourquoi ? Il y aurait deux explications : soit l'application utilise des ressources (drivers, disques...) qui sont très lents, soit elle exploite mal le micro processeur qui passe sont temps à recharger des buffers ou à attendre des instructions car la programmation est pénalisante. Pour cela Intel VTune™ Performance Analyzer est incontournable.

Les outils présentés ci-dessus s'adressent aux entreprises qui veulent engager des ressources conséquentes pour améliorer les temps d'exécution de leurs applications sur du multicores. Mais il existe une solution plus light qui commence à sortir. Il s'agit de l'Intel Parallel Studio qui s'intégre dans Microsoft Visual Studio 2008.

Voilà, j'espère qu'à travers cet article je vous ai donné un aperçu quant aux solutions pour faire de la programmation parallèle. Pour en savoir plus sur les outils Intel dans ce contexte je vous invite à visiter un descriptif de l'ensemble de la solution Intel.