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.

Intel propose Intel® Parallel Studio

Intel, fort de son expérience comme fournisseur d'outils qui permettent d'optimiser l'utilisation de processeurs multicores sous Mac, Windows et Linux, propose une nouvelle gamme d'outils qui combine cette gamme en un seul ensemble. Il s'agit de Intel® Parallel Studio, qui s'adresse spécifiquement aux développeurs Windows avec Visual C++. Cette gamme trouve ses origines dans la gamme actuelle qui se décline sous forme des quatre outils : Intel® C++ Compiler avec les bibliothèques Intel Performance Primitives, Intel Math Kernel Library et Threading Building Blocks, Intel® Thread Checker, Intel® Thread Profiler et VTune™ Performance Analyzer.

La programmation parallèle, considérée par beaucoup (à tort), comme étant une affaire de spécialistes, peut être envisagée par le développeur C++ ou Fortran sans devoir se battre avec des threads, sémaphores, priorités... grâce à ces outils et aux APIs haut niveau (OpenMP, Threading Building Blocks), soit via le nouveau Intel Parallel Studio, soit via les outils traditoinnels éfoqués ci-dessus. Mais nous n'en sommes qu'au début de cette nouvelle offre qu'est l'Intel Parallel Studio. Par contre il est possible de commencer à tester cet ensemble grâce au programme beta test qu'Intel met en place.

Pour en savoir plus, veuillez regarder le descriptif de l'Intel® Parallel Studio qui se trouve ici et éventuellement aller sur les divers liens qui se trouvent en bas de la page descriptive.

Pourquoi Programmation Parallèle pour Tous ?

Depuis 1982, date de mon premier contact avec l'informatique à taille humaine l'Apple II, à l'opposé des VAX, IBM main frame, etc., j'ai été témoin de la montée en puissance constante de l'informatique. Qui à l'époque, aurait pu imaginer qu'on puisse tenir dans la main un petit appareil qui soit à la foi téléphone, agenda, baladeur, récepteur TV, GPS, courrier électronique et j'en passe. Tout ceci pour dire que M. le Dr. Moore, un des fondateurs d'Intel, à dit un jour, que l'industrie allait doubler le nombre de transistors sur une puces tous les 18 mois.

Et alors, direz-vous ? Et alors c'est énorme. Depuis 1982, cela fait 26 x 12 / 18, donc 18. Ceci signifie qu'une puce en 2009 contient 2 puissance 18 soit 524288 plus de transistors qu'en 1982 - c'est énorme et c'est ce qui explique la montée en puissance, non seulement quant au nombre de transistors, mais également la vitesse, la bande passante, le stockage... Mais sur ces 27 ans, une constante a été maintenue - nous étions toujours en mono processeur ce qui permettait aux programmeurs de compter sur la montée en puissance pour absorber la gourmandise des applications quant à leur besoins en ressources.

Pavé dans la mare! Voilà qu'il y a trois ans environ, les fondeurs de puces buttent sur une frontière physique. Vers 2,6 gHz, les besoins énergétiques d'une puce augmentent très fortement avec la cadence ce qui se traduit par l'impossibilité de suivre la loi de Moore quant à la vitesse. Si nous étions à 2,6 gHz en 2007, nous devrions être aux alentours de 5,2 gHz en 2009. Et bien non. Nous sommes toujours à 2,6 et les fondeurs, dans leur sagesse, nous proposent le double de cycle CPU mais sur deux coeurs et non sur un seul. Ce qui est bien, par contre, il faut avoir prévu que l'application puisse exploiter les deux coeurs simultanément ce qui implique une programmation parallèle. Voilà, le mot est lâché.

Mais il ne faut pas s'arrêter à deux coeurs. j'ai vu à la FNAC aujourd'hui mon premier portable quadcore in vivo (un HP), et ASUS en a un (l'ASUS G71). Dell aussi j'imagine... et Intel qui nous dit qu'ils travaillent sur un 80 cores à titre expérimental pour connaître les enjeux d'une parallélisation massive.

Forte de ce constat, et ayant longtemps programmé en C++, Fortran, java... je découvre avec à mon grand soulagement que je pourrais dorénavant profiter de ces nouvelles puces sans devoir me plonger dans des détails de programmation parallèle comme les threads, sémaphores, priorités... avec des outils totalement inadaptés comme les compilateurs, débogueurs et bibliothèques que j'avais l'habitude d'utiliser.

Etant naturellement curieuse je me suis lancée dans l'aventure, surtout avec les outils Intel qui permettent non seulement de développer les applications parallèles, mais également de les mettre au point, ceci dans le contexte de mon activité professionnelle comme revendeur d'outils de développement. Par la suite, ayant approfondi les techniques, j'ai créé, avec l'aide d'Intel, un cours de deux jours de banalisations de la programmation parallèle en s'appuyant sur les techniques comme OpenMP et Threading Building Blocks. J'écarte MPI car il s'agit d'un univers très spécialisé, notamment du domaine des clusters, et les Win Threads et Posix car nous pourrions dénommer ces techniques comme l'assembleur de la programmation parallèle - puissante mais oh combien difficile à mettre en oeuvre et déboguer.

Donc voici le fil conducteur qui m'a mené à créer ce blog via lequel je compte générer des échanges sur les techniques et outils de programmation parallèle accessibles à tout programmeur C++ ou Fortran.