Ordinateurs modernes pour la supply chain - Cours 4.1

00:17 Introduction
03:35 Ordres de grandeur
06:55 Étapes de l’optimisation de la supply chain
12:17 Les courbes en S du matériel
15:52 L’histoire jusqu’à présent
17:34 Sciences auxiliaires
20:25 Ordinateurs modernes
20:57 Latence 1/2
27:15 Latence 2/2
30:37 Calcul, vitesse d’horloge
36:36 Calcul, pipelining, 1/3
39:11 Calcul, pipelining, 2/3
40:27 Calcul, pipelining, 3/3
46:36 Calcul, superscalar 1/2
49:55 Calcul, superscalar 2/2
56:45 Mémoire 1/3
01:00:42 Mémoire 2/3
01:06:43 Mémoire 3/3
01:11:13 Stockage des données 1/2
01:14:06 Stockage des données 2/2
01:18:36 Bande passante
01:23:20 Conclusion
01:27:33 Prochain cours et questions du public

Description

Les chaînes d’approvisionnement modernes nécessitent des ressources informatiques pour fonctionner, tout comme les convoyeurs motorisés nécessitent de l’électricité. Pourtant, les systèmes de chaîne d’approvisionnement lents restent omniprésents, alors que la puissance de traitement des ordinateurs a été multipliée par plus de 10 000 depuis 1990. Une méconnaissance des caractéristiques fondamentales des ressources informatiques modernes - même parmi les cercles informatiques ou de data science - explique en grande partie cet état de fait. La conception logicielle sous-jacente des recettes numériques ne devrait pas s’opposer au substrat informatique sous-jacent.

Transcription complète

Bienvenue dans cette série de cours sur la chaîne d’approvisionnement. Je suis Joannes Vermorel et aujourd’hui je vais présenter “Les ordinateurs modernes pour la chaîne d’approvisionnement”. Les chaînes d’approvisionnement occidentales ont été numérisées depuis longtemps, parfois il y a jusqu’à trois décennies. Les décisions basées sur l’informatique sont partout et les recettes numériques associées portent différents noms tels que les points de réapprovisionnement, les stocks min-max, et les stocks de sécurité, avec différents degrés de supervision humaine.

Néanmoins, si nous regardons les grandes entreprises qui exploitent des chaînes d’approvisionnement de taille équivalente, nous constatons des millions de décisions essentiellement pilotées par ordinateur, qui influencent les performances de la chaîne d’approvisionnement. Ainsi, lorsqu’il s’agit d’améliorer les performances de la chaîne d’approvisionnement, cela se résume rapidement à l’amélioration des recettes numériques qui pilotent la chaîne d’approvisionnement. Ici, invariablement, lorsque nous commençons à envisager des recettes numériques supérieures de quelque nature que ce soit, où nous voulons de meilleurs modèles et des prévisions plus précises, ces recettes supérieures finissent par coûter beaucoup plus de ressources informatiques.

Les ressources informatiques ont été un défi pour la chaîne d’approvisionnement car elles coûtent beaucoup d’argent, et il y a toujours la prochaine étape de l’évolution pour le prochain modèle ou le prochain système de prévision qui nécessite dix fois plus de ressources informatiques que le précédent. Oui, cela pourrait apporter des performances supplémentaires à la chaîne d’approvisionnement, mais cela s’accompagne d’un coût informatique accru. Au cours des dernières décennies, le matériel informatique a progressé énormément, mais comme nous le verrons aujourd’hui, ce progrès, bien qu’il soit toujours en cours, est souvent contrarié par les logiciels d’entreprise. En conséquence, les logiciels ne deviennent pas plus rapides avec un matériel plus moderne ; au contraire, ils peuvent très souvent devenir plus lents.

L’objectif de cette conférence est d’inculquer au public une certaine sympathie mécanique, afin que vous puissiez évaluer si un logiciel d’entreprise censé mettre en œuvre des recettes numériques destinées à fournir de meilleures performances de la chaîne d’approvisionnement intègre le matériel informatique tel qu’il existe déjà et tel qu’il existera dans une décennie, ou s’il s’y oppose et ne tire donc pas le meilleur parti du matériel informatique que nous avons aujourd’hui.

L’un des aspects les plus déconcertants des ordinateurs modernes est l’éventail d’ordres de grandeur impliqués. Du point de vue de la chaîne d’approvisionnement, nous avons généralement environ cinq ordres de grandeur, et c’est déjà une estimation optimiste ; en réalité, c’est souvent moins. Cinq ordres de grandeur signifient que nous pouvons passer d’une unité à 100 000 unités. Rappelez-vous que j’ai déjà abordé la loi des petits nombres dans des conférences précédentes. Si vous avez un grand nombre d’unités, vous ne les traiterez pas individuellement ; vous les regrouperez dans des boîtes, ce qui vous laissera un nombre beaucoup plus réduit de boîtes. De même, si vous avez beaucoup de boîtes, vous les regrouperez sur des palettes, etc., de sorte que vous aurez un nombre beaucoup plus réduit de palettes. Les économies d’échelle induisent des prévisions de quantités, et du point de vue de la chaîne d’approvisionnement, une inefficacité de 10 % est déjà considérée comme assez significative.

Dans le domaine des ordinateurs, c’est très différent ; nous avons affaire à 15 ordres de grandeur, ce qui est absolument gigantesque. Passer d’une unité à un million de milliards d’unités est un nombre si grand qu’il est en réalité très difficile à visualiser. Nous passons d’un octet, qui ne représente que huit bits et peut être utilisé pour représenter une lettre ou un chiffre, à un pétaoctet, qui équivaut à un million de gigaoctets. Un pétaoctet représente à peu près l’ordre de grandeur de la quantité de données que Lokad gère actuellement, et les grandes entreprises qui exploitent de vastes chaînes d’approvisionnement gèrent également des ensembles de données de l’ordre du pétaoctet.

Nous passons d’une opération en virgule flottante par seconde (FLOP) à un petaFLOP, qui équivaut à un million de gigaFLOPS. Ces ordres de grandeur sont absolument gigantesques et très trompeurs. Par conséquent, dans le domaine de la chaîne d’approvisionnement, où une inefficacité de 10 % est considérée comme inefficace, ce qui se passe généralement dans le domaine des ordinateurs, ce n’est pas une inefficacité de 10 %, mais plutôt une inefficacité multipliée par 10, voire plusieurs ordres de grandeur. Ainsi, si vous faites quelque chose de mal en termes de performance dans le domaine des ordinateurs, votre pénalité ne sera pas de 10 % ; au contraire, votre système sera 10 fois plus lent qu’il ne devrait l’être, voire 100 fois, voire même 1 000 fois plus lent. C’est vraiment ce qui est en jeu : avoir une véritable alignement, qui nécessite une certaine sympathie mécanique entre le logiciel d’entreprise et le matériel informatique sous-jacent.

Lorsque l’on considère une recette numérique censée fournir une performance supérieure de la chaîne d’approvisionnement, il existe un ensemble d’étapes de maturité qui sont intéressantes conceptuellement. Évidemment, cela peut varier en pratique, mais c’est généralement ce que nous avons identifié chez Lokad. Ces étapes peuvent être résumées comme suit : faire en sorte que cela fonctionne, faire en sorte que cela soit correct, faire en sorte que cela soit rapide et faire en sorte que cela soit bon marché.

“Faire en sorte que cela fonctionne” consiste à évaluer si une recette numérique prototype fournit réellement les résultats escomptés, tels que des taux de service plus élevés, moins de stocks morts, une meilleure utilisation des actifs ou tout autre objectif digne d’intérêt du point de vue de la chaîne d’approvisionnement. L’objectif est de s’assurer d’abord que la nouvelle recette numérique fonctionne réellement à la première étape de maturité.

Ensuite, vous devez “faire en sorte que cela soit correct”. Du point de vue de la chaîne d’approvisionnement, cela signifie transformer ce qui était essentiellement un prototype unique en quelque chose de qualité industrielle. Cela implique généralement d’attacher à la recette numérique un certain degré de correction par conception. Les chaînes d’approvisionnement sont vastes, complexes et, surtout, très désordonnées. Si vous avez une recette numérique très fragile, même si la méthode numérique est bonne, il est très facile de se tromper, et vous finissez par créer beaucoup plus de problèmes par rapport aux avantages que vous souhaitiez apporter en premier lieu. Ce n’est pas une proposition gagnante. Faire en sorte que cela soit correct, c’est s’assurer que vous avez quelque chose qui peut être déployé à grande échelle avec un minimum de friction. Ensuite, vous voulez rendre cette recette numérique rapide, et quand je dis rapide, je veux dire rapide en termes de temps réel. Lorsque vous lancez le calcul, vous devez obtenir les résultats en quelques minutes, ou peut-être une heure ou deux au maximum, mais pas plus longtemps. Les chaînes d’approvisionnement sont désordonnées, et il y aura un moment dans l’histoire de votre entreprise où il y aura des perturbations, telles que des navires porte-conteneurs bloqués au milieu du canal de Suez, une pandémie ou un entrepôt inondé. Lorsque cela se produit, vous devez être capable de réagir rapidement. Je ne dis pas réagir dans les prochaines millisecondes, mais si vous avez des recettes numériques qui prennent des jours pour se terminer, cela crée une friction opérationnelle massive. Vous avez besoin de choses qui peuvent être exploitées dans un court laps de temps humain, donc cela doit être rapide.

Rappelez-vous, les logiciels d’entreprise modernes fonctionnent sur des clouds, et vous pouvez toujours payer pour plus de ressources informatiques sur des plateformes de cloud computing. Ainsi, votre logiciel peut réellement être rapide simplement parce que vous louez beaucoup de puissance de traitement. Ce n’est pas que le logiciel lui-même doit être correctement conçu pour tirer parti de toute la puissance de traitement qu’un cloud peut fournir, mais il peut être rapide et très inefficace simplement parce que vous louez autant de puissance de traitement auprès de votre fournisseur de cloud computing.

