Le parallélisme est l'avenir du code... même si les développeurs français semblent en douter. Microsoft avait insisté sur le sujet lors de son dernier Tech'Ed, il y a deux semaines aux Etats-Unis, et deux responsables produits de l'éditeur sont venus ce lundi à Paris, au centre de conférences Microsoft, présenter les dernières avancées de l'équipe Visual Studio, devant un public très clairsemé, malgré l'entrée gratuite. Il est vrai qu'écouter Microsoft - connu pour avoir empilé les couches de code et fait de Windows un monstre à l'appétit gargantuesque - parler d'optimisation du code a quelque chose de comique. Néanmoins, l'éditeur semble avoir compris que l'ère du « free lunch » est terminée, pour reprendre les propos de Steve Teixeira, un des deux animateurs de cette après-midi consacrée à la parallélisation du code. Pour lui, l'ère du « free lunch » correspond à une attitude où le développeur n'optimise pas son code, dans la mesure où il considère que le fait d'ajouter par la suite des ressources machine suffira à le rendre performant. C'est ce qui semble avoir présidé jusqu'à présent aux développements de Windows, comme le dénonçait récemment Gartner. Le parallélisme obligatoire pour tirer parti du multi-coeur Les fabricants de processeurs ont, malheureusement pour les éditeurs, dû rompre l'enchantement du « free lunch ». Les performances des CPU ne pouvaient en effet continuer de croître qu'en multipliant le nombre de coeurs en leur sein. Or les applications, telles qu'elles sont conçues actuellement, ne savent pas tirer parti des architectures multi-coeurs. Pour de vrais gains de performance, les applications doivent être programmées avec des mécanismes de parallélisme. Mais comme le souligne Steve Teixeira, il s'agit d'un travail extrêmement complexe, réservé aux développeurs les plus brillants. Microsoft propose depuis le début du mois un outillage spécifique pour masquer cette complexité. Comme Keith Yedlin, responsable de ce programme d'extensions pour le parallélisme le reconnaît, le kit Parallel Extensions (disponible en téléchargement en version CTP, donc pas encore finalisée) ne répond pas encore à toutes les problématiques introduites par la parallélisation. Ne serait-ce, par exemple, que parce que les outils ne savent pas aujourd'hui rendre compte de façon visuelle de la concomitance d'activités (le public français a d'ailleurs eu un aperçu du prochain débogueur, conçu en WPF, l'interface graphique riche de Microsoft) ; or le parallélisme consiste justement à découper un programme de façon à l'exécuter sur tous les coeurs en même temps. Une CPU utilisée à fond multiplie par 5 les performances [[page]] Il faut savoir aussi comment gérer l'intégrité de données manipulées par deux processus en parallèle. Autre limite, certaines applications dépendent d'actions séquentielles. Néanmoins, lorsque les scénarios s'y prêtent, les performances sont impressionnantes. Parmi les démonstrations, une simple requête sur une base, écrite en Linq, et qui consommait 25% de la CPU (un quadricoeur), demandait par exemple 10,27 secondes. La même requête en PLinq - donc avec une instruction rendant le code parallèle - consommait 98% de la CPU mais donnait la réponse en seulement 2,11 secondes. Fait notable, les démonstrations étaient réalisées sur Vista : le système lui-même n'est pas spécialement optimisé pour les multi-coeurs, mais une application optimisée parvient tout de même à en tirer parti. Des opportunités à inventer et à saisir pour les développeurs d'applications Si tout n'est pas résolu, les opportunités sont déjà nombreuses, souligne Steve Teixeira. On peut ainsi imaginer de passer à de nouvelles interfaces homme-machine, impensables avant car bien trop gourmandes. On peut aussi imaginer des applications répondant de façon immédiate, reléguant l'irritant sablier aux oubliettes. Et à la fin, la nature du développeur reprendra ses droits : « on pourra ramener le free lunch : une application écrite pour du double-coeur fonctionnera encore mieux avec du quadri-coeur, de l'octo-coeur, etc. »