XXP

mai 2016

lun. mar. mer. jeu. ven. sam. dim.
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          

« Puissance de calcul : la loi de Moore dans les mains des développeurs | Accueil | Puissance de calcul : la loi de Moore dans les mains des développeurs »

06 novembre 2008

Puissance de calcul : la loi de Moore dans les mains des développeurs

Puissance_nombre2
Puissance multi-coeur

La prédiction de Moore, qui prévoit le doublement de la puissance de calcul des microprocesseurs tous les deux ans (libre interprétation de la formulation initiale de Moore dont le sujet était le nombre de transistors), est menacée par la réalité physique. C'est au software de secourir le hardware.

Problèmes physiques...

Les obstacles qui se dressent sur la route de la course à la puissance de calcul obligent AMD, Intel et autres fondeurs à chercher d'autres chemins que l'entassement de transistors ou l'accroissement des fréquences d'horloge :

  • Mur de la puissance : augmenter encore le nombre de transistors présents sur une puce ou augmenter encore la fréquence d'horloge impose de savoir absorber le surplus de chaleur, alors que les solutions de refroidissement acceptables ont déjà été exploitées.
  • Mur de la mémoire : un accès à la mémoire DRAM peut coûter quelques 300 cycles d'horloge du microprocesseur, au contraire de l'accès à la mémoire dite cache, embarquée sur la puce. Dépasser cette limite consiste à gonfler la mémoire cache de la puce, mais le mur de la puissance réapparaît...
  • Mur de la complexité : paralléliser automatiquement le pipeline de traitement est une solution valable mais couteuse en termes de transistors car algorithmiquement complexe. Trouver de nouvelles astuces pour détecter à la volée les instructions parallélisables malgré la complexité du code et des données qui s'y rapportent est de moins en moins rentable et se heurte encore à la barrière de la dissipation de chaleur.

Plutôt que de se frotter à ces limites physiques, les fabricants de microprocesseurs préfèrent les contourner en jouant sur un tout autre paramètre, le parallélisme des fils d'exécution. Ce que font très bien les puces multi-cœurs.

... Solutions logicielles

Mais l'objectif de ces puces n'est atteint que si leurs multiples cœurs sont effectivement exploités. Autrement dit vu de l'utilisateur, le gain en confort n'est réel que si le logiciel manipulé consomme les possibilités de multithreading que le hardware lui offre.

Aujourd'hui c'est rarement le cas, d'une part parce que les logiciels actuels n'ont pas été conçus pour  ce type de hardware, et d'autre part parce que développer des logiciels multi-threadés est beaucoup plus difficile et donc beaucoup plus cher que de les développer "à l'ancienne", sans se soucier de parallélisme. Sans outils de développement adaptés, même un développeur expérimenté peut produire des bugs caractéristiques du multi-threading, souvent féroces (deadlock, crash) et difficiles à reproduire. Et bien sûr, ces bugs n'apparaissent en général que chez le client parce que celui-ci possède une configuration non testée (le dernier 256 cœurs à la mode…).

C'est pourquoi les librairies d'aide à la gestion du parallélisme sont indispensables aux développeurs soucieux de performances.

Pour .Net, ce sont les Parallel Extensions, qui feront partie de .Net 4.0 et qui sont en preview depuis décembre 2007. TPL, pour Task Parallel Library et  PLINQ, pour Parallel LINQ, font partie de ce package.

TPL permet par exemple de paralléliser une boucle (presque) sans risque d'erreur  avec Parallel.For :

    void Render(Scene scene, Color[,] rgb)

    {

        Parallel.For(0, screenHeight, delegate(int y)

        {

            for (int x = 0; x < screenWidth; x++)

            {

                rgb[x, y] = TraceRay(new Ray(scene, x, y));

            }

        });

    }

 

Pour le C++ natif, PPL (Parallel Pattern Livrary) sera inclus dans Visual Studio 2010.

Pour Java, Google vient de lancer la librairie open-source Korus, et les nouveautés de Java 7 API  comprendront des ajouts dans java.util.concurrency.

Voilà de quoi laisser le software prendre le relai du hardware dans la course à la puissance sans que les coûts de développement n'explosent.

Sources et liens :

TrackBack

URL TrackBack de cette note:
https://www.typepad.com/services/trackback/6a00d8341c871f53ef010535d4704c970c

Listed below are links to weblogs that reference Puissance de calcul : la loi de Moore dans les mains des développeurs:

Commentaires

L'utilisation des commentaires est désactivée pour cette note.