L’étape suivante consiste à rendre la méthode bon marché, c’est-à-dire qu’elle n’utilise pas trop de ressources informatiques du cloud. Si vous n’entrez pas dans cette dernière étape, cela signifie que vous ne pourrez jamais améliorer votre méthode. Si vous avez une méthode qui fonctionne, qui est correcte et qui est rapide mais qui consomme beaucoup de ressources, lorsque vous voulez passer à l’étape suivante de la recette numérique, qui impliquera inévitablement quelque chose qui coûte encore plus de ressources informatiques que ce que vous utilisez actuellement, vous serez bloqué. Vous devez rendre la méthode que vous avez super légère afin de pouvoir commencer à expérimenter avec des recettes numériques moins efficaces que ce que vous avez actuellement.

Cette dernière étape est celle où vous devez vraiment adopter le matériel sous-jacent disponible dans les ordinateurs modernes. Vous pouvez vous en sortir avec les trois premières étapes sans trop d’affinité, mais la dernière est essentielle. Rappelez-vous, si vous n’atteignez pas l’étape “faire en sorte que cela soit bon marché”, vous ne pourrez pas itérer, et vous serez donc bloqué. C’est pourquoi, même si c’est la dernière étape, c’est un jeu itératif, et il est essentiel de passer par toutes les étapes si vous voulez itérer de manière répétée.

Le matériel informatique progresse, et cela ressemble à une progression exponentielle, mais la réalité est que cette progression exponentielle du matériel informatique est en réalité composée de milliers de courbes en S. Une courbe en S est une courbe où vous introduisez une nouvelle conception, un nouveau processus, un nouveau matériau ou une nouvelle architecture, et initialement, ce n’est pas vraiment mieux que ce que vous aviez avant. Ensuite, l’effet de l’innovation prévue entre en jeu, et vous avez une montée en puissance, suivie d’un plateau après avoir consommé tous les avantages de l’innovation. Les courbes en S qui atteignent un plateau sont caractéristiques des progrès dans le matériel informatique, qui est composé de milliers de ces courbes. Du point de vue d’un profane, cela apparaît comme une croissance exponentielle. Cependant, les experts voient les courbes en S individuelles atteindre un plateau, ce qui peut conduire à une vision pessimiste. Même les experts ne voient pas toujours l’émergence de nouvelles courbes en S qui surprennent tout le monde et continuent la croissance exponentielle du progrès.

Bien que le matériel informatique continue de progresser, le rythme de progression est loin de ce que nous avons connu dans les années 1980 ou 1990. Le rythme est maintenant beaucoup plus lent et assez prévisible, en grande partie en raison des investissements massifs nécessaires pour construire de nouvelles usines de production de matériel informatique. Ces investissements s’élèvent souvent à des centaines de millions de dollars, offrant une visibilité sur cinq à dix ans. Bien que le progrès ait ralenti, nous avons toujours une vision assez précise de ce qui se passera en termes de progrès du matériel informatique au cours de la prochaine décennie.

La leçon pour les logiciels d’entreprise qui mettent en œuvre des recettes numériques est que vous ne pouvez pas vous attendre passivement à ce que le matériel futur améliore tout pour vous. Le matériel continue de progresser, mais capturer ce progrès nécessite des efforts du côté logiciel. Vous pourrez faire plus avec le matériel qui existera dans une décennie, mais seulement si l’architecture au cœur de votre logiciel d’entreprise adopte le matériel informatique sous-jacent. Sinon, vous pourriez en fait faire pire que ce que vous faites aujourd’hui, une proposition qui n’est pas aussi déraisonnable qu’elle en a l’air.

Cette conférence est la première du quatrième chapitre de cette série de conférences sur la supply chain. Je n’ai pas encore terminé le troisième chapitre sur les personae de la supply chain. Dans les conférences suivantes, je vais probablement alterner entre le chapitre actuel, où je traite des sciences auxiliaires de la supply chain, et le troisième chapitre sur les personae de la supply chain.

Dans le tout premier chapitre du prologue, j’ai présenté mes points de vue sur la supply chain en tant que domaine d’étude et pratique. Nous avons vu que la supply chain est essentiellement une collection de problèmes complexes, par opposition aux problèmes simples, en proie à des comportements adverses et à des jeux de concurrence. Par conséquent, nous devons accorder une grande attention à la méthodologie, car les méthodologies directes naïves fonctionnent mal dans ce domaine. C’est pourquoi le deuxième chapitre était consacré à la méthodologie nécessaire pour étudier les supply chains et établir des pratiques pour les améliorer au fil du temps.

Le troisième chapitre, Personae de la Supply Chain, était axé sur la caractérisation des problèmes de la supply chain eux-mêmes, avec pour devise “tomber amoureux du problème, pas de la solution”. Le quatrième chapitre que nous ouvrons aujourd’hui concerne les sciences auxiliaires des supply chains.

Les sciences auxiliaires sont des disciplines qui soutiennent l’étude d’une autre discipline. Il n’y a pas de jugement de valeur ; il ne s’agit pas de dire qu’une discipline est supérieure à une autre. Par exemple, la médecine n’est pas supérieure à la biologie, mais la biologie est une science auxiliaire de la médecine. La perspective des sciences auxiliaires est bien établie et prédominante dans de nombreux domaines de recherche, tels que les sciences médicales et l’histoire.

Dans les sciences médicales, les sciences auxiliaires comprennent la biologie, la chimie, la physique et la sociologie, entre autres. Un médecin moderne ne serait pas considéré comme compétent s’il n’avait aucune connaissance en physique. Par exemple, comprendre les bases de la physique est nécessaire pour interpréter une image radiographique. Il en va de même pour l’histoire, qui compte une longue série de sciences auxiliaires.

En ce qui concerne la supply chain, l’une de mes plus grandes critiques à l’égard des matériaux, des cours, des livres et des articles typiques sur la supply chain est qu’ils traitent du sujet sans approfondir les sciences auxiliaires. Ils traitent la supply chain comme s’il s’agissait d’une connaissance isolée et autonome. Cependant, je pense que la pratique moderne de la supply chain ne peut être réalisée qu’en exploitant pleinement les sciences auxiliaires des supply chains. L’une de ces sciences auxiliaires, et l’objet de la conférence d’aujourd’hui, est le matériel informatique.

Cette conférence n’est pas strictement une conférence sur la supply chain, mais plutôt sur le matériel informatique avec des applications en supply chain à l’esprit. Je pense qu’il est fondamental de pratiquer la supply chain de manière moderne, par opposition à ce qui se faisait il y a un siècle.

Jetons un coup d’œil aux ordinateurs modernes. Dans cette conférence, nous examinerons ce qu’ils peuvent apporter à la supply chain, en mettant particulièrement l’accent sur les aspects qui ont un impact massif sur les performances des logiciels d’entreprise. Nous passerons en revue la latence, le calcul, la mémoire, le stockage des données et la bande passante.

La vitesse de la lumière est d’environ 30 centimètres par nanoseconde, ce qui est relativement lent. Si l’on considère la distance caractéristique d’intérêt pour un processeur moderne qui fonctionne à 5 gigahertz (5 milliards d’opérations par seconde), la distance aller-retour que la lumière peut parcourir en 0,2 nanoseconde n’est que de 3 centimètres. Cela signifie que, en raison de la limitation de la vitesse de la lumière, les interactions ne peuvent pas se produire au-delà de 3 centimètres. Il s’agit d’une limitation stricte imposée par les lois de la physique, et il n’est pas clair si nous pourrons jamais la surmonter.

La latence est une contrainte extrêmement difficile. Du point de vue de la supply chain, nous avons au moins deux distributions de matériel informatique impliquées. Lorsque je parle de matériel informatique distribué, je veux dire du matériel informatique qui implique de nombreux appareils qui ne peuvent pas occuper le même espace physique. Évidemment, vous devez les maintenir à distance les uns des autres simplement parce qu’ils ont leurs propres dimensions. Cependant, la première raison pour laquelle nous avons besoin d’une informatique distribuée est la nature des supply chains, qui sont géographiquement distribuées. Par conception, les supply chains sont réparties sur des géographies, et donc, il y aura également du matériel informatique réparti sur ces géographies. Du point de vue de la vitesse de la lumière, même si vous avez des appareils qui ne sont qu’à trois mètres l’un de l’autre, c’est déjà très lent car cela prend 100 cycles d’horloge pour faire l’aller-retour. Trois mètres est une distance assez importante du point de vue de la vitesse de la lumière et de la fréquence d’horloge des processeurs modernes.

Un autre type de distribution est l’évolutivité horizontale. La manière moderne d’avoir plus de puissance de traitement à notre disposition n’est pas d’avoir un appareil informatique 10 fois ou un million de fois plus puissant ; ce n’est pas ainsi que cela est conçu. Si vous voulez plus de ressources de traitement, vous avez besoin de dispositifs informatiques supplémentaires, de plus de processeurs, de plus de puces mémoire et de plus de disques durs. C’est en empilant le matériel que vous pouvez avoir plus de ressources de calcul à votre disposition. Cependant, tous ces appareils prennent de l’espace, et donc, vous finissez par distribuer votre matériel informatique simplement parce que vous ne pouvez pas le centraliser dans un ordinateur d’un centimètre de large.

En ce qui concerne les latences, en examinant les sortes de latences que nous avons sur Internet professionnel (les latences que vous pouvez obtenir dans un centre de données, pas sur votre Wi-Fi à la maison), nous sommes déjà à moins de 30% de la vitesse de la lumière. Par exemple, la latence entre un centre de données près de Paris, en France, et New York, aux États-Unis, est seulement à moins de 30% de la vitesse de la lumière. C’est une réalisation incroyable pour l’humanité ; l’information circule sur Internet presque à la vitesse de la lumière. Oui, il y a encore de la place pour l’amélioration, mais nous sommes déjà proches des limites strictes imposées par la physique.

