La mémoire devient cruciale dans le computing moderne

Pendant des décennies, la puissance d’un PC se résumait à quelques chiffres clés. La vitesse d’horloge pour le processeur, le nombre de teraFLOPS pour le GPU. Ces valeurs restent pertinentes, mais les composants modernes sont aujourd’hui si puissants qu’un autre facteur limite souvent leurs performances réelles : le temps et l’énergie nécessaires pour acheminer les données jusqu’aux unités de calcul.

Quand le flux de données dicte la performance réelle

Un cœur de CPU moderne peut exécuter plusieurs instructions par cycle d’horloge. Un GPU haut de gamme contient des milliers d’unités arithmétiques fonctionnant en parallèle. Mais aucune de ces unités ne peut calculer quoi que ce soit d’utile sans données : instructions, textures, poids d’un modèle d’IA ou résultats intermédiaires.

Un déséquilibre fondamental en découle. La puissance de calcul brute a explosé au fil des ans, mais le déplacement des données reste beaucoup plus coûteux en latence, en bande passante et en énergie. Conséquence : de nombreuses charges de travail modernes dépensent une part étonnante de leurs ressources à tenter de nourrir les unités d’exécution en continu.

Cela ne signifie pas que chaque application est limitée par la mémoire. Loin de là. Les performances peuvent toujours être contraintes par le débit des calculs, les dépendances d’instructions ou la prédiction de branchement. La différence, c’est qu’aujourd’hui, comprendre le comportement de la mémoire est indispensable pour analyser les performances réelles d’un système.

Et les performances mémoire vont bien au-delà de la simple fréquence ou de la capacité. La latence, la localité des données, la taille des caches, le parallélisme et la topologie des interconnexions interagissent les uns avec les autres. Pour comprendre pourquoi, il faut commencer par la distinction la plus importante : la manière dont les données sont accédées.

Accès séquentiel et aléatoire : deux mondes parallèles

Imaginez lire un fichier de 1 Go du début à la fin. L’emplacement du prochain bloc de données est parfaitement prévisible. Une fois que le système comprend ce que vous faites, il peut commencer à récupérer les données futures avant même qu’elles ne soient explicitement demandées. C’est ce qu’on appelle un accès séquentiel, et les ordinateurs modernes sont extrêmement efficaces pour le gérer.

Les CPU intègrent des préchargeurs matériels conçus pour reconnaître ces flux de mémoire prévisibles. Les contrôleurs DRAM peuvent maintenir plusieurs transactions en vol et réorganiser les requêtes. Les contrôleurs SSD répartissent les accès sur de nombreux canaux NAND. Les GPU peuvent regrouper les requêtes mémoire de threads voisins en transactions plus larges. Le matériel peut ainsi créer un pipeline efficace.

Malheureusement, l’accès aléatoire est un obstacle bien plus difficile à franchir.

Prenons l’exemple du parcours d’une liste chaînée, où chaque entrée contient l’adresse de la suivante. Le processeur n’a aucun moyen de savoir où se trouve la prochaine donnée avant d’avoir fini de lire la première. Cela supprime toute possibilité de préchargement et empêche la machine de superposer efficacement les accès. C’est pourquoi deux applications peuvent transférer le même volume de données tout en affichant des vitesses d’exécution radicalement différentes.

Cette distinction devient encore plus cruciale lorsque des dépendances de latence interviennent. Si un CPU demande quatre lignes de cache indépendantes, il peut généralement garder plusieurs défauts de cache en vol simultanément et masquer une grande partie de leur latence. En revanche, si la requête B dépend du résultat de la requête A, alors B ne peut même pas démarrer avant la fin de A.

Le principe est le même partout dans l’informatique. Une base de données effectuant de petites recherches imprévisibles présente un défi très différent de la copie d’un gros fichier. Un GPU échantillonnant des texels cohérents se comporte différemment de milliers de threads accédant à des adresses sans rapport. Un SSD lisant des centaines de kilo-octets séquentiellement voit une charge de travail fondamentalement différente de la récupération de blocs de 4 Ko éparpillés.

