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

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 :
- Design Considerations For Parallel Programming, MSDN Magazine octobre 2008.
- Microsoft Parallel Extensions to .NET Framework 3.5, June 2008 Community Technology Preview
- Parallel Computing Downloads
Commentaires