En conséquence, il y a même des entreprises maintenant qui veulent poser des câbles à travers le plancher de la mer Arctique pour relier Londres à Tokyo avec un câble qui passerait sous le pôle Nord, juste pour gagner quelques millisecondes de latence pour les transactions financières. Fondamentalement, la latence et la vitesse de la lumière sont des préoccupations très réelles, et l’Internet que nous avons est essentiellement aussi bon qu’il le sera jamais à moins qu’il n’y ait des percées en physique. Cependant, nous n’avons rien de tel qui se profile à l’horizon pour la prochaine décennie.

Étant donné que la latence est un problème extrêmement difficile, les implications pour les logiciels d’entreprise sont importantes. Les allers-retours en termes de flux d’informations sont mortels, et les performances de votre logiciel d’entreprise dépendront largement du nombre d’allers-retours entre les différents sous-systèmes qui existent au sein de votre logiciel. Le nombre d’allers-retours caractérisera la latence incompressible que vous subissez. Minimiser les allers-retours et améliorer les latences est, pour la plupart des logiciels d’entreprise, y compris ceux dédiés à l’optimisation prédictive des supply chains, le problème numéro un. Atténuer les latences équivaut souvent à offrir de meilleures performances.

Une astuce intéressante, bien que ce ne soit pas quelque chose que tout le monde dans cette audience déploiera en production, consiste à aborder les complications introduites par la latence. Le temps lui-même devient insaisissable et flou lorsque vous entrez dans le domaine des calculs à la nanoseconde. Il est difficile de trouver des horloges précises dans le calcul distribué, et leur absence introduit des complications au sein des logiciels d’entreprise distribués. De nombreux allers-retours sont nécessaires pour synchroniser les différentes parties du système. En raison de l’absence d’une horloge précise, vous vous retrouvez avec des alternatives algorithmiques telles que les horloges vectorielles ou les horodatages multipartites, qui sont des structures de données qui reflètent un ordre partiel des horloges des appareils de votre système. Ces allers-retours supplémentaires peuvent nuire aux performances.

Un design astucieux adopté par Google il y a plus d’une décennie consistait à utiliser des horloges atomiques à l’échelle des puces. La résolution de ces horloges atomiques est nettement meilleure que celle des horloges à quartz que l’on trouve dans les montres électroniques ou les ordinateurs. Le NIST a démontré une nouvelle configuration d’horloge atomique à l’échelle des puces avec une dérive quotidienne encore plus précise. Google a utilisé des horloges atomiques internes pour synchroniser les différentes parties de leur base de données SQL distribuée à l’échelle mondiale, Google Spanner, afin d’économiser des allers-retours et d’améliorer les performances à l’échelle mondiale. C’est une façon de contourner la latence grâce à des mesures de temps très précises.

En regardant dix ans plus tard, Google ne sera probablement pas la dernière entreprise à utiliser ce genre d’astuce astucieuse, et elles sont relativement abordables, avec des horloges atomiques à l’échelle des puces coûtant environ 1 500 dollars pièce.

Maintenant, jetons un coup d’œil au calcul, qui consiste à effectuer des calculs avec un ordinateur. La vitesse d’horloge était l’ingrédient magique de l’amélioration pendant les années 80 et 90. En effet, si vous pouviez doubler la vitesse d’horloge de votre ordinateur dans l’ensemble, vous doubleriez efficacement les performances de votre ordinateur, quelle que soit la nature du logiciel impliqué. Tous les logiciels seraient plus rapides de manière linéaire en fonction de la vitesse d’horloge. Il est extrêmement intéressant d’augmenter la vitesse d’horloge, et elle s’améliore toujours, bien que l’amélioration se soit aplatie au fil du temps. Il y a presque 20 ans, la vitesse d’horloge était d’environ 2 GHz, et de nos jours, elle est de 5 GHz.

La raison principale de cette amélioration aplatie est le mur de puissance. Le problème est que lorsque vous augmentez la vitesse d’horloge sur une puce, vous avez tendance à doubler approximativement la consommation d’énergie, puis vous devez dissiper cette énergie. Le problème est la dissipation thermique, car si vous ne pouvez pas dissiper l’énergie, votre appareil accumule de la chaleur jusqu’à endommager l’appareil lui-même. De nos jours, l’industrie des semi-conducteurs est passée de plus d’opérations par seconde à plus d’opérations par watt.

Cette règle d’une augmentation de 30% doublant la consommation d’énergie est une arme à double tranchant. Si vous acceptez de renoncer à un quart de votre puissance de traitement par unité de temps sur le CPU, vous pouvez réellement diviser la consommation d’énergie par deux. Cela est particulièrement intéressant pour les smartphones, où les économies d’énergie sont cruciales, et également pour le cloud computing, où l’un des principaux moteurs de coût est l’énergie elle-même. Pour avoir une puissance de traitement en cloud computing rentable, il ne s’agit pas d’avoir des CPU super rapides, mais plutôt d’avoir des CPU sous-cadencés qui peuvent être aussi lents que 1 GHz, car ils fournissent plus d’opérations par seconde pour votre investissement énergétique.

Le mur de puissance est un tel problème que les architectures de CPU modernes utilisent toutes sortes de stratagèmes astucieux pour le mitiger. Par exemple, les CPU modernes peuvent réguler leur vitesse d’horloge, l’augmentant temporairement pendant une seconde environ avant de la réduire pour dissiper la chaleur. Ils peuvent également exploiter ce qu’on appelle le silicium sombre. L’idée est que si le CPU peut alterner les zones chaudes sur la puce, il est plus facile de dissiper l’énergie par rapport à avoir toujours la même zone active cycle après cycle d’horloge. C’est un ingrédient clé de la conception moderne. Du point de vue des logiciels d’entreprise, cela signifie que vous voulez vraiment pouvoir mettre à l’échelle. Vous voulez pouvoir faire plus avec de nombreux CPU, mais individuellement, ces processeurs seront plus faibles que les précédents que vous aviez. Il ne s’agit pas d’obtenir de meilleurs processeurs au sens où tout est meilleur dans l’ensemble ; il s’agit d’avoir des processeurs qui vous donnent plus d’opérations par watt, et cette tendance se poursuivra.

Peut-être qu’une décennie plus tard, nous atteindrons, avec difficulté, sept ou peut-être huit gigahertz, mais je ne suis même pas sûr que nous y parviendrons. Quand je regarde la vitesse d’horloge en 2021 chez la plupart des fournisseurs de cloud computing, elle est plus alignée sur environ 2 GHz, donc nous en sommes revenus à la vitesse d’horloge que nous avions il y a 20 ans, et c’est la solution la plus rentable.

Atteindre les performances actuelles des CPU a nécessité une série d’innovations clés. Je vais en présenter quelques-unes, en particulier celles qui ont le plus d’impact sur la conception des logiciels d’entreprise. Sur cet écran, ce que vous voyez, c’est le flux d’instructions d’un processeur séquentiel, comme les processeurs étaient essentiellement fabriqués jusqu’au début des années 80. Vous avez une série d’instructions qui s’exécutent du haut du graphique vers le bas, représentant le temps. Chaque instruction passe par une série d’étapes : récupération, décodage, exécution et écriture.

Pendant l’étape de récupération, vous récupérez l’instruction, le registre, récupérez l’instruction suivante, incrémentez le compteur d’instructions et préparez le CPU. Pendant l’étape de décodage, vous décodez l’instruction et émettez le microcode interne, qui est ce que le CPU exécute en interne. L’étape d’exécution consiste à récupérer les entrées pertinentes des registres et à effectuer le calcul réel, et l’étape d’écriture consiste à prendre le résultat que vous venez de calculer et à le placer quelque part dans l’un des registres. Dans ce processeur séquentiel, chaque étape nécessite un cycle d’horloge, il faut donc quatre cycles d’horloge pour exécuter une instruction. Comme nous l’avons vu, il est très difficile d’augmenter la fréquence des cycles d’horloge eux-mêmes en raison de nombreuses complications.

Le truc clé qui est en place depuis le début des années 80 et au-delà est connu sous le nom de pipelining. Le pipelining peut considérablement accélérer le calcul de votre processeur. L’idée est que, étant donné que chaque instruction passe par une série d’étapes, nous allons superposer les étapes, et ainsi le CPU lui-même va avoir tout un pipeline d’instructions. Sur ce diagramme, vous pouvez voir un CPU avec un pipeline de profondeur quatre, où il y a toujours quatre instructions en cours d’exécution simultanément. Cependant, elles ne sont pas dans la même étape : une instruction est dans l’étape de récupération, une dans l’étape de décodage, une dans l’étape d’exécution et une dans l’étape d’écriture. Avec ce simple truc, représenté ici comme un processeur en pipeline, nous avons multiplié les performances effectives du processeur par quatre en ne faisant que mettre en pipeline les opérations. Tous les processeurs modernes utilisent le pipelining.

La prochaine étape de cette amélioration s’appelle le super pipelining. Les processeurs modernes vont bien au-delà du simple pipelining. En réalité, le nombre d’étapes impliquées dans un vrai processeur moderne est plus proche de 30 étapes. Sur le graphique, vous pouvez voir un CPU avec 12 étapes à titre d’exemple, mais en réalité, il serait plus proche de 30 étapes. Avec ce pipeline plus profond, 12 opérations peuvent s’exécuter simultanément, ce qui est très bon pour les performances tout en utilisant toujours le même cycle d’horloge.