Cela explique aussi pourquoi il est impossible de simplement transformer un accès aléatoire en accès séquentiel pour augmenter les performances. Les développeurs s’y efforcent malgré tout : les bases de données réorganisent les données, les moteurs de jeu regroupent les tâches, les algorithmes GPU réordonnent les requêtes. Mais ce n’est pas toujours possible.

Si la prochaine adresse dépend vraiment du résultat de l’opération en cours, la dépendance est réelle. Si un rayon de lumière peut rebondir vers une partie imprévisible d’une scène 3D, le GPU ne peut pas connaître chaque accès futur à l’avance. L’objectif devient alors moins d’éliminer les accès aléatoires que de faire en sorte que les accès coûteux se produisent le plus rarement, le plus prévisiblement et le plus simultanément possible.

La localité : le secret de l’efficacité des caches

Heureusement, les logiciels accèdent rarement à des données totalement arbitraires en permanence. Les programmes présentent généralement une localité spatiale et une localité temporelle.

La localité spatiale signifie que si un programme accède à une donnée, il est relativement probable qu’il ait besoin de données voisines peu après. La localité temporelle signifie qu’une donnée récemment accédée a des chances raisonnables d’être réutilisée.

Une boucle traitant un tableau présente une excellente localité spatiale. Les données d’un monde de jeu fréquemment référencées peuvent avoir une forte localité temporelle. Ces propriétés sont ce qui rend les caches viables.

Lorsqu’un CPU a besoin d’un octet depuis la DRAM, il ne transfère généralement pas uniquement cet octet. Les données circulent dans la hiérarchie de cache par blocs de taille fixe appelés lignes de cache. Sur les CPU x86 grand public, elles font typiquement 64 octets.

Si le programme accède ensuite à des données voisines, elles sont peut-être déjà présentes dans le cache. Cela introduit un autre concept critique : le jeu de travail.

Un programme peut allouer techniquement des dizaines de gigaoctets de mémoire, mais n’opérer en réalité que sur une petite partie à un moment donné. Si ce jeu de travail actif tient dans un cache rapide, les performances seront excellentes. Augmentez-le légèrement au-delà de la capacité du cache disponible, et soudain, de nombreux accès débordent vers un niveau de hiérarchie plus lent. Cela peut créer des variations de performances étonnamment brutales.

C’est aussi pourquoi l’augmentation de la capacité du cache produit parfois des gains énormes, et parfois presque aucun. Passer d’un cache de 32 Mo à 96 Mo est extrêmement précieux si cela permet à un jeu de travail fréquemment réutilisé de 60 Mo de rester sur la puce. L’avantage est bien moindre si la charge de travail parcourt en flux continu plusieurs gigaoctets de données qu’elle ne touche plus jamais. Les caches fonctionnent donc mieux lorsque le logiciel leur donne quelque chose qui vaut la peine d’être mémorisé.

Pourquoi les CPU ont plusieurs niveaux de cache

Cela soulève une question évidente. Si le cache est si utile, pourquoi ne pas simplement construire un énorme cache ultra-rapide et oublier la mémoire plus lente ? Parce que les propriétés que nous voulons pour la mémoire sont en conflit les unes avec les autres.

Les caches les plus proches du CPU sont fabriqués en SRAM et optimisés pour une latence d’accès extrêmement basse et une bande passante très élevée. Mais la SRAM consomme une surface de silicium considérable. Des structures plus grandes nécessitent aussi plus de fils, des chemins physiques plus longs, une logique de recherche plus complexe et souvent plus d’énergie pour y accéder.

À mesure que la capacité augmente, maintenir la vitesse d’un petit cache local devient progressivement plus difficile, et c’est la raison principale de l’existence de la hiérarchie.

