Le professeur Niklaus Wirth avait raison. Le créateur du langage Pascal, co-auteur de la technologie de programmation structurée , et lauréat du prix Turing 1995 a noté:

"Le ralentissement des programmes est beaucoup plus rapide que l'accélération des ordinateurs"

Depuis lors, cette déclaration a été considérée comme la loi de Wirth . Il nie effectivement la loi de Moore, qui stipule que le nombre de transistors dans les processeurs a doublé depuis 1965 environ. Voici ce que Wirth écrit dans son article "Call for Slim Software" :

«Il y a environ 25 ans, un éditeur de texte interactif ne comptait que 8 000 octets et un compilateur 32 kilo-octets, tandis que leurs descendants modernes nécessitaient des mégaoctets. Tous ces logiciels gonflés sont-ils devenus plus rapides? Non, bien au contraire. S'il n'y avait pas de matériel mille fois plus rapide, les logiciels modernes seraient totalement inutilisables. "

Il est difficile d’être en désaccord avec cela.

Logiciel d'obésité

Le problème du développement de logiciels modernes est très aigu. Wirth souligne un aspect important: le temps. Il suggère que la principale raison de la surcharge du logiciel est le manque de temps de développement.



Aujourd'hui, il y a une autre raison de l'obésité dans les logiciels: l'abstraction. Et c'est un problème beaucoup plus grave. Les développeurs n'ont jamais écrit de programmes à partir de rien, mais cela n'a jamais été un problème auparavant.



Dijkstra et Wirth ont essayé d'améliorer la qualité du code et ont développé le concept de programmation structurée. Ils voulaient sortir la programmation de la crise, et pendant un certain temps, la programmation a été considérée comme un véritable métier pour les vrais professionnels. Les programmeurs se sont souciés de la qualité des programmes, ont apprécié la clarté et l'efficacité du code.



Ces jours sont révolus.



Avec l'essor des langages de plus haut niveau tels que Java, Ruby, PHP et Javascript, la programmation est devenue plus abstraite en 1995 lorsque Wirth a écrit son article. Les nouveaux langages ont rendu la programmation beaucoup plus facile et ont pris beaucoup de choses. Ils étaient orientés objet et étaient fournis avec des éléments tels que les IDE et le ramasse-miettes.



C'est devenu plus facile pour les programmeurs de vivre, mais tout doit payer. Plus il est facile de vivre, moins il faut penser. Vers le milieu des années 90, les programmeurs ont cessé de penser à la qualité de leurs programmes, écrit le développeur Robin Martin dans son article «Niklaus Wirth avait raison, et c'est le problème» . Dans le même temps, une utilisation généralisée des bibliothèques a commencé, dont la fonctionnalité est toujours bien plus que nécessaire pour un programme spécifique.



Étant donné que la bibliothèque n'est pas conçue pour un projet particulier, elle a probablement un peu plus de fonctionnalités que ce dont elle a vraiment besoin. Pas de problème, dites-vous. Cependant, les choses s'additionnent assez rapidement. Même les gens qui aiment les bibliothèques ne veulent pas réinventer la roue. Cela conduit à ce qu'on appelle l'enfer de la dépendance. Nicola Duza a écrit un article sur ce problème en Javascript .



Le problème ne semble pas grave, mais en réalité, il est plus grave que vous ne le pensez. Par exemple, Nikola Dusa a écrit une application simple de liste de tâches. Cela fonctionne dans votre navigateur avec HTML et Javascript. Combien de dépendances pensez-vous qu'il a utilisé? 13 000. Treize. Mille. Preuve .



Les chiffres sont insensés, mais le problème ne fera que croître. À mesure que de nouvelles bibliothèques sont créées, le nombre de dépendances dans chaque projet augmentera également.



Cela signifie que le problème dont Niklaus Wirth avait mis en garde en 1995 ne fera qu'empirer avec le temps.



Que faire?



Robin Martin suggère qu'une bonne façon de commencer est de diviser les bibliothèques. Au lieu de créer une seule grande bibliothèque qui fasse de son mieux, créez simplement plusieurs bibliothèques.



Ainsi, le programmeur n'a qu'à sélectionner les bibliothèques dont il a réellement besoin, ignorant les fonctionnalités qu'il n'utilisera pas. Non seulement il installe moins de dépendances, mais les bibliothèques utilisées auront également moins de dépendances.

Fin de la loi de Moore