Cependant, il y a un nouveau problème : l’instruction suivante commence avant que la précédente ne soit terminée. Cela signifie que si vous avez des opérations qui dépendent les unes des autres, vous avez un problème car le calcul des entrées pour l’instruction suivante n’est pas encore prêt, et vous devez attendre. Nous voulons utiliser l’ensemble du pipeline à notre disposition pour maximiser la puissance de traitement. Ainsi, les processeurs modernes ne récupèrent pas seulement une instruction à la fois, mais quelque chose comme 500 instructions à la fois. Ils regardent loin dans la liste des prochaines instructions et les réorganisent pour atténuer les dépendances, en entrelaçant les flux d’exécution pour tirer parti de la profondeur totale du pipeline.

Il y a beaucoup de choses qui compliquent cette opération, notamment les branches. Une branche est simplement une condition en programmation, comme lorsque vous écrivez une instruction “if”. Le résultat de la condition peut être vrai ou faux, et en fonction du résultat, votre programme exécutera une partie de la logique ou une autre. Cela complique la gestion des dépendances car le CPU doit deviner la direction que vont prendre les branches à venir. Les processeurs modernes utilisent la prédiction de branches, qui implique des heuristiques simples et a une très grande précision de prévision. Ils peuvent prédire la direction des branches avec une précision de plus de 99 %, ce qui est meilleur que ce que la plupart d’entre nous peuvent faire dans un contexte réel de supply chain. Cette précision est nécessaire pour exploiter les pipelines super profonds.

Juste pour vous donner une idée des sortes d’heuristiques utilisées pour la prédiction de branches, une heuristique très simple consiste à dire que la branche ira dans la même direction, dans la même direction, qu’elle a pris la dernière fois. Cette simple heuristique vous donne une précision d’environ 90 %, ce qui est assez bon. Si vous ajoutez une subtilité à cette heuristique, qui est que la branche ira dans la même direction que la dernière fois, mais vous devez tenir compte de l’origine, donc c’est la même branche venant de la même origine, alors vous obtiendrez une précision d’environ 95 %. Les processeurs modernes utilisent en réalité des perceptrons assez complexes, qui est une technique d’apprentissage automatique, pour prédire la direction des branches.

Dans les bonnes conditions, vous pouvez prédire les branches de manière assez précise et ainsi exploiter pleinement le pipeline pour tirer le meilleur parti d’un processeur moderne. Cependant, d’un point de vue de l’ingénierie logicielle, vous devez être gentil avec votre processeur, en particulier avec la prédiction de branches. Si vous n’êtes pas gentil, cela signifie que le prédicteur de branches se trompera, et lorsque cela se produit, le CPU prédira la direction de la branche, organisera le pipeline et commencera à effectuer des calculs à l’avance. Lorsque la branche est réellement rencontrée et que le calcul est effectivement effectué, le CPU se rendra compte que la prédiction de branche était fausse. Une prédiction de branche incorrecte ne donne pas un résultat incorrect ; elle entraîne une perte de performance. Le CPU n’aura d’autre choix que de vider l’intégralité du pipeline, ou une grande partie de celui-ci, d’attendre que d’autres calculs soient effectués, puis de redémarrer le calcul. L’impact sur les performances peut être très significatif, et vous pouvez facilement perdre un ou deux ordres de grandeur de performances en raison de la logique des logiciels d’entreprise qui ne fonctionne pas bien avec la logique de prédiction de branches de votre CPU.

Un autre truc notable au-delà du pipelining est l’instruction superscalaire. Les processeurs traitent généralement des scalaires, ou des paires de scalaires, à la fois - par exemple, deux nombres avec une précision en virgule flottante de 32 bits. Ils effectuent des opérations scalaires, en traitant essentiellement un nombre à la fois. Cependant, les processeurs modernes depuis une décennie ont pratiquement tous une instruction superscalaire, qui peut réellement traiter plusieurs vecteurs de nombres et effectuer des opérations vectorielles directement. Cela signifie qu’un CPU peut prendre un vecteur, disons, de huit nombres en virgule flottante et un deuxième vecteur de huit nombres en virgule flottante, effectuer une addition et obtenir un vecteur de nombres en virgule flottante qui représente les résultats de cette addition. Tout cela est fait en un seul cycle.

Par exemple, des ensembles d’instructions spécialisés comme AVX2 vous permettent d’effectuer des opérations en tenant compte de 32 bits de précision avec des paquets de huit nombres, tandis que AVX512 vous permet de le faire avec des paquets de 16 nombres. Si vous êtes capable d’exploiter ces instructions, cela signifie que vous pouvez littéralement gagner un ordre de grandeur en termes de vitesse de traitement car une instruction, un cycle d’horloge, effectue beaucoup plus de calculs que le traitement des nombres un par un. Ce processus est connu sous le nom de SIMD (Single Instruction, Multiple Data) et il est très puissant. Il a été à l’origine de la majeure partie des progrès réalisés au cours de la dernière décennie en termes de puissance de traitement, et les processeurs modernes sont de plus en plus basés sur des vecteurs et superscalaires. Cependant, d’un point de vue logiciel d’entreprise, c’est relativement délicat. Avec le pipelining, votre logiciel doit être compatible, et peut-être qu’il est compatible avec la prédiction de branchement par accident. Cependant, en ce qui concerne l’instruction superscalaire, il n’y a rien d’accidentel. Votre logiciel doit vraiment faire certaines choses explicitement, la plupart du temps, pour tirer parti de cette puissance de traitement supplémentaire. Vous ne l’obtenez pas gratuitement ; vous devez adopter cette approche, et généralement, vous devez organiser les données elles-mêmes de manière à avoir un parallélisme des données, et les données sont organisées de manière à être adaptées aux instructions SIMD. Ce n’est pas de la rocket science, mais cela n’arrive pas par accident, et cela vous donne un énorme coup de pouce en termes de puissance de traitement.

Maintenant, les processeurs modernes peuvent avoir de nombreux cœurs, et un cœur de processeur peut vous donner un flux distinct d’instructions. Avec les processeurs très modernes qui ont de nombreux cœurs, généralement, les processeurs actuels peuvent atteindre jusqu’à 64 cœurs, soit 64 flux d’exécution concurrents indépendants. Vous pouvez atteindre environ un téraflop, qui est la limite supérieure du débit de traitement que vous pouvez obtenir à partir d’un processeur très moderne. Cependant, si vous voulez aller au-delà, vous pouvez vous tourner vers les GPU (unités de traitement graphique). Contrairement à ce que vous pourriez penser, ces appareils peuvent être utilisés pour des tâches qui n’ont rien à voir avec les graphiques.

Un GPU, comme celui de NVIDIA, est un processeur superscalaire. Au lieu d’avoir jusqu’à 64 cœurs comme les processeurs haut de gamme, les GPU peuvent avoir plus de 10 000 cœurs. Ces cœurs sont beaucoup plus simples et moins puissants ou rapides que les cœurs de CPU classiques, mais il y en a beaucoup plus. Ils portent SIMD à un nouveau niveau, où vous pouvez traiter non seulement des paquets de 8 ou 16 nombres à la fois, mais littéralement des milliers de nombres à la fois pour effectuer des instructions vectorielles. Avec les GPU, vous pouvez atteindre une plage de plus de 30 téraflops sur un seul appareil, ce qui est énorme. Les meilleurs CPU du marché peuvent vous donner un téraflop, tandis que les meilleurs GPU vous donneront plus de 30 téraflops. C’est plus d’un ordre de grandeur de différence, ce qui est très significatif.

Si vous allez encore plus loin, pour des types de calculs spécialisés tels que l’algèbre linéaire (au fait, des choses comme l’apprentissage automatique et l’apprentissage profond sont essentiellement de l’algèbre linéaire impliquant des matrices partout), vous pouvez avoir des processeurs comme les TPUs (Tensor Processing Units). Google a décidé de les nommer Tensors en raison de TensorFlow, mais la réalité est que les TPUs seraient mieux nommés Unités de Traitement de Multiplication de Matrices. La chose intéressante avec la multiplication de matrices est qu’il n’y a pas seulement beaucoup de parallélisme de données impliqué, mais il y a aussi une énorme quantité de répétition impliquée car les opérations sont très répétitives. En organisant un TPU comme un réseau systolique, qui est essentiellement une grille bidimensionnelle avec des unités de calcul sur la grille, vous pouvez franchir la barrière du pétaflop - atteignant plus de 1000 téraflops sur un seul appareil. Cependant, il y a un inconvénient : Google le fait avec des nombres flottants sur 16 bits au lieu des 32 bits habituels. D’un point de vue de la supply chain, une précision de 16 bits n’est pas mauvaise ; cela signifie que vous avez une précision d’environ 0,1% dans vos opérations, et pour de nombreuses opérations d’apprentissage automatique ou statistiques, une précision de 0,1% est tout à fait acceptable si elle est correctement réalisée et sans accumulation de biais.

Ce que nous constatons, c’est que le chemin du progrès en termes de matériel informatique, en ne considérant que le calcul, a été de se tourner vers des appareils de plus en plus spécialisés et rigides. Grâce à cette spécialisation, vous pouvez réaliser d’énormes gains en puissance de traitement. Si vous passez d’une instruction superscalaire, vous gagnez un ordre de grandeur ; si vous optez pour une carte graphique, vous gagnez un ou deux ordres de grandeur ; et si vous optez pour une algèbre linéaire pure, vous gagnez essentiellement deux ordres de grandeur. C’est très significatif.

Au fait, toutes ces conceptions matérielles sont bidimensionnelles. Les puces modernes et les structures de traitement sont très plates. Un CPU moderne ne comporte pas plus de 20 couches, et comme ces couches ne font que quelques microns d’épaisseur, les CPU, GPU ou TPU sont essentiellement des structures plates. Vous pourriez penser : “Et la troisième dimension ?” Eh bien, il s’avère qu’en raison du mur de puissance, qui est le problème de la dissipation de l’énergie, nous ne pouvons pas vraiment passer à la troisième dimension car nous ne savons pas comment évacuer toute l’énergie qui est versée dans le dispositif.