Un cache L1 est assez petit pour se trouver extrêmement près d’un cœur d’exécution et servir les données avec une latence très faible. Le L2 offre plus de capacité avec une latence un peu plus élevée. Le cache de dernier niveau (généralement L3 sur les CPU modernes) offre encore plus de capacité et peut être partagé entre les cœurs, mais y accéder est généralement plus lent. Si une requête rate tous les niveaux, elle doit finalement voyager jusqu’à la DRAM, beaucoup plus lente.

La conception du cache va aussi bien au-delà de la simple capacité. L’associativité affecte l’endroit où les blocs de données peuvent être placés et peut réduire les conflits, mais une flexibilité accrue de recherche ajoute de la complexité. Le bancage du cache peut augmenter la capacité d’accès parallèle. Des ports multiples améliorent le débit mais coûtent en surface et en puissance. Les caches privés donnent aux cœurs individuels un accès local rapide, tandis que les caches partagés peuvent utiliser la capacité totale plus efficacement et simplifier certains partages de données.

Il y a ensuite la cohérence. Lorsque plusieurs cœurs de CPU mettent en cache des copies de la même mémoire, le système doit garantir qu’ils n’opèrent pas indéfiniment sur des versions contradictoires des données. Maintenir cette vue cohérente génère une communication et une comptabilité supplémentaires, particulièrement à mesure que le nombre de cœurs augmente. Plus de cache n’offre donc pas de solution miracle universelle.

La technologie 3D V-Cache d’AMD est un excellent exemple moderne d’ingénieurs trouvant un autre moyen de contourner ce compromis. Au lieu d’étendre considérablement la puce du cœur de CPU horizontalement, AMD empile une puce de cache supplémentaire verticalement. Sa mise en œuvre de deuxième génération ajoute une puce cache L3 de 64 Mo en utilisant une liaison directe cuivre à cuivre et des vias traversant le silicium.

La popularité des processeurs Ryzen X3D dans le jeu en démontre l’impact pratique lorsque du cache supplémentaire correspond au jeu de travail d’une application. Les jeux manipulent constamment des données d’état du monde, des appels de rendu, des structures physiques, des animations et bien d’autres structures. Garder plus de ces informations fréquemment réutilisées près du CPU peut réduire les voyages coûteux vers la DRAM.

Mais même ici, les gains varient considérablement d’un jeu à l’autre. Certains parviennent déjà à faire tenir leurs données critiques dans des caches conventionnels plus petits. D’autres sont limités ailleurs. Certains en bénéficient énormément. Cette variabilité est exactement ce que la théorie de la hiérarchie mémoire prédit.

Les performances de la DRAM vont bien au-delà de la fréquence

Finalement, les données qui ne sont pas disponibles dans le cache doivent provenir de la mémoire principale, la DRAM.

La DRAM offre une capacité bien supérieure à la SRAM pour une fraction du coût par bit, mais elle est considérablement plus lente. Les ingénieurs compensent donc avec de la bande passante et du parallélisme.

La DRAM moderne est divisée en interne en banques et groupes de banques. À l’intérieur de ces banques se trouvent des rangées de cellules mémoire. Accéder aux données implique généralement d’activer une rangée dans un tampon de rangée avant de lire ou d’écrire les colonnes désirées.

Cela conduit à trois scénarios simplifiés : si la rangée requise est déjà active, le contrôleur obtient un accès direct au tampon de rangée. Si aucune rangée pertinente n’est ouverte, une doit être activée. Si la banque a actuellement la mauvaise rangée d’ouverte, la rangée existante doit peut-être d’abord être fermée avant que la nouvelle puisse être activée.

Le contrôleur mémoire fait donc bien plus que transmettre aveuglément les requêtes du CPU. Il suit les transactions en cours et tente de les planifier efficacement à travers les canaux, les rangées, les groupes de banques et les banques, tout en respectant un ensemble étendu de contraintes de timing mémoire.

