En mars 2005, Herb Sutter a publié son célèbre article «The Free Lunch Is Over» (le repas gratuit est terminé) et a prédit une révolution de la programmation concurrente aussi importante que la révolution orientée objet. Voici un bref extrait de l'article expliquant la motivation de cette prédiction :
Les principaux fabricants et architectures de processeurs, d'Intel et AMD à Sparc et PowerPC, ont épuisé la plupart de leurs approches traditionnelles pour augmenter les performances des CPU. Au lieu de pousser toujours plus haut les fréquences d'horloge et le débit d'instructions séquentielles, ils se tournent désormais en masse vers l'hyperthreading et les architectures multicœurs. Ces deux fonctionnalités sont déjà disponibles sur les puces actuelles ; en particulier, le multicœur est disponible sur les processeurs PowerPC et Sparc IV actuels, et arrivera en 2005 chez Intel et AMD. En effet, le grand thème du In-Stat/MDR Fall Processor Forum 2004 était les dispositifs multicœurs, de nombreuses entreprises y présentant des processeurs multicœurs nouveaux ou mis à jour. Avec le recul, il n'est pas exagéré d'appeler 2004 l'année du multicœur.
Aujourd'hui, nous savons que la loi de Moore ne peut pas continuer éternellement, comme expliqué ici
La plupart des prévisionnistes de l'industrie des semi-conducteurs, y compris Gordon Moore, estiment que la loi de Moore prendra fin vers 2025. En avril 2005, Gordon Moore a déclaré dans une interview que la projection ne peut pas être soutenue indéfiniment : « Cela ne peut pas continuer éternellement. La nature des exponentielles est qu'on les pousse et qu'au bout du compte, le désastre arrive. » Il a également noté que les transistors finiraient par atteindre les limites de la miniaturisation au niveau atomique.
Dans le même temps, les fabricants de processeurs continuent d'ajouter des cœurs à chaque nouvelle génération de processeurs. Par exemple, la famille Intel E7 Xeon compte 24 cœurs.
Pour revenir à la prédiction de Herb Sutter, il dit :
La concurrence est la prochaine révolution majeure dans la façon dont nous écrivons les logiciels.
Et
les applications devront de plus en plus être concurrentes si elles veulent exploiter pleinement les gains exponentiels continus de débit des CPU. L'efficacité et l'optimisation des performances deviendront plus importantes, pas moins.
Treize ans après sa prédiction, la concurrence a-t-elle vraiment révolutionné la façon dont nous écrivons les logiciels ? Ou devons-nous attendre encore quelques années pour voir cette révolution se déployer ?
Nous savons que travailler avec le multithreading et les systèmes multicœurs n'est pas facile, et de nombreux développeurs rencontrent des difficultés importantes. Un rapide coup d'œil sur les forums de développeurs révèle des retours comme celui-ci :
I am a fairly good programmer, my boss is also a fairly good programmer. Though he seems to underestimate some tasks such as multi-threading and how difficult it can be (I find it very difficult for anything more than running a few threads, waiting for all to finish, then return results).
The moment you start having to worry about deadlocks and race conditions, I find it very difficult, but the boss doesn't seem to appreciate this - I don't think he has ever come across this. Just slap a lock on it is pretty much the attitude.
So how can I introduce him, or explain why he might be underestimating the complexities of concurrency, parallelism, and multi-threading? Or maybe I am wrong?C'est exactement ce que Herb Sutter a souligné dans son article :
La grande majorité des programmeurs d'aujourd'hui ne maîtrise pas la concurrence, tout comme la grande majorité des programmeurs d'il y a 15 ans ne maîtrisait pas encore les objets. Mais le modèle de programmation concurrente s'apprend, en particulier si l'on s'en tient à la programmation par messages et par verrous, et une fois assimilé, il n'est pas beaucoup plus difficile que l'orienté objet et peut, espérons-le, devenir tout aussi naturel. Soyez simplement prêts et prévoyez l'investissement en formation et en temps, pour vous et pour votre équipe.
Les développeurs sont-ils aujourd'hui conscients des avantages de la concurrence ? Les projets sont-ils conçus pour tirer le meilleur parti de la concurrence, ou avons-nous encore besoin d'experts pour concevoir du code concurrent efficace ? La révolution est-elle là ?
Oui, la révolution est là, mais elle n'a pas été menée par les seuls développeurs. Elle a commencé il y a des années avec de nouveaux langages de programmation, ainsi que de nouvelles bibliothèques et normes pour les langages établis. Les développeurs ont besoin de langages qui facilitent l'exploitation pleine de la concurrence. Se reposer uniquement sur des API de bas niveau est généralement une mauvaise idée, car cela peut introduire de nombreux bugs et autres problèmes.
Rust, Go et Clojure sont des exemples de langages modernes conçus avec la concurrence à l'esprit.
Voici le slogan de Rust :
Rust est un langage de programmation système qui s'exécute à une vitesse fulgurante, empêche les erreurs de segmentation et garantit la sécurité des threads.
Et la définition de Clojure :
Clojure est un langage de programmation dynamique et généraliste, combinant l'accessibilité et le développement interactif d'un langage de script avec une infrastructure efficace et robuste pour la programmation multithread.
Ces nouveaux langages gagnent en popularité, mais rivaliser avec les langages établis comme C, C++, Java et C# reste difficile. Cependant, ces langages établis ont gagné au fil des ans des fonctionnalités et des bibliothèques qui aident les développeurs à tirer parti de la concurrence et à écrire du code concurrent efficace. C'est ce que Herb Sutter a souligné dans son article :
Enfin, les langages et systèmes de programmation seront de plus en plus contraints de bien gérer la concurrence.
Par exemple, Microsoft® .NET Framework 4 a introduit un modèle de programmation parallèle capable d'utiliser tous les cœurs CPU disponibles et d'exécuter le code applicatif en parallèle, améliorant ainsi les performances des programmes C#. Chaque nouvelle version du .NET Framework a ajouté des capacités qui ont facilité la programmation multicœur.
Pour le C++, Herb Sutter a souligné à l'époque qu'il n'existait aucun support normalisé de la concurrence :
Le langage C++ est utilisé depuis longtemps pour écrire correctement des systèmes multithread lourds, mais il n'a aucun support normalisé de la concurrence (la norme ISO C++ ne mentionne même pas les threads, et ce intentionnellement), et la concurrence est donc typiquement réalisée, par nécessité, en utilisant des fonctionnalités et bibliothèques de concurrence non portables, spécifiques à la plateforme. (Elle est aussi souvent incomplète ; par exemple, les variables statiques ne doivent être initialisées qu'une seule fois, ce qui exige généralement que le compilateur les protège par un verrou, mais de nombreuses implémentations C++ ne génèrent pas ce verrou.)
Heureusement, la renaissance du C++ amorcée en 2011 a fourni aux développeurs de nombreuses fonctionnalités utiles qui facilitent la programmation multithread et multicœur.
Pour résumer, la révolution est déjà là, à la fois dans la conception des nouveaux langages de programmation et dans l'ajout de nouvelles fonctionnalités aux langages établis. C'est maintenant aux développeurs d'explorer ces capacités et de les utiliser efficacement. Ne vous inquiétez pas — la programmation concurrente n'est plus aussi effrayante qu'avant.
Au final, Herb Sutter avait raison, ce qui n'a rien de surprenant vu son expertise de longue date. Il a également contribué de manière significative au développement de fonctionnalités de concurrence utiles depuis 2011, à commencer par la norme C++11.