Ce que nous pouvons prédire pour la prochaine décennie, c’est que ces appareils resteront essentiellement bidimensionnels. Du point de vue des logiciels d’entreprise, la plus grande leçon est que vous devez concevoir le parallélisme des données dès le cœur même de votre logiciel. Si vous ne le faites pas, vous ne pourrez pas capturer tout le progrès qui se produit en termes de puissance de calcul brute. Cependant, cela ne peut pas être une réflexion après coup. Cela doit se produire au cœur même de l’architecture, au niveau où vous organisez toutes les données qui doivent être traitées dans vos systèmes. Si vous ne le faites pas, vous serez coincé avec le genre de processeurs que nous avions il y a deux décennies.

Maintenant, dans les années 80, la mémoire était aussi rapide que les processeurs, ce qui signifie qu’un cycle d’horloge était un cycle d’horloge pour la mémoire et un pour le CPU. Cependant, ce n’est plus le cas. Au fil du temps, depuis les années 80, le rapport entre la vitesse de la mémoire et les latences d’accès aux données déjà dans les registres du processeur n’a cessé d’augmenter. Nous avons commencé avec un rapport de un, et nous avons maintenant un rapport généralement supérieur à mille. Ce problème est connu sous le nom de mur de la mémoire, et il n’a cessé d’augmenter au cours des quatre dernières décennies. Il augmente encore de nos jours, bien que très lentement, principalement parce que la vitesse d’horloge des processeurs augmente très lentement. Étant donné que les processeurs ne progressent pas beaucoup en termes de vitesse d’horloge, ce problème du mur de la mémoire n’augmente pas davantage. Cependant, l’endroit où nous nous trouvons actuellement est incroyablement déséquilibré, où l’accès à la mémoire est essentiellement trois ordres de grandeur plus lent que l’accès aux données qui se trouvent déjà commodément à l’intérieur du processeur.

Cette perspective contredit complètement tous les algorithmes classiques tels qu’ils sont encore enseignés de nos jours dans la plupart des universités. Le point de vue algorithmique classique suppose que vous avez un temps uniforme pour accéder à la mémoire, ce qui signifie que l’accès à n’importe quel bit de mémoire prend le même temps. Mais dans les systèmes modernes, ce n’est absolument pas le cas. Le temps nécessaire pour accéder à une certaine partie de la mémoire dépend beaucoup de l’endroit où les données réelles se trouvent physiquement dans votre système informatique.

Du point de vue des logiciels d’entreprise, il s’avère malheureusement que la plupart des conceptions logicielles qui ont été établies pendant les années 80 et 90 ont complètement ignoré le problème, car il était très mineur pendant la première décennie. Il n’a vraiment explosé que ces deux dernières décennies, mais en conséquence, la plupart des modèles observés dans les logiciels d’entreprise actuels s’opposent complètement à cette conception, car ils supposent que vous avez un accès constant à la mémoire.

En passant, si vous commencez à réfléchir aux langages de programmation comme Python (première version publiée en 1989) ou Java (en 1995) qui proposent la programmation orientée objet, cela va à l’encontre du fonctionnement de la mémoire dans les ordinateurs modernes. Chaque fois que vous avez des objets, et c’est encore pire si vous avez des liaisons tardives comme dans Python, cela signifie que pour faire quoi que ce soit, vous devrez suivre des pointeurs et effectuer des sauts aléatoires dans la mémoire. Si l’un de ces sauts est malheureux parce que c’est une partie qui ne se trouve pas déjà dans le processeur, cela peut être mille fois plus lent. C’est un très gros problème.

Pour mieux comprendre l’ampleur du mur de la mémoire, il est intéressant de regarder les latences typiques dans un ordinateur moderne. Si nous redimensionnons ces latences en termes humains, supposons qu’un processeur fonctionne à un cycle d’horloge par seconde. Dans cette hypothèse, la latence typique du CPU serait d’une seconde. Cependant, si nous voulons accéder aux données en mémoire, cela pourrait prendre jusqu’à six minutes. Donc, alors que vous pouvez effectuer une opération par seconde, si vous voulez accéder à quelque chose en mémoire, vous devez attendre six minutes. Et si vous voulez accéder à quelque chose sur le disque, cela peut prendre jusqu’à un mois, voire une année entière. C’est incroyablement long, et c’est de cela que parlent ces ordres de grandeur de performance dont j’ai parlé au tout début de cette conférence. Lorsque vous traitez avec 15 ordres de grandeur, c’est très trompeur ; vous ne réalisez pas nécessairement l’énorme impact sur les performances que vous pouvez avoir, où littéralement vous pouvez finir par devoir attendre l’équivalent humain de plusieurs mois si vous ne placez pas les informations au bon endroit. C’est absolument gigantesque.

En passant, les ingénieurs en logiciel d’entreprise ne sont pas les seuls à lutter contre cette évolution du matériel informatique moderne. Si nous examinons les latences que nous obtenons avec des cartes SSD super rapides, telles que la série Intel Optane, vous pouvez voir que la moitié de la latence pour accéder à la mémoire sur ce périphérique est en fait causée par les surcharges du noyau lui-même, dans ce cas, le noyau Linux. C’est le système d’exploitation lui-même qui génère la moitié de la latence. Qu’est-ce que cela signifie ? Eh bien, cela signifie que même les personnes qui conçoivent Linux ont encore du travail à faire pour rattraper le matériel moderne. Néanmoins, c’est un grand défi pour tout le monde.

Cependant, cela fait vraiment mal aux logiciels d’entreprise, surtout lorsqu’il s’agit d’optimisation de la chaîne d’approvisionnement, en raison du fait que nous avons des tonnes de données à traiter. C’est déjà une tâche assez complexe dès le départ. Du point de vue des logiciels d’entreprise, vous devez vraiment adopter une conception qui fonctionne bien avec le cache car le cache contient des copies locales qui sont plus rapides à accéder et plus proches du CPU.

Le fonctionnement est le suivant : lorsque vous accédez à un octet dans votre mémoire principale, vous ne pouvez pas accéder à un seul octet dans les logiciels modernes. Lorsque vous voulez accéder même à un seul octet dans votre RAM, le matériel va en fait copier 4 kilo-octets, essentiellement toute la page qui fait 4 kilo-octets de taille. L’hypothèse sous-jacente est que lorsque vous commencez à lire un octet, l’octet suivant que vous allez demander sera celui qui suit. C’est le principe de la localité, ce qui signifie que si vous jouez selon la règle et appliquez un accès qui préserve la localité, alors vous pouvez avoir une mémoire qui semble fonctionner presque aussi rapidement que votre processeur.

Cependant, cela nécessite un alignement entre les accès mémoire et la localité des données. En particulier, il existe de nombreux langages de programmation, comme Python, qui ne fournissent pas nativement ce genre de choses. Au contraire, ils posent un défi énorme pour apporter un certain degré de localité. C’est une lutte immense, et finalement, c’est une bataille où vous avez un langage de programmation qui a été conçu autour de modèles qui antagonisent complètement le matériel à notre disposition. Ce problème ne va pas changer dans la décennie à venir ; il ne fera qu’empirer.

Ainsi, d’un point de vue logiciel d’entreprise, vous souhaitez imposer la localité des données mais aussi la minification. Si vous pouvez réduire la taille des données, elles seront plus rapides. C’est quelque chose qui n’est pas très intuitif, mais si vous pouvez réduire la taille des données, généralement en éliminant certaines redondances, vous pouvez rendre votre programme plus rapide car vous serez beaucoup plus agréable avec le cache. Vous pourrez stocker plus de données pertinentes dans les niveaux de cache inférieurs qui ont des latences beaucoup plus faibles, comme le montre cet affichage.

Enfin, parlons spécifiquement du cas de la DRAM. La DRAM est littéralement le composant physique qui constitue la RAM que vous utilisez pour votre poste de travail ou votre serveur dans le cloud. La DRAM est également appelée mémoire principale, qui est constituée de puces DRAM. Au cours de la dernière décennie, en termes de tarification, la DRAM a à peine diminué. Nous sommes passés de 5 $ par gigaoctet à 3 $ par gigaoctet une décennie plus tard. Le prix de la RAM diminue toujours, bien que pas très rapidement. Il stagne au cours des prochaines années, et étant donné qu’il n’y a que trois acteurs majeurs sur ce marché qui ont la capacité de fabriquer de la DRAM à grande échelle, il y a très peu d’espoir qu’il y ait quelque chose d’inattendu sur ce marché dans la décennie à venir.

Mais ce n’est même pas le pire du problème. Il y a aussi la consommation d’énergie par gigaoctet. Si vous regardez la consommation d’énergie, il s’avère que la RAM moderne consomme un peu plus d’énergie par gigaoctet qu’il y a une décennie. La raison est essentiellement que la RAM que nous avons actuellement est plus rapide, et la même règle du mur de puissance s’applique : si vous augmentez la fréquence d’horloge, vous augmentez considérablement la consommation d’énergie. Au fait, la RAM consomme beaucoup d’énergie car la DRAM est fondamentalement un composant actif. Vous devez rafraîchir la RAM en permanence en raison des fuites électriques, donc si vous éteignez votre RAM, vous perdez toutes vos données. Vous devez rafraîchir les cellules en permanence.

Ainsi, la conclusion pour les logiciels d’entreprise est que la DRAM est le seul composant qui ne progresse plus. Il y a des tonnes de choses qui progressent encore très rapidement, comme la puissance de traitement ; cependant, ce n’est pas le cas de la DRAM - elle stagne beaucoup. Si nous prenons en compte la consommation d’énergie, qui représente également une part importante des coûts du cloud computing, la RAM ne progresse pratiquement pas. Par conséquent, si vous adoptez une conception qui met l’accent sur la mémoire principale, et c’est généralement ce que vous obtiendrez lorsque vous avez un fournisseur qui dit : “Oh, nous avons une conception en mémoire pour le logiciel”, souvenez-vous de ces mots-clés.