C’est une raison pour laquelle la bande passante mémoire et la latence mémoire ne doivent pas être traitées comme des mesures interchangeables.

La latence décrit la durée d’une opération particulière. La bande passante décrit le volume de données qui peut être transféré dans le temps. Un système peut avoir une bande passante agrégée énorme et être relativement mauvais pour servir une chaîne d’accès mémoire aléatoires dépendants.

À l’inverse, une charge de travail capable de maintenir des centaines de transactions indépendantes en vol peut tolérer une latence substantielle tout en approchant un débit global impressionnant.

La mémoire DDR5 illustre à quel point la conception mémoire moderne dépend du parallélisme. Par rapport à la DDR4, la DDR5 augmente le nombre de groupes de banques, double la longueur de rafale par défaut de huit à seize, et divise un DIMM en deux sous-canaux indépendants. Micron note spécifiquement qu’augmenter les groupes de banques améliore la probabilité d’utiliser des timings moins restrictifs et permet à davantage de pages mémoire de rester ouvertes simultanément.

Cela explique aussi pourquoi l’optimisation de la DRAM donne parfois des résultats frustrants et incohérents. Augmenter le débit de transfert augmente la bande passante théorique. Resserrer les timings peut réduire divers délais. Ajouter des rangées peut affecter le parallélisme disponible. Le contrôleur mémoire, l’architecture du CPU et le comportement de l’application déterminent ensuite la part de l’amélioration qui atteint réellement le logiciel. Un benchmark de compression, un jeu, une base de données et une copie de gros fichier peuvent donc réagir très différemment à la même mise à niveau mémoire.

GDDR et HBM : deux solutions pour deux problèmes

Les GPU nécessitent une bande passante énorme car des milliers de voies d’exécution peuvent demander des données simultanément. Les GPU grand public utilisent donc de la mémoire GDDR connectée via des interfaces comparativement larges et fonctionnant à des débits de transfert très élevés.

Les accélérateurs d’IA et de calcul haute performance poussent cela encore plus loin avec la High Bandwidth Memory, ou HBM.

Au lieu de placer des puces mémoire autour du processeur et de les piloter via des interfaces conventionnelles sur carte mère, la HBM empile des puces DRAM et utilise des interfaces extrêmement larges placées très près du processeur grâce à des techniques de packaging avancées.

Le résultat est une bande passante extraordinaire et une bonne efficacité énergétique par bit transféré, bien qu’au prix d’une complexité et d’un coût d’assemblage substantiellement plus élevés.

L’Instinct MI355X d’AMD donne une indication utile de l’échelle en jeu aujourd’hui. Un seul accélérateur embarque 288 Go de HBM3E et expose jusqu’à 8 To/s de bande passante mémoire théorique. Des systèmes à huit GPU contiennent donc 2,3 To de HBM.

Ces chiffres seraient absurdes pour un CPU de bureau. Pour l’IA moderne, cependant, nourrir le matériel de calcul est devenu l’un des problèmes architecturaux centraux.

L’IA fait du déplacement des données un problème de performance majeur

L’intelligence artificielle générative moderne, principalement sous la forme des grands modèles de langage (LLM), fournit peut-être l’exemple le plus clair de la raison pour laquelle le débit arithmétique brut ne raconte qu’une partie de l’histoire.

Les grands réseaux de neurones impliquent un nombre colossal d’opérations matricielles, ce pour quoi les GPU modernes et les accélérateurs dédiés sont justement conçus. Mais le processeur doit toujours récupérer les poids du modèle, les activations et les données intermédiaires avant que ces unités arithmétiques ne puissent faire un travail utile.

L’entraînement est particulièrement gourmand en mémoire car le système doit maintenir bien plus que les poids du modèle. Selon la technique d’entraînement et l’optimiseur, il peut aussi avoir besoin des gradients, des états de l’optimiseur, des activations conservées pour la rétropropagation et d’un espace de travail temporaire.

