Univers parallèle

Lorsqu'Anwar Ghuloum est arrivé chez Intel en 2002, l'entreprise était le leader parmi les fabricants de puces, principalement parce qu'elle livrait des processeurs fonctionnant à des vitesses de plus en plus élevées. Nous étions déjà à trois gigahertz avec le Pentium 4, et la feuille de route prévoyait des vitesses d'horloge futures de 10 gigahertz et au-delà, se souvient Ghuloum, qui a un doctorat de Carnegie Mellon et est maintenant l'un des principaux ingénieurs de l'entreprise. La même année, lors de la conférence des développeurs d'Intel, Pat Gelsinger, directeur de la technologie, a déclaré : Nous sommes sur la bonne voie, d'ici 2010, pour des appareils de 30 gigahertz, 10 nm ou moins, offrant une téra-instruction de performances. C'est mille milliards d'instructions informatiques par seconde.

Mais Gelsinger avait tort. Intel et ses concurrents fabriquent toujours des processeurs qui plafonnent à moins de quatre gigahertz, et quelque chose autour de cinq gigahertz est désormais considéré, du moins pour l'instant, comme la vitesse maximale possible pour la technologie silicium.

Cette histoire faisait partie de notre numéro de janvier 2009

• Voir le reste du numéro
• S'abonner