Chaque fois que vous entendez un fournisseur vous dire qu’il a une conception en mémoire, ce que le fournisseur vous dit - et ce n’est pas une proposition très convaincante - c’est que sa conception repose entièrement sur l’évolution future de la DRAM, où nous savons déjà que les coûts ne vont pas diminuer. Donc, si nous prenons en compte le fait que dans 10 ans, votre supply chain aura probablement environ 10 fois plus de données à traiter simplement parce que les entreprises sont de plus en plus douées pour collecter plus de données au sein de leurs supply chains et pour collaborer afin de collecter plus de données auprès de leurs clients et fournisseurs, il n’est pas déraisonnable de s’attendre à ce qu’une décennie plus tard, toute grande entreprise exploitant une grande supply chain collecte 10 fois plus de données qu’elle ne le fait actuellement. Cependant, le prix par gigaoctet de RAM sera toujours le même. Donc, si vous faites le calcul, vous pourriez vous retrouver avec des coûts de cloud computing ou des coûts informatiques qui sont essentiellement presque d’un ordre de grandeur plus élevé, simplement pour faire à peu près la même chose, simplement parce que vous devez faire face à une masse de données en constante augmentation qui ne rentre pas facilement en mémoire. L’idée clé est que vous voulez vraiment éviter toutes sortes de conceptions en mémoire. Ces conceptions sont très dépassées, et nous verrons dans ce qui suit quelles sont les alternatives que nous avons.

Maintenant, regardons le stockage des données, qui concerne le stockage persistant des données. Essentiellement, il existe deux classes de stockage de données répandues. La première est les disques durs (HDD) ou les disques rotatifs. La deuxième est les disques à semi-conducteurs (SSD). La chose intéressante est que la latence sur les disques rotatifs est terrible, et lorsque vous regardez cette image, vous pouvez facilement comprendre pourquoi. Ces disques tournent littéralement, et lorsque vous voulez accéder à n’importe quel point de données aléatoire sur le disque, en moyenne, vous devez attendre la moitié d’une rotation du disque. Étant donné que les disques haut de gamme tournent à environ 10 000 rotations par minute, cela signifie que vous avez une latence intrinsèque de trois millisecondes qui ne peut pas être compressée. C’est littéralement le temps qu’il faut pour que le disque tourne et pour pouvoir lire le point précis d’intérêt sur le disque. C’est mécanique et ne s’améliorera pas davantage.

Les HDD sont terribles en termes de latence, mais ils ont aussi un autre problème, qui est la consommation d’énergie. En règle générale, un HDD et un SSD consomment tous deux environ trois watts par heure par appareil. C’est généralement le statu quo actuel. Cependant, lorsque le disque dur fonctionne, même si vous ne lisez rien activement à partir du disque dur, vous consommerez trois watts simplement parce que vous devez maintenir le disque en rotation. Atteindre 10 000 rotations par minute prend beaucoup de temps, donc vous devez maintenir le disque en rotation tout le temps, même si vous utilisez le disque très rarement.

En revanche, en ce qui concerne les disques à semi-conducteurs, ils consomment trois watts lorsque vous y accédez, mais lorsque vous n’accédez pas aux données, ils ne consomment presque pas d’énergie. Ils ont une consommation d’énergie résiduelle, mais elle est extrêmement faible, de l’ordre des milliwatts. C’est très intéressant car vous pouvez avoir des tonnes de SSD ; si vous ne les utilisez pas, vous ne payez pas pour l’énergie qu’ils consomment. L’ensemble de l’industrie est progressivement passée des HDD aux SSD au cours de la dernière décennie.

Pour comprendre cela, nous pouvons examiner cette courbe. Ce que nous voyons, c’est que le prix par gigaoctet des HDD et des SSD a diminué au cours des dernières années. Cependant, le prix stagne maintenant. Les données sont un peu anciennes, mais elles n’ont pas beaucoup varié au cours des dernières années. Au cours des 10 dernières années, nous constatons qu’il y a une décennie, les SSD étaient extrêmement chers, à 2 400 dollars par téraoctet, tandis que les disques durs étaient seulement à 60 dollars par téraoctet. Cependant, de nos jours, le prix des disques durs a été divisé par trois, soit environ 20 dollars par téraoctet. Le prix des SSD a été divisé par plus de 25, et la tendance à la baisse des prix des SSD ne s’arrête pas. Les SSD sont actuellement, et probablement pour la décennie à venir, le composant qui progresse le plus, et c’est très intéressant.

Au fait, je vous ai dit que la conception des dispositifs informatiques modernes (CPU, GPU, TPU) était essentiellement bidimensionnelle avec au maximum 20 couches. Cependant, en ce qui concerne les SSD, la conception est de plus en plus tridimensionnelle. Les SSD les plus récents ont environ 176 couches. Nous atteignons, en termes d’ordre, 200 couches. Étant donné que ces couches sont incroyablement fines, il n’est pas déraisonnable de s’attendre à ce qu’à l’avenir, nous ayons des dispositifs avec des milliers de couches et des capacités de stockage potentiellement beaucoup plus importantes. Évidemment, le problème sera que vous ne pourrez pas accéder à toutes ces données tout le temps, encore une fois, en raison du dark silicon et de la dissipation de puissance.

Il s’avère que si vous jouez bien, beaucoup de données sont très rarement consultées. Les SSD impliquent une conception matérielle très spécifique qui présente de nombreuses particularités, telles que le fait que vous ne pouvez allumer les bits mais pas les éteindre. Essentiellement, imaginez que vous ayez initialement que des zéros ; vous pouvez transformer un zéro en un, cependant, vous ne pouvez pas transformer ce un en un zéro localement. Si vous voulez le faire, vous devez réinitialiser tout le bloc qui peut être aussi grand que huit mégaoctets, ce qui signifie que lorsque vous écrivez, vous pouvez transformer des bits de zéro en un, mais pas de un en zéro. Pour transformer des bits de un en zéro, vous devez vider tout le bloc et le réécrire, ce qui entraîne toutes sortes de problèmes connus sous le nom d’amplification d’écriture.

Au cours de la dernière décennie, les disques SSD disposent d’une couche interne appelée couche de traduction flash qui peut atténuer tous ces problèmes. Ces couches de traduction flash s’améliorent de plus en plus avec le temps. Cependant, il existe de grandes opportunités pour améliorer davantage, et en termes de logiciel d’entreprise, cela signifie que vous voulez vraiment optimiser votre conception pour tirer le meilleur parti des SSD. Les SSD sont déjà une bien meilleure affaire que la DRAM en ce qui concerne le stockage de données, et si vous jouez intelligemment, vous pouvez vous attendre, dans une décennie, à des gains d’ordre de grandeur qui seront obtenus grâce aux progrès de l’industrie du matériel, ce qui n’est pas le cas en ce qui concerne la DRAM.

Enfin, parlons de la bande passante. La bande passante est probablement le problème le plus résolu en termes de technologie. Cependant, même si la bande passante peut être atteinte, nous pouvons atteindre des débits absolument fous à la date actuelle. Commercialement, l’industrie des télécommunications est très complexe, et il y a des tonnes de problèmes, de sorte que les consommateurs finaux ne voient pas réellement tous les avantages des progrès qui ont été réalisés en termes de communications optiques.

En ce qui concerne la communication optique avec les émetteurs-récepteurs à fibre optique, les progrès sont absolument fous. C’est probablement l’une de ces choses qui progressent comme les processeurs progressaient dans les années 80 ou 90. Juste pour vous donner une idée, avec la multiplexage par répartition en longueur d’onde (WDM) ou le multiplexage par répartition spatiale (SDM), nous pouvons maintenant atteindre littéralement un dixième de téraoctets de données transférées par seconde sur un seul câble de fibre optique. C’est absolument énorme. Nous atteignons le point où un seul câble peut transporter suffisamment de données pour alimenter essentiellement un centre de données entier. Ce qui est encore plus impressionnant, c’est que l’industrie des télécommunications a été capable de développer de nouveaux émetteurs-récepteurs qui peuvent fournir ces performances absolument incroyables sur la base de câbles anciens. Vous n’avez même pas besoin de déployer de nouvelles fibres dans les rues ou physiquement ; vous pouvez littéralement prendre la fibre qui a été déployée il y a une décennie, déployer le nouvel émetteur-récepteur, et avoir plusieurs ordres de grandeur de plus de bande passante sur le même câble.

La chose intéressante, c’est qu’il existe une loi générale des communications optiques : chaque décennie, la distance diminue à laquelle il devient intéressant de remplacer la communication électrique par des communications optiques. Si nous remontons quelques décennies en arrière, il y a deux décennies, il fallait environ 100 mètres pour que la communication optique dépasse la communication électrique. Donc, si vous aviez des distances inférieures à 100 mètres, vous optiez pour le cuivre ; si vous aviez plus de 100 mètres, vous optiez pour la fibre. Cependant, de nos jours, avec la dernière génération, nous pouvons avoir une distance où l’optique l’emporte même à une distance aussi courte que trois mètres. Si nous regardons une décennie à l’avance, je ne serais pas surpris de voir des situations où les communications optiques l’emportent même si nous regardons des distances aussi courtes que la moitié d’un mètre. Cela signifie qu’à un moment donné, je ne serais pas surpris que les ordinateurs eux-mêmes aient des voies optiques à l’intérieur, simplement parce que c’est plus performant que les voies électriques.