Malheureusement, la miniaturisation des transistors ne peut pas durer éternellement et a ses limites physiques. Peut-être que tôt ou tard la loi de Moore cessera de fonctionner. Certains disent que cela s'est déjà produit. Au cours des dix dernières années, la vitesse d'horloge et la puissance des cœurs de processeur individuels ont déjà cessé de croître comme avant.



Bien qu'il soit trop tôt pour l'enterrer. Il existe un certain nombre de nouvelles technologies qui promettent de remplacer la microélectronique au silicium. Par exemple, Intel, Samsung et d'autres sociétés expérimentent des transistors à base de nanostructures de carbone (nanofils) , ainsi que des puces photoniques.





Evolution des transistors. Illustration: Samsung



Mais certains chercheurs adoptent une approche différente. Ils proposent de nouvelles approches de programmation de systèmes pour améliorer considérablement l'efficacité des futurs logiciels. Ainsi, il est possible de «relancer» la loi de Moore par programme, aussi fantastique que cela puisse paraître à la lumière des observations de Nicklaus Wirth sur l'obésité dans les programmes. Mais que se passerait-il si nous pouvions inverser cette tendance?

Techniques d'accélération logicielle

Récemment, Science a publié un article intéressant rédigé par des scientifiques du laboratoire d'informatique et d'intelligence artificielle du Massachusetts Institute of Technology (CSAIL MIT). Ils mettent en évidence trois domaines prioritaires pour accélérer encore le calcul:

• le meilleur logiciel;
  
  
• nouveaux algorithmes;
  
  
• matériel plus optimisé.

L'auteur principal du travail scientifique Charles Leiserson confirme l'obésité de la thèse des logiciels . Il dit que les avantages de la miniaturisation des transistors ont été si grands que pendant des décennies, les programmeurs ont pu donner la priorité à rendre le code plus facile à écrire plutôt qu'à accélérer l'exécution. L'inefficacité pourrait être tolérée car des puces informatiques plus rapides compensaient toujours l'obésité logicielle.



«Mais de nos jours, de nouvelles avancées dans des domaines tels que l'apprentissage automatique, la robotique et la réalité virtuelle exigeront une énorme puissance de calcul que la miniaturisation ne peut plus fournir», déclare Leiserson. "Si nous voulons exploiter le plein potentiel de ces technologies, nous devons changer notre approche de l'informatique."



Dans la partie logicielle, il est proposé de reconsidérer la stratégie d'utilisation de bibliothèques avec des fonctionnalités excessives, car c'est une source d'inefficacité. Les auteurs recommandent de se concentrer sur la tâche principale - augmenter la vitesse d'exécution du programme, et non sur la vitesse d'écriture du code.



Dans de nombreux cas, les performances peuvent en effet être augmentées des milliers de fois, et ce n'est pas une exagération. A titre d'exemple, les chercheurs citent la multiplication de deux matrices 4096 × 4096. Ils ont commencé par l'implémentation en Python comme l'un des langages de haut niveau les plus populaires. Par exemple, voici une implémentation sur quatre lignes dans Python 2:

for i in xrange(4096):
for j in xrange(4096):
for k in xrange(4096):
C[i][j] += A[i][k] * B[k][j]

Le code comporte trois boucles imbriquées et l'algorithme de solution est basé sur le programme d'algèbre scolaire.



Mais il s'avère que cette approche naïve est trop inefficace pour la puissance de calcul. Sur un ordinateur moderne, il fonctionnera pendant environ sept heures, comme indiqué dans le tableau ci-dessous.





Le passage à un langage de programmation plus efficace augmente déjà considérablement la vitesse d'exécution du code. Par exemple, un programme Java s'exécutera 10,8 fois plus vite, tandis qu'un programme C s'exécutera 4,4 fois plus vite que Java. Ainsi, passer de Python à C signifie une exécution du programme 47 fois plus rapide.



Et ce n'est que le début de l'optimisation. Si vous écrivez le code en tenant compte des particularités du matériel sur lequel il sera exécuté, vous pouvez augmenter la vitesse de 1300 fois. Dans cette expérience, le code a d'abord été exécuté en parallèle sur les 18 cœurs de processeur (version 4), puis a utilisé la hiérarchie du cache du processeur (version 5), ajouté la vectorisation (version 6) et appliqué des instructions spécifiques Advanced Vector Extensions (AVX) dans la version 7. Dernière version optimisée le code ne prend que 0,41 seconde, pas 7 heures, c'est-à-dire plus de 60 000 fois plus vite que le code Python d'origine.