L’inférence supprime certains de ces besoins mais crée ses propres défis mémoire.

Prenez un grand modèle de langage avec sept milliards de paramètres. Avec une précision 16 bits, les poids seuls nécessitent environ 14 Go, sans compter le cache KV et les autres surcharges d’exécution.

La quantification aide car réduire chaque paramètre de 16 bits à 8 ou 4 bits diminue la quantité de mémoire requise pour stocker et déplacer le modèle. C’est pourquoi les formats de faible précision améliorent plus que la capacité de stockage. Moins d’octets voyageant depuis la mémoire peut directement augmenter les performances lorsque le trafic mémoire est le facteur limitant.

La leçon plus large s’étend bien au-delà de l’IA. Le recalcul et le déplacement de données sont souvent des coûts interchangeables. Parfois, stocker un résultat est moins cher que le recalculer. Parfois, recalculer une valeur est moins cher que la récupérer depuis une mémoire distante. L’architecture moderne essaie de plus en plus de déterminer de quel côté du compromis il faut se placer.

Le jeu vidéo : une charge de travail mémoire particulièrement complexe

Les jeux sont particulièrement intéressants car il n’existe pas une seule « charge de travail jeu ».

À un instant, le CPU peut parcourir des structures de visibilité et préparer des appels de rendu. Un autre thread peut mettre à jour la physique ou l’IA. Le GPU traite simultanément de la géométrie, échantillonne des textures, lit des données de matériaux, écrit dans des cibles de rendu, évalue des shaders et accède à des structures d’accélération. Dans un jeu en monde ouvert, les assets peuvent aussi être streamés depuis le stockage vers la mémoire système et la VRAM en arrière-plan. Certaines de ces opérations sont très cohérentes, d’autres non. Cela aide à expliquer plusieurs tendances matérielles.

Du côté du CPU, les processeurs X3D d’AMD utilisent de grands caches de dernier niveau pour capturer davantage des jeux de travail utilisés par les jeux. Le bénéfice peut être substantiel lorsque les données critiques du jeu devraient sinon voyager à plusieurs reprises vers la DRAM.

Sur les GPU, de grands caches de dernier niveau réduisent de manière similaire le trafic externe vers la VRAM, augmentant la bande passante mémoire effective et abaissant radicalement la latence d’accès pour les données critiques. NVIDIA, AMD et Intel ont tous substantiellement modifié leurs structures de cache à travers les générations de GPU car éviter les transactions hors-puce peut améliorer les performances mémoire effectives sans nécessiter une augmentation tout aussi importante de la bande passante mémoire physique.

Le ray tracing en temps réel rend le comportement des données encore plus difficile. Les rayons traversent des hiérarchies de volumes englobants, ou BVH, des structures de données arborescentes qui déterminent quelles pièces de géométrie de la scène ils peuvent intersecter. Contrairement aux charges de travail rasterisées conventionnelles, les rayons peuvent diverger et se diriger vers des régions complètement différentes de la scène.

NVIDIA décrit cela comme une divergence à la fois d’exécution et de données : des threads GPU voisins peuvent suivre des chemins de code différents tout en accédant à des adresses mémoire difficiles à regrouper ou à mettre en cache. Sa technologie de réorganisation de l’exécution des shaders a été conçue en partie pour regrouper le travail de ray tracing de manière à améliorer la localité d’exécution et des données.

C’est un exemple important car il montre qu’une mémoire plus rapide n’est pas toujours la seule solution à un problème de mémoire, car parfois l’option préférable est de réorganiser le travail pour que le sous-système mémoire existant puisse être utilisé plus efficacement.

Les jeux peuvent aussi être limités par la capacité plutôt que par la bande passante ou la latence. Si les textures, la géométrie et les ressources de rendu requises dépassent la capacité de la VRAM, alors le système peut devoir déplacer des ressources à travers le bus PCI-Express depuis la mémoire système, ou les expulser et les recharger. Un GPU avec une bande passante théorique énorme ne peut pas compenser des données qui ne résident pas dans sa mémoire locale en premier lieu.