Du point de vue du logiciel d’entreprise, cela est également très intéressant car cela signifie que si vous regardez vers l’avenir, la bande passante va diminuer massivement en termes de coût. Cela est largement subventionné par des entreprises comme Netflix, qui ont une consommation de bande passante importante. Cela signifie que pour tricher avec la latence, vous pourriez faire des choses comme récupérer préventivement une tonne de données vers l’utilisateur, puis laisser l’utilisateur interagir avec des données qui ont été rapprochées de lui avec une latence beaucoup plus courte. Même si vous apportez des données qui ne sont pas nécessaires, ce qui vous tue, c’est la latence, pas la bande passante. Il vaut mieux dire : “J’ai des doutes sur le type de données qui sera nécessaire ; je peux prendre mille fois plus de données que ce dont j’ai vraiment besoin, les rapprocher de l’utilisateur final, laisser l’utilisateur ou le programme interagir avec ces données, et minimiser le temps de réponse, et je gagnerai en termes de performances.” Cela a encore un impact profond sur le type de décisions architecturales qui sont prises aujourd’hui car elles conditionneront si vous pouvez gagner en performances avec les progrès de cette classe de matériel dans une décennie.

En conclusion, la latence est le grand défi de notre époque en termes de génie logiciel. Cela conditionne vraiment toutes sortes de performances que nous avons et aurons. La performance est absolument essentielle car elle influencera non seulement le coût informatique, mais aussi la productivité des personnes qui opèrent dans votre supply chain. En fin de compte, cela influencera également la performance de la supply chain elle-même, car si vous n’avez pas cette performance, vous ne pouvez même pas mettre en œuvre une sorte de recette numérique qui serait vraiment intelligente et fournirait des événements d’optimisation avancée et prédictive que nous recherchons. Cependant, dans l’ensemble, cette bataille pour de meilleures performances n’est pas gagnée, du moins pas dans le domaine des logiciels d’entreprise. Les nouveaux systèmes peuvent être, et sont souvent, plus lents que les anciens. C’est un problème aigu. Les performances logicielles plus lentes génèrent des coûts stupéfiants pour les entreprises qui en sont victimes.

Juste pour vous donner un exemple, il ne faut pas considérer comme acquis que du matériel informatique plus performant vous donne de meilleures performances. Certaines personnes sur Internet ont décidé de mesurer la latence d’entrée, ou le décalage d’entrée, qui est le temps qu’il faut après une pression sur une touche pour que la lettre correspondante s’affiche à l’écran. Avec un Apple II en 1983, qui avait un processeur de 1 MHz, cela prenait 30 millisecondes. En 2016, avec un Lenovo X1, équipé d’un processeur de 2,6 GHz, un très bel ordinateur portable, la latence s’est avérée être de 110 millisecondes. Nous avons donc un matériel informatique plusieurs milliers de fois meilleur, mais nous nous retrouvons avec une latence presque quatre fois plus lente. C’est caractéristique de ce qui se passe lorsque vous n’avez pas de sympathie mécanique et que vous ne faites pas attention au matériel informatique que vous avez. Si vous antagonisez le matériel informatique, il vous le rendra par de mauvaises performances.

Le problème est bien réel. Ma suggestion est que lorsque vous commencez à examiner n’importe quel logiciel d’entreprise pour votre entreprise, qu’il soit open source ou non, rappelez-vous les éléments de sympathie mécanique que vous avez appris aujourd’hui. Regardez le logiciel et réfléchissez sérieusement à savoir s’il embrasse les tendances profondes du matériel informatique ou s’il les ignore complètement. S’il les ignore, cela signifie non seulement que les performances ne s’amélioreront pas avec le temps, mais très probablement, elles se détérioreront. La plupart des améliorations de nos jours sont obtenues grâce à la spécialisation plutôt qu’à la vitesse d’horloge. Si vous manquez cette autoroute, vous empruntez un chemin qui deviendra de plus en plus lent au fil du temps. Évitez ces solutions car elles résultent généralement de décisions de conception clés prises tôt qui ne peuvent pas être annulées. Vous êtes coincé avec elles pour toujours, et cela ne fera qu’empirer année après année. Pensez à une décennie à l’avance lorsque vous commencez à examiner ces angles.

Maintenant, regardons les questions. C’était une conférence assez longue, mais c’est un sujet difficile.

Question: Quel est votre avis sur les ordinateurs quantiques et leur utilité pour résoudre les problèmes complexes d’optimisation de la supply chain ?

Une question très intéressante. Je me suis inscrit il y a 18 mois pour la version bêta de l’ordinateur quantique d’IBM, lorsqu’ils ont ouvert l’accès à leur ordinateur quantique dans le cloud. J’ai l’impression que c’est passionnant, car les experts peuvent voir toutes les courbes en S s’aplatir mais ne voient pas les nouvelles courbes apparaître de nulle part. L’informatique quantique en est une. Cependant, je pense que les ordinateurs quantiques présentent des défis très difficiles en ce qui concerne les supply chains. Tout d’abord, comme je l’ai dit, la bataille de notre époque en termes de logiciel d’entreprise est la latence, et les ordinateurs quantiques n’y changent rien. Les ordinateurs quantiques vous donnent potentiellement jusqu’à 10 ordres de grandeur d’accélération pour des problèmes de calcul très serrés. Ainsi, les ordinateurs quantiques seraient la prochaine étape au-delà des TPUs, où vous pouvez effectuer des opérations très serrées incroyablement rapidement.

C’est très intéressant, mais pour être honnête, il y a actuellement très peu d’entreprises, à ma connaissance, qui parviennent même à exploiter les instructions superscalaires dans leur logiciel d’entreprise. Cela signifie que l’ensemble du marché laisse de côté une accélération de 10 à 28 fois grâce aux GPU superscalaires. Il y a très peu de personnes dans le monde de la supply chain qui le font ; peut-être Lokad, peut-être pas. Pour ce qui est des TPUs, je pense qu’il n’y a littéralement personne. Google le fait de manière extensive, mais je ne connais personne qui ait jamais utilisé les TPUs pour quoi que ce soit lié à la supply chain. Les processeurs quantiques seraient la prochaine étape au-delà des TPUs.

Je suis certainement très attentif à ce qui se passe avec les ordinateurs quantiques, mais je pense que ce n’est pas le goulot d’étranglement auquel nous sommes confrontés. C’est passionnant car nous revisitons la conception de von Neumann établie il y a environ 70 ans, mais ce n’est pas le goulot d’étranglement auquel nous ou la supply chain serons confrontés au cours de la prochaine décennie. Au-delà de cela, votre supposition est aussi bonne que la mienne. Oui, cela pourrait potentiellement tout changer ou pas.

Question: Les offres Cloud et SaaS permettent aux organisations de tirer parti et de convertir des coûts fixes. Les entreprises proposant de tels services travaillent-elles également à réduire leurs coûts fixes et les risques associés ?

Eh bien, cela dépend. Si je suis une plateforme de cloud computing et que je vous vends de la puissance de traitement, est-ce vraiment dans mon intérêt de rendre votre logiciel d’entreprise aussi efficace que possible ? Pas vraiment. Je vous vends des machines virtuelles, des gigaoctets de bande passante et du stockage, donc en réalité, c’est tout le contraire. Mon intérêt est de m’assurer que vous disposez d’un logiciel aussi inefficace que possible, afin que vous consommiez et payiez pour une quantité folle de ressources à la demande.

En interne, les grandes entreprises technologiques comme Microsoft, Amazon et Google sont incroyablement agressives en ce qui concerne l’optimisation de leurs ressources informatiques. Mais elles sont également agressives lorsqu’elles sont en première ligne pour payer la facture lorsqu’elles facturent un client pour la location d’une machine virtuelle. Si le client loue une machine virtuelle qui est 10 fois plus grande que ce qu’elle devrait être simplement parce que le logiciel d’entreprise qu’il utilise est très inefficace, il n’est pas dans leur intérêt d’interrompre l’erreur du client. C’est très bien pour eux ; c’est bon pour les affaires. Lorsque l’on pense que les intégrateurs de systèmes et les plateformes de cloud computing travaillent généralement main dans la main en tant que partenaires, on peut se rendre compte que ces catégories de personnes n’ont pas nécessairement votre intérêt à l’esprit. Maintenant, en ce qui concerne le SaaS, c’est un peu différent. En effet, si vous finissez par payer un fournisseur de SaaS par utilisateur, alors il est dans l’intérêt de l’entreprise, et c’est le cas de Lokad, par exemple. Nous ne facturons pas en fonction des ressources informatiques que nous consommons ; nous facturons généralement nos clients selon des frais mensuels fixes. Ainsi, les fournisseurs de SaaS ont tendance à être très agressifs en ce qui concerne leur propre consommation de ressources de calcul.

Cependant, attention, il y a un biais : si vous êtes une entreprise SaaS, vous pouvez être assez réticent à faire quelque chose qui serait beaucoup plus agréable pour vos clients mais beaucoup plus coûteux en termes de matériel pour vous. Ce n’est pas tout rose. Il y a une sorte de conflit d’intérêts qui affecte tous les fournisseurs de services SaaS qui opèrent dans l’espace de la supply chain. Par exemple, ils pourraient investir dans la réingénierie de tous leurs systèmes pour offrir une meilleure latence et des pages Web plus rapides, mais le problème est que cela coûte des ressources et leurs clients ne vont pas naturellement leur payer plus s’ils font cela.

Le problème tend à être amplifié lorsqu’il s’agit de logiciels d’entreprise. Pourquoi cela ? C’est parce que la personne qui achète le logiciel n’est généralement pas la personne qui l’utilise. C’est pourquoi une grande partie du système d’entreprise est incroyablement lent. La personne qui achète le logiciel ne souffre pas autant qu’un planificateur de la demande ou un gestionnaire des stocks qui doit faire face à un système super lent tous les jours de l’année. Il y a donc un autre aspect qui est spécifique au domaine des logiciels d’entreprise. Vous devez vraiment analyser la situation, en tenant compte de tous les incitatifs en jeu, et lorsqu’il s’agit de logiciels d’entreprise, il y a généralement de nombreux incitatifs contradictoires.