De plus, sur une carte graphique AMD FirePro S9150, le même code s'exécute en seulement 70 ms, 5,4 fois plus rapide que la version 7 la plus optimisée sur un processeur polyvalent et 360000 fois plus rapide que la version 1.



En termes d'algorithmes, les chercheurs proposent une approche en trois volets qui consiste à explorer de nouveaux domaines problématiques, à mettre à l'échelle les algorithmes et à les adapter pour mieux tirer parti du matériel moderne.



Par exemple, l'algorithme de Strassen pour la multiplication matricielle d'un autre 10% accélère la version la plus rapide du numéro de code 7. Pour d'autres problèmes, les nouveaux algorithmes offrent encore plus de gains de performances. Par exemple, le diagramme suivant montre les progrès réalisés dans l'efficacité des algorithmes pour résoudre le problème de débit maximal entre 1975 et 2015. Chaque nouvel algorithme augmentait la vitesse de calcul de plusieurs ordres de grandeur et, les années suivantes, il était encore optimisé.





Efficacité des algorithmes pour résoudre le problème du débit maximum sur un graphe à n = 10 ¹² sommets et m = n ¹¹ arêtes



Ainsi, l'amélioration des algorithmes contribue également à "émuler" la loi de Moore par programmation.



Enfin, en termes d'architecture matérielle, les chercheurs préconisent d'optimiser le matériel afin que les problèmes puissent être résolus avec moins de transistors. L'optimisation passe par l'utilisation de processeurs plus simples et la création de matériel adapté à des applications spécifiques, comme un GPU est adapté pour l'infographie.



«Les équipements adaptés à des domaines spécifiques peuvent être beaucoup plus efficaces et utiliser beaucoup moins de transistors, ce qui permet aux applications de fonctionner des dizaines ou des centaines de fois plus vite», déclare Tao Schardl, co-auteur du document de recherche. "Plus généralement, l'optimisation matérielle stimulera davantage la programmation parallèle en créant des zones supplémentaires sur la puce pour une utilisation parallèle."



La tendance à la parallélisation est déjà visible. Comme le montre le diagramme, ces dernières années, les performances du processeur ont augmenté uniquement en raison de l'augmentation du nombre de cœurs.





Performances SPECint des cœurs individuels et des processeurs monocœurs et multicœurs de 1985 à 2015. L'unité de base est un microprocesseur 1985 80386 DX



Pour les opérateurs de datacenters, même la plus petite amélioration des performances logicielles peut se traduire par des gains financiers importants. Sans surprise, des entreprises telles que Google et Amazon mènent désormais des initiatives pour développer leurs propres processeurs spécialisés. Les premiers processeurs tenseur (neuronaux) Google TPU et les puces AWS Graviton fonctionnent dans les centres de données Amazon .



Au fil du temps, les leaders de l'industrie peuvent être suivis par les propriétaires d'autres centres de données, afin de ne pas perdre en efficacité face à des concurrents.



Les chercheurs écrivent que dans le passé, les gains de performances explosifs dans les processeurs à usage général ont limité la portée du développement de processeurs spécialisés. Maintenant, il n'y a pas de telle limitation.



«Les gains de productivité nécessiteront de nouveaux outils, langages de programmation et matériel pour permettre une conception plus efficace en gardant à l'esprit la vitesse», a déclaré le professeur Charles Leiserson, co-auteur de la recherche. "Cela signifie également que les programmeurs doivent mieux comprendre comment les logiciels, les algorithmes et le matériel s'articulent, plutôt que de les examiner de manière isolée."



D'autre part, les ingénieurs expérimentent des technologies qui peuvent encore améliorer les performances du processeur. Il s'agit de l'informatique quantique, de la disposition 3D, des microcircuits supraconducteurs, du calcul neuromorphique, de l'utilisation du graphène au lieu du silicium, etc. Mais jusqu'à présent, ces technologies sont au stade d'expérimentation.



Si les performances du processeur cessent vraiment de croître, nous nous retrouverons dans une réalité complètement différente. Peut-être que nous devons vraiment reconsidérer nos priorités de programmation, et les spécialistes de l'assemblage valent leur pesant d'or.

---

La publicité

Besoin d'un serveur puissant ? Notre société propose des serveurs épiques - des serveurs virtuels avec processeur AMD EPYC, fréquence centrale du processeur jusqu'à 3,4 GHz. La configuration maximale impressionnera tout le monde - 128 cœurs de processeur, 512 Go de RAM, 4000 Go de NVMe.