Les performances mémoire ont donc plusieurs dimensions, même au sein d’une seule image : le volume de données qui tient localement, la rapidité d’accès, l’efficacité avec laquelle les accès se regroupent, la manière dont les caches capturent la réutilisation, et la quantité de trafic parallèle que l’architecture peut soutenir.

Les SSD démontrent pourquoi la bande passante séquentielle ne suffit pas

Le stockage fournit peut-être la démonstration la plus facile de la façon dont un simple chiffre de bande passante peut être trompeur.

Les SSD NVMe PCIe modernes annoncent des débits séquentiels spectaculaires, mais les transferts séquentiels représentent une charge de travail extrêmement favorable. Les requêtes contiguës de grande taille permettent au contrôleur de distribuer le travail efficacement sur les canaux, puces et plans NAND tout en gardant de nombreuses opérations en vol. Les applications réelles, cependant, demandent fréquemment quelque chose de très différent.

Les systèmes d’exploitation, jeux, bases de données et applications peuvent demander des milliers de morceaux de données relativement petits dispersés sur le disque. C’est pourquoi les spécifications des SSD distinguent le débit séquentiel des IOPS aléatoires, de la profondeur de file d’attente et de la latence.

La documentation de charge de travail de Solidigm elle-même définit les accès séquentiels comme des blocs adjacents, les accès aléatoires comme des blocs répartis sur le média, et la profondeur de file d’attente comme le nombre de requêtes d’E/S en cours. De manière cruciale, augmenter la profondeur de file d’attente peut améliorer le débit en exposant plus de travail parallèle, mais cela se fait au détriment de la latence.

Ceci est conceptuellement très similaire à la DRAM. En fait, un SSD basé sur la mémoire flash NAND contient de nombreuses puces flash fonctionnant en parallèle derrière un contrôleur. La NAND elle-même est organisée en pages et en blocs d’effacement plus grands, et les écritures ne peuvent pas être traitées comme un simple réécrasement d’octet en DRAM. Le contrôleur effectue une traduction d’adresse, une répartition de l’usure, une récupération de place et d’autres opérations en arrière-plan pour faire ressembler la NAND à un périphérique bloc ordinaire.

Ces processus peuvent créer un trafic interne supplémentaire connu sous le nom d’amplification d’écriture, où le SSD écrit physiquement plus de données que l’hôte n’en a demandé. La récupération de place peut aussi produire des pics de latence lors de charges de travail soutenues.

Les SSD grand public ajoutent fréquemment une autre couche à la hiérarchie via une mise en cache d’écriture rapide. En fait, une portion de la NAND peut temporairement fonctionner dans un mode SLC-like, acceptant les écritures rapidement avant que les données ne soient repliées plus tard dans un stockage TLC ou QLC plus dense. Certains disques incluent aussi de la DRAM pour mapper les données, tandis que les modèles sans DRAM peuvent utiliser des technologies comme le Host Memory Buffer pour garder des portions de leurs structures de mappage dans la mémoire système.

Une fois de plus, le périphérique de stockage a effectivement construit sa propre hiérarchie mémoire. Et une fois le cache rapide épuisé, les performances d’écriture soutenues peuvent être très différentes du pic de benchmark de courte durée affiché sur une page produit.

Un même matériel peut être rapide ou lent selon la charge de travail

À ce stade, il devrait être clair pourquoi les benchmarks mémoire nécessitent du contexte.

Une copie de gros fichier veut une bande passante séquentielle soutenue.

Une base de données sensible à la latence peut se soucier bien plus des petits accès aléatoires et de la latence extrême.

Une simulation scientifique opérant sur des tableaux denses peut faire un excellent usage d’une bande passante de streaming et de la vectorisation.