Question : Combien de fois Lokad a-t-il dû revoir son approche, compte tenu des progrès matériels observés ? Pouvez-vous mentionner un exemple, si possible, pour mettre ce contenu en contexte de problèmes réels résolus ?

Lokad, je crois, a largement réinventé notre pile technologique une demi-douzaine de fois. Cependant, Lokad a été fondée en 2008, et nous avons eu une demi-douzaine de réécritures majeures de toute l’architecture. Ce n’est pas parce que le logiciel avait tellement progressé ; le logiciel avait progressé, oui, mais ce qui a motivé la plupart de nos réécritures n’était pas le fait que le matériel avait tellement progressé. C’était plutôt comme si nous avions acquis une compréhension du matériel. Tout ce que j’ai présenté aujourd’hui était essentiellement connu des personnes qui étaient déjà attentives il y a une décennie. Donc, vous voyez, oui, le matériel évolue, mais c’est très lent, et la plupart des tendances sont très prévisibles, même une décennie à l’avance. C’est un long jeu qui se joue.

Lokad a dû subir de nombreuses réécritures, mais c’était plutôt le reflet du fait que nous devenions progressivement moins incompétents. Nous acquérions des compétences, et nous avions donc une meilleure compréhension de la façon d’exploiter le matériel, plutôt que le fait que le matériel avait changé la tâche. Ce n’était pas toujours vrai ; il y avait des éléments spécifiques qui ont vraiment été révolutionnaires pour nous. Le plus notable a été les SSD. Nous sommes passés des HDD aux SSD, et cela a complètement changé la donne en termes de performances, avec des impacts massifs sur notre architecture. En termes d’exemples concrets, toute la conception d’Envision, le langage de programmation spécifique au domaine que Lokad fournit, est basée sur les connaissances que nous avons acquises au niveau du matériel. Ce n’est pas seulement une réalisation ; il s’agit de faire tout ce à quoi vous pouvez penser simplement plus rapidement.

Vous voulez traiter un tableau avec un milliard de lignes et 100 colonnes, et vous voulez le faire 100 fois plus rapidement avec les mêmes ressources informatiques ? Oui, vous pouvez le faire. Vous voulez être capable de faire des jointures entre des tables très volumineuses avec des ressources informatiques minimales ? Oui, encore une fois. Pouvez-vous avoir des tableaux de bord super complexes avec littéralement une centaine de tables affichées à l’utilisateur final en moins de 500 millisecondes ? Oui, nous avons réussi cela. Ce sont des réalisations banales, mais c’est parce que nous avons réussi toutes ces réalisations que nous pouvons mettre en production des recettes d’optimisation prédictive assez sophistiquées. Nous devons nous assurer que toutes les étapes qui nous ont permis d’y arriver sont réalisées avec une très grande productivité.

Le plus grand défi lorsque vous souhaitez réaliser quelque chose de très sophistiqué pour la supply chain en termes de recettes numériques n’est pas l’étape du “faire fonctionner”. Vous pouvez prendre des étudiants universitaires et réaliser une série de prototypes qui permettront d’améliorer les performances de la supply chain en quelques semaines. Il vous suffit de prendre Python et n’importe quelle bibliothèque d’apprentissage automatique open source du jour, et ces étudiants, s’ils sont intelligents et motivés, produiront un prototype fonctionnel en quelques semaines. Cependant, vous ne pourrez jamais le mettre en production à grande échelle. C’est le problème. Il s’agit de savoir comment passer par toutes ces étapes de maturité du “faire les choses correctement”, “les faire rapidement” et “les faire à moindre coût”. C’est là que l’affinité matérielle brille vraiment et votre capacité à itérer.

Il n’y a pas de réalisation unique. Cependant, tout ce que nous faisons, par exemple lorsque nous disons que Lokad réalise des prévisions probabilistes, ne nécessite pas beaucoup de puissance de traitement. Ce qui nécessite vraiment de la puissance de traitement, c’est de tirer parti de distributions de probabilités très étendues et d’examiner tous ces futurs possibles et de combiner tous ces futurs possibles avec toutes les décisions possibles que vous pouvez prendre. De cette façon, vous pouvez choisir les meilleurs avec une optimisation financière, ce qui devient très coûteux. Si vous n’avez pas quelque chose de très optimisé, vous êtes bloqué. Le fait même que Lokad puisse utiliser des prévisions probabilistes en production est une preuve que nous avons eu une optimisation matérielle approfondie tout au long des pipelines pour tous nos clients. Nous servons actuellement environ 100 entreprises.

Question : Est-il préférable d’avoir un serveur interne pour les logiciels d’entreprise (ERP, WMS) plutôt que d’utiliser des services cloud pour éviter la latence ?

Je dirais qu’aujourd’hui, cela n’a pas d’importance car la plupart des latences que vous rencontrez se situent à l’intérieur du système. Ce n’est pas le problème de la latence entre votre utilisateur et l’ERP. Oui, si vous avez une latence très faible, vous pouvez ajouter environ 50 millisecondes de latence. Évidemment, si vous avez un ERP, vous ne voulez pas qu’il soit situé à Melbourne alors que vous opérez à Paris, par exemple. Vous voulez garder le centre de données près de l’endroit où vous opérez. Cependant, les plateformes de cloud computing modernes disposent de dizaines de centres de données, il n’y a donc pas beaucoup de différence en termes de latence entre l’hébergement interne et les services cloud.

En général, l’hébergement interne ne signifie pas placer l’ERP sur le sol au milieu de l’usine ou de l’entrepôt. Au lieu de cela, cela signifie mettre votre ERP dans un centre de données où vous louez du matériel informatique. Je pense qu’il n’y a pas de différence pratique entre l’hébergement interne et les plateformes de cloud computing du point de vue des plateformes de cloud computing modernes avec des centres de données partout dans le monde.

Ce qui fait vraiment la différence, c’est si vous avez un ERP qui minimise internement tous les allers-retours. Par exemple, ce qui tue généralement les performances d’un ERP, c’est l’interaction entre la logique métier et la base de données relationnelle. Si vous avez des centaines d’interactions aller-retour pour afficher une page web, votre ERP sera terriblement lent. Vous devez donc envisager des conceptions de logiciels d’entreprise qui ne comportent pas un nombre massif d’allers-retours. Il s’agit d’une propriété interne du logiciel d’entreprise que vous examinez, et cela ne dépend pas beaucoup de l’endroit où vous localisez le logiciel.

Question : Pensez-vous que nous avons besoin de nouveaux langages de programmation qui embrasseraient la nouvelle conception matérielle au niveau central, en utilisant les fonctionnalités de l’architecture matérielle à leur plein potentiel ?

Oui, et oui. Mais pour être honnête, j’ai un conflit d’intérêts ici. C’est précisément ce que Lokad a fait avec Envision. Envision est né de l’observation qu’il est difficile de tirer parti de toute la puissance de traitement disponible dans les ordinateurs modernes, mais cela ne devrait pas l’être si vous concevez le langage de programmation lui-même en gardant à l’esprit les performances. Vous pouvez le rendre surnaturel, et c’est pourquoi, dans la leçon 1.4 sur les paradigmes de programmation pour la supply chain, j’ai dit que si vous choisissez les bons paradigmes de programmation, tels que la programmation par tableau ou la programmation par trame de données, et que vous construisez un langage de programmation qui embrasse ces concepts, vous obtenez des performances presque gratuites.

Le prix que vous payez est que vous n’êtes pas aussi expressif qu’un langage de programmation comme Python ou C++, mais si vous êtes prêt à accepter une expressivité réduite et à couvrir tous les cas d’utilisation pertinents pour la supply chain, alors oui, vous pouvez obtenir d’énormes améliorations de performance. C’est ma conviction, et c’est pourquoi j’ai également affirmé que, par exemple, la programmation orientée objet du point de vue de l’optimisation de la supply chain n’apporte rien.

Au contraire, c’est une sorte de paradigme qui antagonise seulement le matériel informatique sous-jacent. Je ne dis pas que la programmation orientée objet est entièrement mauvaise ; ce n’est pas ce que je dis. Je dis qu’il y a des domaines de l’ingénierie logicielle où cela a tout son sens, mais cela n’a pas de sens en ce qui concerne l’optimisation prédictive de la supply chain. Donc oui, nous avons vraiment besoin de langages de programmation qui embrassent cela.

Je sais que j’ai tendance à répéter cela, mais Python a essentiellement été conçu à la fin des années 80, et ils ont un peu manqué tout ce qu’il y avait à voir sur les ordinateurs modernes. Ils ont quelque chose où, par conception, ils ne peuvent pas tirer parti du multi-threading. Ils ont cette verrou global, donc ils ne peuvent pas tirer parti de plusieurs cœurs. Ils ne peuvent pas tirer parti de la localité. Ils ont un binding tardif qui complique vraiment les accès mémoire. Ils sont très variables, donc ils consomment beaucoup de mémoire, ce qui signifie que cela joue contre le cache, etc.

Ce sont les sortes de problèmes où, si vous utilisez Python, cela signifie que vous allez affronter des batailles difficiles dans les décennies à venir, et la bataille ne fera qu’empirer avec le temps. Ils ne s’amélioreront pas.

La prochaine leçon aura lieu dans trois semaines, le même jour de la semaine, à la même heure. Elle aura lieu à 15h, heure de Paris, le 9 juin. Nous allons discuter des algorithmes modernes pour la supply chain, qui sont un peu l’équivalent des ordinateurs modernes pour la supply chain. À la prochaine.