I. Introduction▲
I-A. Contexte▲
Le 21 avril 2009, Intel a organisé comme tous les ans une conférence pour parler de ses outils de développement. Cette année, l'accent était exclusivement porté sur sa nouvelle suite de développement parallèle, Intel Parallel Studio, dont la sortie est programmée le 21 mai. Cette conférence, principalement destinée aux revendeurs de logiciels, était aussi pour la première fois ouverte à des représentants de sites web orientés développement, et j'y étais présent pour le compte de developpez.com.
Les présentateurs étaient :
- Christian Staudinger (Intel), qui organisait la conférence ;
- James Reinders (Chief Software Evangelist and Director of Software Development Products, Intel), qui a décrit globalement l'offre d'Intel et a parlé des perspectives futures ;
- Éric Vernié et Blaise Vignon (Microsoft), qui ont présenté la problématique du parallélisme, et évoqué quelques solutions que propose Microsoft pour faciliter le développement parallèle(1) ;
- Charly Lippoth (Nero) qui nous a présenté en quoi son entreprise avait parallélisé une partie de son code, et comment ils avaient utilisé Parallel Studio pour y parvenir ;
- Heinz Bast (Intel), qui nous a parlé de Parallel Composer ;
- Levent Akyil (Intel), qui nous a présenté Parallel Inspector et Parallel Amplifier.
Étant donnée l'audience principale de la conférence, des gens plus au fait du marketing que du développement, les présentations n'étaient pas d'une technicité élevée, et les démonstrations réduites au minimum. Je n'ai donc pas trop eu la possibilité de me faire ma propre opinion sur la manière donc fonctionne le produit en pratique(2).
Vous pourrez aussi avoir plus d'informations en consultant l'interview de James Reinders que j'ai réalisée pendant cette conférence, ainsi que le test d'Intel Parallel Studio écrit par Matthieu Brucher.
Merci à Alp pour la relecture de cet article.
I-B. Enjeux▲
Avant même sa gamme de produits, l'enjeu principal pour Intel est que les développeurs commencent à programmer en parallèle, afin de tirer profit des capacités des processeurs en train de sortir. Jusqu'à l'arrivée des processeurs multicœurs, en effet, il suffisait d'attendre un peu pour acheter une machine plus puissante et avoir des programmes qui tournent plus rapidement. Aujourd'hui, on achète toujours une machine plus puissante, mais elle ne fait plus tourner le programme plus vite, sauf si ce programme a été écrit spécialement pour tirer parti des cœurs supplémentaires. La phrase célèbre résumant cette situation est : « The free lunch is over ».
Pour développer ce genre de programmes, parallèles, un développeur est face à deux problématiques : la justesse des programmes, et la scalabilité.
- La justesse d'abord : développer du code parallèle est compliqué, il faut faire attention à des problèmes qui n'existent pas dans le code classique et portent le doux nom de race condition, deadlock, priority inversion, ressource contention…(3) Et déboguer un tel code est encore plus compliqué : d'une exécution à l'autre, le code ne va pas s'exécuter exactement à la même vitesse, et des problèmes de synchronisation peuvent apparaître et disparaître subrepticement.
- La scalabilité : si on veut de nouveau obtenir des programmes qui évoluent en performance en fonction du matériel sous-jacent, il ne suffit pas qu'ils soient écrits de manière parallèle. Il faut en plus qu'ils s'adaptent dynamiquement aux ressources disponibles, et ne comportent pas de goulot d'étranglement. Il est fréquent d'avoir du code parallèle qui tourne environ deux fois plus vite sur une machine bicœurs que sur une machine monocœur, et encore deux fois plus vite sur un quadricœur, mais qui au bout d'un certain nombre de cœurs sature et ne profite plus d'une augmentation du nombre de cœurs.
Le principal objectif d'Intel est donc que la plupart des programmes ayant des opérations longues à réaliser soient écrits de manière parallèle, et Intel Parallel Studio est une suite d'outils ayant pour objectif de résoudre ces deux problèmes.
II. Intel Parallel Studio▲
Cette suite se compose dans l'esprit de quatre modules, Advisor, Composer, Inspector et Amplifier, qui couvrent différentes phases du cycle de développement. Pourquoi « dans l'esprit » ? Parce que le module Advisor, probablement le plus original des quatre, n'est pas encore fini. Il sortira donc plus tard, à part de Parallel Studio, mais les acheteurs de ce dernier pourront en télécharger une version light.
Des outils de développement, ce n'est pas chose nouvelle chez Intel, qui possède déjà des programmes couvrant à peu près le spectre de Parallel Studio (Vtune, Thread Checker…). Mais ces programmes sont considérés comme assez complexes à utiliser, réservés aux professionnels de l'optimisation, et on peut voir un certain nombre de modules de Parallel Studio comme des versions allégées et relookées de ces outils professionnels, qui continuent à exister(4). Le package Parallel Studio est aussi prévu à un prix plus attractif que les différents outils haut de gamme.
Un des aspects majeurs de cette volonté de simplification, c'est que Parallel Studio n'est pas un outil indépendant, mais un plug-in de Visual Studio, le compilateur en situation de quasi-monopole sur le marché Windows. Ça permet à ces outils de bénéficier de ce qui existe déjà dans Visual Studio, comme le débogueur, en lui apportant de légères modifications, plutôt que de devoir tout redévelopper. Mais surtout, ça évite à l'utilisateur de devoir changer d'environnement de travail, et intègre donc le développement parallèle à son travail de tous les jours. Le problème principal est que pour les gens travaillant dans un autre environnement, il n'est pas possible d'utiliser Parallel Studio.
II-A. Parallel Advisor▲
Même si ce module n'est pas encore prêt, on a eu droit à une petite présentation de comment il doit fonctionner, et de ce qu'il doit apporter. L'idée est, en combinant les moyens mis à disposition d'Inspector et d'Amplifier, de permettre de rapidement prototyper ce que donnerait une parallélisation d'un code.
On part d'un programme existant, ne fonctionnant pas en parallèle. Une première exécution utilisant les fonctions d'Amplifier permet d'identifier les goulots d'étranglement. On ajoute alors dans le code des annotations qui indiquent qu'une parallélisation est envisagée à un certain endroit. Une nouvelle exécution du code montre alors, grâce aux fonctions d'Inspector, quels seraient les problèmes de synchronisation que causerait cette parallélisation, et de nouvelles annotations permettent de les corriger.
Une fois ce cycle effectué, il ne reste plus qu'à transformer ces annotations en véritable code. C'est, je pense, dans la facilité de mise en place de ces annotations par rapport à l'écriture de code vraiment parallèle que se jouera l'intérêt de ce module.
II-B. Parallel Composer▲
Ce module contient les outils qui permettent d'écrire du code parallèle. Comme tous les outils de ce genre sortis récemment, l'objectif est de mettre une certaine distance entre le développeur et les aspects bas niveau de gestion du parallélisme. Ce module est lui-même composé de plusieurs sous-parties, relativement indépendantes.
Par rapport à la version professionnelle Intel Compiler Pro 11.0, il manque à Parallel composer la possibilité de compiler du Fortran, la bibliothèque Math Kernel Library, ainsi que le support de plateformes autres que Windows.
II-B-1. Le compilateur Intel▲
Ce compilateur, qui a une bonne réputation en termes d'optimisation, en particulier dans le domaine scientifique, est la première brique de Composer. Basé sur un front-end EDG, il est bug-compatible avec celui de Microsoft, ce qui est nécessaire pour pouvoir remplacer ce dernier au pied levé, ce qui est un des objectifs de Parallel Studio. En termes d'interface, une simple option dans un menu permet de basculer un projet d'un compilateur à l'autre. Parmi les fonctionnalités les plus intéressantes annoncées, on peut noter :
- la possibilité de paralléliser automatiquement certains codes, ou de remplacer automatiquement certains patterns de code par un appel à une bibliothèque optimisée. Je ne sais pas trop dans quelle mesure ces fonctions, impressionnantes en mode démo, interviennent dans la vie de tous les jours sur un vrai programme ;
- la gestion en avance de phase des lambdas de C++0x. On peut noter que VC10 possédera lui aussi ces lambdas, pour les mêmes raisons : leur présence permet d'alléger énormément le code nécessaire pour écrire du code parallèle.
II-B-2. Parallel Debugger extension for Visual Studio▲
Ce module étend les possibilités de débogage d'un code parallèle par Visual Studio. La possibilité d'ajouter un point d'arrêt au moment où deux threads accèdent simultanément à une même zone mémoire semble en particulier très intéressante pour mieux comprendre les races conditions dans le code.
II-B-3. La bibliothèque Tread Building Blocks (TBB)▲
Cette bibliothèque, déjà très connue pour la programmation parallèle et disponible en open source est incluse dans Composer. Le but de cette bibliothèque est que l'utilisateur ne manipule plus des threads et des locks, mais des fonctionnalités de plus haut niveau, comme des boucles parallèles, des tris parallèles, des structures de données auxquelles on peut accéder sans locks depuis plusieurs threads… Le tout s'adaptant automatiquement au nombre de processeurs disponibles.
Parmi les nouveautés de cette version de TBB, on note la possibilité d'utiliser cette bibliothèque avec des lambdas pour alléger considérablement l'écriture. De nombreux modules ont été modifiés, mais le présentateur n'est pas entré dans les détails lors de la conférence.
II-B-4. La bibliothèque Intel Performance Primitives (IPP)▲
Cette bibliothèque, qui elle n'est pas disponible en open source, contient toute une série de fonctions numériques optimisées. Et en particulier, les valarray de la bibliothèque standard du C++ utilisent certaines de ces fonctions. Voilà qui va peut-être redynamiser cette partie de la bibliothèque qui est actuellement assez peu utilisée.
II-C. Parallel Inspector▲
Parallel Inspector a pour but de détecter les problèmes causés par des erreurs de parallélisme dans du code. Il reprend avec une nouvelle interface les principes d'Intel Thread Checker. Pour y parvenir, il instrumente le code, l'exécute puis collecte et analyse des informations sur ce qui s'est passé.
Il se trouve que la technologie mise en place est très proche de celle utilisée pour analyser des problèmes qui n'ont rien à voir avec le parallélisme, à part le fait qu'il est parfois difficile de faire le lien entre la manière dont le problème se manifeste et la cause de ce dernier : les problèmes d'allocation mémoire. En conséquence, Intel Thread Checker permet aussi de détecter ce genre de problèmes.
II-C-1. Démarche▲
La première étape consiste à instrumenter le code. Cette étape semble bien intégrée dans l'interface de Visual Studio, et ne demande pas de recompilation, l'instrumentation se faisant directement au niveau de l'exécutable (ce qui permet d'instrumenter du code dont on ne possède pas les sources). Qui dit instrumentation dit forcément modifications du comportement du code, en particulier en termes de performances. Inspector propose quatre niveaux différents d'instrumentation, faisant chacun un compromis entre surcoût à l'exécution et problèmes détectés. Les niveaux les plus détaillés peuvent être extrêmement ralentis, au point de rendre problématique l'exécution.
Ensuite, on exécute le programme, puis une analyse des résultats a lieu (qui peut elle aussi durer un certain temps). Enfin, les résultats sont présentés dans une vue qui reprend les problèmes, quand le code source est disponible, les points du code liés à ces problèmes, et des filtres sur ces résultats. Ces derniers sont de deux catégories :
- les filtres génériques : ne montrer que les deadlocks, que les memory leaks, que les leaks supérieurs à telle taille, que les problèmes liés à telle ou telle partie du code source ;
- un filtrage à la demande : ce problème spécifique, je ne veux plus le voir désormais (parce que j'ai analysé qu'en fait, il s'agissait d'un faux positif, ou bien parce que c'est dans le code d'un collègue et que je lui ai transmis l'information, ou bien…).
Enfin, il est possible de séparer ces différentes étapes. On peut par exemple dans des cas extrêmes envoyer un code instrumenté à un client, il l'exécute pour reproduire un problème qui n'arrive que chez lui, nous envoie les fichiers enregistrés lors de l'exécution, on les analyse chez nous.
II-C-2. Analyse de la mémoire▲
Bien qu'il ne s'agisse pas de l'objectif premier de Parallel Studio, il semble que cet outil rende de très grands services (d'après les gens d'Intel, certains utilisateurs se déclarent conquis par Parallel Studio même pour des programmes monothread, rien que par la présence de cet outil). Il existe sur le marché des outils spécialisés pour détecter ce genre de problème, qui coûtent parfois plus cher que l'ensemble du package Parallel Studio…
L'objectif est de détecter des fuites mémoire, des accès à de la mémoire non initialisée ou libérée, une double libération de la mémoire…
II-C-3. Analyse multithread▲
Cette fois, on est dans le cœur du sujet. L'objectif est de détecter les accès en parallèle à une même zone mémoire (data race) et les interblocages de threads (deadlocks). Un des problèmes de cette détection est que d'une exécution à l'autre, les timings seront légèrement différents, et les problèmes ne se reproduiront pas forcément, ou pas de la même manière. C'est ce qui fait toute la difficulté du code parallèle et de son débogage.
Tout l'intérêt de l'outil consiste donc dans le fait qu'il détecte non pas des problèmes qui ont eu lieu, mais des problèmes qui auraient pu avoir lieu. Comment fait-il ? Par une analyse des séquences de verrouillage et d'accès à une zone de mémoire depuis tel ou tel thread, il repère des motifs d'accès qui ne sont pas garantis comme sains. Cela peut dans des cas assez rares conduire à des faux positifs, mais est extrêmement précieux en règle générale.
II-D. Parallel Amplifier▲
Ce dernier module permet de répondre à la question : j'ai parallélisé mon code, il fonctionne, mais fonctionne-t-il vite ? On ne s'occupe plus de la problématique justesse, mais de la problématique scalabilité.
Il y a de nombreuses causes qui pourraient faire que les performances d'un code parallèle ne soient pas proportionnelles au nombre de cœurs disponibles. Le but de ce module est d'identifier les endroits problématiques afin de permettre d'y remédier. Le profiler professionnel d'Intel pour parvenir à ce but est Vtune, qui est réputé pour fournir des informations extrêmement détaillées sur une exécution, mais aussi pour noyer l'utilisateur dans une complexité et un niveau de détails dont il n'a la plupart du temps pas grand-chose à faire.
Cette fois encore, le code va être instrumenté puis exécuté, mais cette fois le but de l'instrumentation est de mesurer les performances. Trois types d'analyse sont prévus :
- Hotspot analysis : comme un profiler classique, cette analyse a pour objectif de détecter les endroits dans le code où beaucoup de temps est passé ;
- Concurrency analysis : cette fois-ci, le but est de montrer à quels endroits l'ensemble des processeurs n'est pas utilisé ;
- Lock&wait analysis : un des points de blocage qui apparaît uniquement quand le nombre de cœurs augmente est que finalement, une partie importante du temps va être passée non pas à travailler, mais à attendre d'avoir le droit de le faire. Le but de cette analyse est donc de mettre en évidence le temps passé à attendre l'obtention d'un verrou.
Parmi les fonctionnalités intéressantes en termes d'interface de ce module, on peut noter deux points :
- l'affichage directement en parallèle du code source des mesures de temps, ce qui permet de mieux suivre ce qui se passe qu'un simple affichage à part ;
- la possibilité d'afficher côte à côte des mesures de temps réalisées à des instants différents, afin en particulier de pouvoir d'un seul coup d'œil juger les impacts d'une modification de code.
III. Conclusions▲
III-A. Et le futur ? La technologie Ct▲
Intel nous a décrit un peu plus en détail une technologie actuellement nommée Ct (le nom commercial n'est pas encore fixé) qui est une bibliothèque de templates C++(5) ayant pour but de faciliter l'écriture de programmes parallèles, grâce au parallélisme par les données. L'idée est de se placer dans un domaine d'application particulier, avec des restrictions spécifiques.
Dans ces conditions, il est possible d'écrire du code qui soit automatiquement parallélisé, sans que la personne qui l'écrit ait à écrire une seule ligne de code spécifique. Et avec un tel parallélisme implicite, il est possible de garantir à la fois que le programme résultant sera exempt de bogues liés au parallélisme, et qu'il s'adaptera automatiquement au nombre de cœurs disponibles.
C'est ce qui fait que les langages de programmation fonctionnels se prêtent mieux que les langages impératifs comme le C++ à une parallélisation automatique du code. C'est aussi similaire à la démarche mise en place par Microsoft avec P-Linq :
|
Produit |
P-Linq |
Ct |
|
Auteur |
Microsoft |
Intel |
|
Domaine |
Requêtes sur des bases de données |
Calculs scientifiques (matrices, vecteurs…) |
|
Notation |
Proche du SQL |
Proche des mathématiques |
|
Restrictions |
La requête est exécutée par le système, le développeur n'a pas de contrôle précis dessus |
Interdiction pour le développeur d'avoir des pointeurs à l'intérieur de structures de données gérées par Ct, pour éviter l'aliasing |
Peut-être verra-t-on dans le futur de nouvelles colonnes à ce tableau.
III-B. Microsoft/Intel▲
Une question qu'on peut se poser quand on développe sous Windows et qu'on voit ces outils, c'est vaut-il mieux utiliser les outils Microsoft (qui connait bien le système, et après tout, c'est le système qui gère les différents threads d'exécution) ou bien ceux d'Intel (qui connait bien le matériel, et après tout, c'est le matériel qui fait la performance) ?
Pour une grande partie, cette question ne se pose pas, Intel Parallel Studio et Microsoft Developper Studio étant en grande partie des produits complémentaires plutôt que concurrents. La présence d'Éric Vernié de Microsoft qui a fait une présentation lors d'une conférence Intel en est bien un signe. Par exemple, si on regarde les fonctionnalités de débogage orienté multithread, celles ajoutées par Microsoft dans Visual Studio 10 ont pour objectif majeur de permettre aux développeurs de manipuler au cours d'une session de debug la notion de tâche et non plus de thread, et celles ajoutées par Intel de détecter un cas d'erreur de programmation parallèle classique, le data race. Elles sont donc complémentaires.
Je vois principalement quatre points sur lesquels les offres de Microsoft et d'Intel peuvent entrer en concurrence.
III-B-1. Le compilateur▲
Sur ce point, je n'ai rien d'autre à dire que : « Que le meilleur gagne ! » Surtout si on peut les échanger sans douleur, c'est une bonne chose pour le développeur d'avoir une possibilité de choix supplémentaire.
III-B-2. Les couches bas niveau de gestion des threads▲
Comme indiqué au début, l'un des buts est que les utilisateurs ne manipulent plus directement des structures bas niveau comme les threads, mais des notions plus haut niveau qui se chargent de s'adapter au nombre de cœurs disponibles à chaque instant. Si divers programmes utilisent chacun de leur côté des techniques propriétaires, ils se comporteront peut-être correctement individuellement, mais entreront en compétition si on les exécute simultanément, au détriment des performances globales.
Microsoft a mis au point ce qu'ils nomment le concurrency runtime, une couche d'abstraction qui gère justement ces aspects bas niveau. Et la bonne nouvelle est qu'Intel a indiqué que la bibliothèque TBB, quand elle tournera sous Windows, utilisera cette couche logicielle. Donc des programmes développés avec les bibliothèques Microsoft ou Intel devraient coopérer sans problèmes.
III-B-3. Les bibliothèques utilisateur de threading▲
Il y a concurrence directe en termes d'objectifs entre les Thread Building Blocks (TBB) d'Intel et la Parallel Pattern Library (PPL) de Microsoft : elles s'adressent au même public (des développeurs C++ voulant paralléliser leur code pour la performance) et parlent globalement le même langage (parallel_for…). Sur ce domaine, Microsoft a plutôt une position d'outsider.
Voir à ce sujet une de mes questions dans l'interview de James Reinders.
III-B-4. Le profiler▲
Dans les versions professionnelles, Microsoft fournit un profiler qui reprend certaines des fonctions que propose Parallel Amplifier. Mais ce profiler n'est pas (du moins dans sa version 2008) orienté parallélisme. De plus, son utilisation s'avère dans la pratique assez peu pratique (volume de données collecté trop important faisant aisément planter l'analyse d'une exécution). J'espère que sur ce point Parallel Amplifier remplira ses promesses.
III-C. Faut-il s'intéresser au développement parallèle en C + + ?▲
La réponse me semble sans hésiter oui ! Aujourd'hui, si on développe en C++, surtout sous Windows où d'autres langages existent et font l'objet d'un fort lobbyisme, c'est principalement parce qu'on est dans des domaines où l'on a besoin de bonnes performances. Et dans le futur proche, où toutes les machines auront plusieurs cœurs, il sera dommage et dommageable de ne pas en tirer parti.
Certes, malgré les outils, le développement parallèle reste plus complexe et donc plus coûteux. Mais a-t-on vraiment le choix ?
III-D. Faut-il acheter Intel Parallel Studio ?▲
À l'issue de la conférence, j'ai l'impression qu'il constitue une offre solide qui couvre assez bien l'ensemble des besoins qui ne sont pas couverts par Visual Studio pour le parallélisme. Bien entendu, rien n'est parfait en ce bas monde (par exemple le surcoût en temps d'exécution de code instrumenté peut être très gênant), mais sans outils pour aider à écrire du code parallèle correct et adaptable, cette tâche est encore plus complexe.
À chacun de décider, bien entendu, mais je pense qu'il est très pertinent pour tout développeur professionnel en C++ sous Windows d'étudier la question.