Un compilateur peut passer beaucoup de temps à parcourir des structures de données complexes avec une localité spatiale et/ou temporelle relativement médiocre.

Un jeu limité par le CPU peut bénéficier énormément d’un plus grand cache de dernier niveau si son jeu de travail chaud y tient, tandis qu’un autre jeu réagira à peine.

L’entraînement en IA a besoin d’un débit de calcul, d’une capacité et d’une bande passante énormes simultanément. Le décodage d’un LLM avec une concurrence faible peut s’appuyer beaucoup plus sur la bande passante mémoire. L’inférence à contexte long ajoute le cache KV et transforme la capacité mémoire disponible en une autre ressource centrale.

Même le mot bande passante a besoin d’être qualifié. Il y a la bande passante théorique de l’interface, la bande passante applicative soutenue, la bande passante du cache, la bande passante de la DRAM, la bande passante du stockage et la bande passante des interconnexions. Une charge de travail peut saturer l’une tout en utilisant à peine une autre. Ce qui détermine finalement les performances, c’est la manière dont le modèle d’accès aux données de l’application interagit avec l’ensemble de la hiérarchie.

L’informatique moderne consiste de plus en plus à déplacer moins de données

C’est pourquoi certaines des améliorations les plus intéressantes des processeurs modernes ne sont pas simplement des unités arithmétiques plus rapides.

Les caches gardent les données réutilisées près des ressources d’exécution, les préchargeurs prédisent les accès futurs, les contrôleurs mémoire réorganisent les requêtes pour exposer le parallélisme de la DRAM, l’ordonnancement des threads sur GPU tente d’améliorer la cohérence, le découpage en tuiles divise les grands problèmes en jeux de travail qui tiennent dans des mémoires plus petites, la compression réduit le nombre d’octets à transférer, la quantification fait de même pour les modèles d’IA, la HBM rapproche physiquement de grandes quantités de mémoire des accélérateurs via des interfaces extrêmement larges, l’empilement 3D ajoute de la capacité sans forcer chaque bit de mémoire sur la même puce plane, les chiplets permettent aux concepteurs de combiner de manière plus flexible des structures de calcul, de cache et d’E/S spécialisées, et des interconnexions de plus en plus sophistiquées tentent d’empêcher que la communication entre CPU, GPU et accélérateurs ne devienne le prochain mur.

Le thème commun est simple : utiliser les déplacements de données coûteux aussi efficacement que possible.

Les performances de calcul brut continueront d’augmenter. La bande passante mémoire aussi, les caches grandiront, la HBM deviendra plus rapide, les SSD pousseront plus loin dans les dizaines de gigaoctets par seconde, et le packaging avancé rapprochera des composants auparavant séparés.

Cependant, la distance physique, l’énergie, la capacité et la latence garantissent qu’aucune technologie mémoire unique ne peut fournir une capacité énorme, une bande passante énorme, une latence négligeable et un coût négligeable simultanément.

La hiérarchie mémoire ne va donc nulle part, et elle devient même plus profonde et plus sophistiquée.

Les performances modernes dépendent de plus en plus de la capacité à mettre les bonnes données au bon niveau de cette hiérarchie avant que le processeur ne les demande, et à organiser le logiciel pour que les mêmes données puissent être réutilisées plutôt que déplacées à nouveau.

Un cœur de CPU attendant des centaines de cycles d’horloge pour un accès mémoire dépendant n’est pas du calcul utile. Un GPU avec des milliers d’unités arithmétiques inactives attendant la VRAM n’est pas du calcul utile. Un accélérateur d’IA capable de pétaFLOPS mais affamé de données de modèle n’est pas du calcul utile. Pas plus qu’un SSD à 14 Go/s si l’application ne peut pas émettre et traiter efficacement les requêtes nécessaires pour l’utiliser.

L’opération la plus rapide, après tout, n’est souvent pas de récupérer les données plus rapidement. C’est d’éviter complètement de devoir les récupérer.