Ce n'est pas comme si la loi de Moore - l'idée que le nombre de transistors sur une puce double tous les deux ans - avait été abrogée. Au contraire, des problèmes inattendus de génération de chaleur et de consommation d'énergie ont mis une limite pratique sur les vitesses d'horloge des processeurs, ou la vitesse à laquelle ils peuvent exécuter des instructions. Les nouvelles technologies, telles que la spintronique (qui utilise la direction de spin d'un seul électron pour coder les données) et les transistors quantiques (ou tunneling), pourraient finalement permettre aux ordinateurs de fonctionner beaucoup plus vite qu'aujourd'hui, tout en utilisant beaucoup moins d'énergie. Mais ces technologies sont à au moins une décennie d'atteindre le marché, et elles nécessiteraient le remplacement des lignes de fabrication de semi-conducteurs qui ont coûté plusieurs dizaines de milliards de dollars à construire.

Ainsi, afin de tirer le meilleur parti des technologies disponibles, les fabricants de puces adoptent une approche différente. Les transistors supplémentaires prédits par la loi de Moore ne sont pas utilisés pour accélérer le fonctionnement des processeurs individuels, mais pour augmenter le nombre de processeurs à l'intérieur d'une puce. Les puces à deux processeurs (ou cœurs) sont désormais la norme pour les ordinateurs de bureau, et les puces à quatre cœurs sont de plus en plus courantes. À long terme, Intel envisage des centaines de cœurs par appareil.

Mais voici le problème : alors que le problème matériel de la surchauffe des puces se prête bien à la solution matérielle de l'informatique multicœur, cette solution donne lieu à son tour à un problème logiciel délicat. Comment programmer pour plusieurs processeurs ? C'est le travail d'Anwar Ghuloum de le comprendre, avec l'aide des groupes de programmation qu'il dirige aux États-Unis et en Chine.

Les entreprises de microprocesseurs prennent un risque énorme en adoptant la stratégie multicœur. S'ils ne parviennent pas à trouver des moyens simples d'écrire des logiciels pour les nouvelles puces, ils pourraient perdre le soutien des développeurs de logiciels. C'est pourquoi la machine de jeu multicœur PlayStation 3 de Sony a été commercialisée tardivement et compte encore moins de titres de jeux que ses concurrents.

Le problème avec le silicium
Pendant les 30 premières années de développement des microprocesseurs, le moyen d'augmenter les performances consistait à fabriquer des puces dotées de fonctionnalités de plus en plus petites et fonctionnant à des vitesses d'horloge de plus en plus élevées. L'ordinateur Apple II original de 1977 utilisait un processeur huit bits qui fonctionnait à un mégahertz. La norme PC d'aujourd'hui est une puce 64 bits fonctionnant à 3,6 gigahertz, soit 28 800 fois plus vite. Mais c'est là que cette trajectoire semble s'arrêter. Vers 2002, les plus petites caractéristiques pouvant être gravées sur une puce par photolithographie étaient réduites à 90 nanomètres, une échelle à laquelle des effets imprévus provoquaient la fuite d'une grande partie de l'électricité pompée dans chaque puce, produisant de la chaleur mais ne faisant aucun travail. . Pendant ce temps, les transistors étaient si serrés sur les puces que la chaleur qu'ils généraient ne pouvait pas être absorbée et emportée. Au moment où les vitesses d'horloge ont atteint cinq gigahertz, les fabricants de puces ont réalisé que les puces deviendraient si chaudes que sans systèmes de refroidissement élaborés, le silicium à partir duquel elles étaient fabriquées fondrait. L'industrie avait besoin d'un moyen différent pour améliorer les performances.

En raison des conceptions complexes que nécessitent désormais les puces monocœur haute vitesse, plusieurs cœurs peuvent fournir la même quantité de puissance de traitement tout en consommant moins d'électricité. Moins d'électricité produit moins de chaleur. De plus, l'utilisation de plusieurs noyaux étale toute la chaleur présente.

Cependant, la plupart des programmes informatiques n'ont pas été conçus avec plusieurs cœurs à l'esprit. Leurs instructions sont exécutées dans une séquence linéaire, sans que rien ne se passe en parallèle. Si votre ordinateur semble faire plus d'une chose à la fois, c'est parce que le processeur passe d'une activité à l'autre plus rapidement que vous ne pouvez l'imaginer. Le moyen le plus simple d'utiliser plusieurs cœurs a donc été de répartir le travail, par exemple en exécutant le système d'exploitation sur un cœur et une application sur un autre. Cela ne nécessite pas un tout nouveau modèle de programmation, et cela peut fonctionner pour les puces d'aujourd'hui, qui ont deux ou quatre cœurs. Mais qu'en est-il de demain, qui peut avoir 64 cœurs ou plus ?

Revisiter le vieux travail
Heureusement, dit Leslie Valiant, professeur d'informatique et de mathématiques appliquées à l'Université Harvard, les principes fondamentaux du parallélisme ont été élaborés il y a des décennies dans le domaine du calcul haute performance, c'est-à-dire avec des superordinateurs. Le défi maintenant, dit Valiant, est de trouver un moyen de rendre cet ancien travail utile.

Les superordinateurs qui ont inspiré l'informatique multicœur étaient des appareils de deuxième génération des années 1980, fabriqués par des sociétés comme Thinking Machines et Kendall Square Research. Ces ordinateurs utilisaient des processeurs standard par centaines, voire par milliers, les exécutant en parallèle. Certains ont été commandés par la Defense Advanced Research Projects Agency des États-Unis comme une alternative moins chère aux superordinateurs Cray. Les leçons apprises dans la programmation de ces ordinateurs sont un guide pour faire fonctionner la programmation multicœur aujourd'hui. Ainsi, Grand Theft Auto pourrait bientôt bénéficier de la recherche logicielle effectuée il y a deux décennies pour aider à la conception de bombes à hydrogène.

Dans les années 1980, il est devenu clair que le problème clé du calcul parallèle est le suivant : il est difficile de séparer un logiciel, de sorte qu'il puisse être traité en parallèle par des centaines de processeurs, puis de le réassembler dans le bon ordre sans permettre au résultat escompté soit corrompu ou perdu. Les informaticiens ont découvert que si certains problèmes pouvaient facilement être parallélisés, d'autres ne le pouvaient pas. Même lorsque les problèmes pouvaient être parallélisés, les résultats pouvaient toujours être renvoyés dans le désordre, dans ce qu'on a appelé une condition de concurrence. Imaginez deux opérations exécutées en parallèle, dont l'une doit se terminer avant l'autre pour que le résultat global soit correct. Comment s'assurer que le bon remporte la course ? Imaginez maintenant deux mille ou deux millions de tels processus.

Ce que nous avons appris de ces travaux antérieurs en calcul haute performance, c'est qu'il existe des problèmes qui se prêtent au parallélisme, mais que les applications parallèles ne sont pas faciles à écrire, explique Marc Snir, codirecteur de l'Universal Parallel Computing Research Center (UPCRC) au Université de l'Illinois à Urbana-Champaign. Normalement, les programmeurs utilisent des langages et des outils de programmation spécialisés pour écrire des instructions pour l'ordinateur dans des termes plus faciles à comprendre pour les humains que les 1 et les 0 du code binaire. Mais ces langages ont été conçus pour représenter des séquences d'opérations linéaires ; il est difficile d'organiser des milliers de processus parallèles via une série linéaire de commandes. Pour créer des programmes parallèles à partir de zéro, ce sont des langages qui permettent aux programmeurs d'écrire du code sans penser à la façon de le rendre parallèle au programme comme d'habitude pendant que le logiciel découvre comment distribuer efficacement les instructions entre les processeurs. Il n'y a pas encore de bons outils pour cacher le parallélisme ou pour le rendre évident [comment y parvenir], dit Snir.

Lumière étincelantes: En 1987, Thinking Machines a sorti son superordinateur CM-2 (ci-dessus), dans lequel 64 000 processeurs fonctionnaient en parallèle. L'entreprise a déclaré faillite en 1994, mais son impact sur l'informatique était important.

Pour aider à résoudre de tels problèmes, les entreprises ont rappelé au service des barbes grises de la superinformatique des années 1980. David Kuck, par exemple, est un professeur émérite de l'Université de l'Illinois bien connu en tant que développeur d'outils pour la programmation parallèle. Maintenant, il travaille sur la programmation multicœur pour Intel. Il en va de même pour toute une équipe embauchée de l'ancienne Digital Equipment Corporation ; dans une vie professionnelle antérieure, il a développé la mise en œuvre par Digital de l'interface de passage de messages (MPI), la norme logicielle dominante pour le calcul intensif multimachine aujourd'hui.

Dans un sens, ces anciens joueurs ont plus de facilité que la dernière fois. En effet, de nombreuses applications multicœurs d'aujourd'hui sont très différentes de celles imaginées par le légendaire concepteur de mainframe Gene Amdahl, qui a émis l'hypothèse que le gain de vitesse réalisable en utilisant plusieurs processeurs était limité par le degré de parallélisation d'un programme donné.

Les ordinateurs traitent des volumes de données plus importants que jamais auparavant, mais leurs tâches de traitement sont si parfaitement adaptées à la parallélisation que les contraintes de la loi d'Amdahl - décrites en 1967 - commencent à ne plus ressembler à aucune contrainte. L'exemple le plus simple d'une tâche massivement parallèle est la détermination par force brute d'un mot de passe inconnu en essayant toutes les combinaisons de caractères possibles. Répartir les solutions potentielles entre 1 000 processeurs ne peut qu'être 1 000 fois plus rapide. Il en va de même pour les applications gourmandes en processeurs d'aujourd'hui pour l'encodage de données vidéo et audio. La compression d'images de film en parallèle est presque parfaitement efficace. Mais si le traitement parallèle est plus facile à trouver des utilisations pour aujourd'hui, il n'est pas forcément beaucoup plus facile à faire. Le rendre plus facile nécessitera un effort concerté de la part des fabricants de puces, des développeurs de logiciels et des informaticiens universitaires. En effet, l'UPCRC de l'Illinois est financé par Microsoft et Intel, les deux sociétés qui ont le plus à gagner si l'informatique multicœur réussit, et le plus à perdre en cas d'échec.

Inventer de nouveaux outils
Si les logiciels deviennent de plus en plus complexes, ce n'est pas seulement parce que plus de fonctionnalités y sont ajoutées ; c'est aussi parce que le code est construit sur de plus en plus de couches d'abstraction qui cachent la complexité de ce que font réellement les programmeurs. Il ne s'agit pas d'un simple excès : les programmeurs ont besoin d'abstractions pour que le code binaire de base fasse le travail toujours plus avancé que nous voulons qu'il fasse. Cependant, lorsqu'il s'agit d'écrire pour des processeurs parallèles, les programmeurs utilisent des outils si rudimentaires que James Larus, directeur de l'architecture logicielle pour le projet Data Center Futures chez Microsoft Research, les compare au langage de niveau le plus bas et le plus difficile qu'un programmeur puisse utiliser. .

Nous ne pouvions pas imaginer écrire le logiciel d'aujourd'hui en langage assembleur, dit-il. Mais pour une raison quelconque, nous pensons que nous pouvons écrire des logiciels parallèles de sophistication égale avec les pièces nouvelles et critiques écrites dans ce qui équivaut à un langage d'assemblage parallèle. Nous ne pouvons pas.

C'est pourquoi Microsoft publie des outils de programmation parallèle aussi rapidement que possible. F#, par exemple, est la version parallèle de Microsoft du langage de programmation ML à usage général. Non seulement il parallélise certaines fonctions, mais il les empêche d'interagir de manière incorrecte, de sorte que le logiciel parallèle devient plus facile à écrire.

Intel, quant à lui, envoie Ghuloum à l'étranger une semaine par mois pour discuter avec les développeurs de logiciels de l'architecture multicœur et des modèles de programmation parallèle. Nous avons adopté la philosophie selon laquelle le « problème » de la programmation parallèle ne sera pas résolu dans un an ou deux et nécessitera de nombreuses améliorations incrémentielles – et un petit nombre de sauts – vers les langages existants, dit Ghuloum. J'ai aussi tendance à penser que nous ne pouvons pas faire cela dans le vide ; c'est-à-dire que sans retour significatif du programmeur, nous finirons sans aucun doute avec la mauvaise chose d'une manière ou d'une autre.

Sur les marchés commerciaux et open source, d'autres nouveaux langages et outils exploitent la puissance du traitement multicœur ou masquent sa complexité. Parmi ceux-ci figurent le framework MapReduce de Google, qui facilite l'exécution de calculs parallèles sur des clusters d'ordinateurs, et Hadoop, une implémentation open source de MapReduce qui peut distribuer des applications sur des milliers de nœuds. De nouveaux langages de programmation comme Clojure et Erlang ont été conçus dès le départ pour le calcul parallèle. La populaire application de chat Facebook a été écrite en partie en Erlang.

Pendant ce temps, Cilk Arts, une entreprise dérivée du MIT, peut diviser des programmes écrits dans le langage établi C++ en threads pouvant être exécutés en parallèle sur plusieurs cœurs. Et Appistry, basée à Saint-Louis, affirme que son Enterprise Application Fabric distribue automatiquement les applications pour le cadre de programmation .Net de Microsoft sur des milliers de serveurs sans obliger les programmeurs à modifier une seule ligne de leur code d'origine.

Les limites de l'informatique multicœur

Tout comme le rêve d'Intel de puces de 10 et 30 gigahertz a cédé la place à la poursuite de l'informatique multicœur, cependant, le multicœur lui-même pourrait durer quelques années plutôt que des décennies. L'efficacité des systèmes parallèles diminue avec chaque processeur ajouté, car les cœurs se disputent les mêmes données ; il viendra un moment où l'ajout d'un cœur supplémentaire à une puce la ralentira réellement. Cela pourrait bien fixer une limite pratique à la stratégie multicœur bien avant que nous commencions à acheter des PC à cent cœurs.

Est-ce important, cependant? Bien qu'il puisse y avoir des applications qui nécessitent la puissance de nombreux cœurs, la plupart des gens n'utilisent pas ces applications. À part les joueurs invétérés, peu de gens se plaignent que leurs PC sont trop lents. En fait, Microsoft a souligné que Windows 7, le successeur de Windows Vista en difficulté, utilisera moins de puissance de traitement et de mémoire que Vista, une évolution rendue nécessaire par la popularité des plates-formes informatiques mobiles de faible puissance et la migration attendue des applications PC vers Serveurs basés sur Internet. Un cynique pourrait dire que la quête d'une puissance de traitement toujours croissante est strictement commerciale - que les sociétés de semi-conducteurs et d'ordinateurs, les fournisseurs de logiciels et les fabricants de téléphones mobiles ont besoin de nous pour acheter de nouveaux gadgets.

Alors, quel est l'inconvénient si l'informatique multicœur échoue ? Quel est l'impact probable sur notre culture si nous prenons un zig technique qui aurait dû être un zag et que nous ne sommes soudainement plus capables d'utiliser les 64 cœurs de processeur de nos futurs ordinateurs portables ?

J'ai hâte ! dit Steve Wozniak, l'inventeur de l'Apple II. L'abrogation de la loi de Moore créerait une renaissance pour le développement de logiciels, affirme-t-il. Ce n'est qu'alors que nous pourrons enfin créer un logiciel qui fonctionnera sur une plate-forme stable et durable.

Dans les écoles, dit Woz, la durée de vie d'un bureau est de 25 ans, celle d'un manuel de 10 ans et celle d'un ordinateur de trois ans, le maximum. Lequel de ces appareils coûte le plus cher à acheter et à utiliser ? Pourquoi, le PC, bien sûr. Lequel a une valeur résiduelle lorsque sa durée de vie utile est terminée ? Pas le PC, il en coûte de l'argent pour s'en débarrasser. Au moins, les livres peuvent être brûlés pour la chaleur. Tant que la technologie ne ralentira pas suffisamment pour que les plates-formes informatiques durent suffisamment longtemps pour être économiquement viables, elles ne seront pas vraiment intrinsèques à l'éducation. Ainsi, la fin de la loi de Moore, même si elle peut sembler mauvaise, serait en fait très bonne.

Robert X. Cringely écrit sur la technologie depuis 30 ans. Il est l'auteur de Empires accidentels : comment les garçons de la Silicon Valley gagnent des millions, combattent la concurrence étrangère et n'arrivent toujours pas à obtenir un rendez-vous .

cacher