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.