La vitesse et la fonctionnalité.
L'histoire de la mémoire virtuelle
Tous les systèmes d'exploitation modernes comme Windows, Linux et MacOS utilisent la mémoire virtuelle. La mémoire virtuelle est un moyen soigné, assisté par le matériel, de mentir à votre ordinateur sur la quantité de mémoire dont il dispose. Votre CPU possède une unité de gestion de la mémoire (MMU), qui mappe la mémoire utilisée par chaque programme en mémoire physique réelle. Cela offre deux avantages immédiats : chaque programme commence au même endroit dans la mémoire, du point de vue de ce programme, et tous les programmes sont isolés les uns des autres. Le programme A n'aura pas accès à la mémoire du programme B.
Mais disons que vous avez un ordinateur de 8 Go et que le programme A et le programme B allouent chacun une mémoire tampon de 4 Go. C'est trop, bien sûr, mais il se trouve aussi que les concepteurs du système d'exploitation savent que, parfois, les programmeurs demandent beaucoup plus que ce dont ils auront jamais besoin. Ainsi, chacun de ces blocs de 4 Go sera alloué dans la mémoire virtuelle, mais pas nécessairement alloué réellement. Chaque programme (chaque processus) possède sa propre cartographie de la mémoire, divisée en petites "pages" de mémoire. La table MMU peut être mise à jour pour ces allocations, mais certaines ou toutes ces pages marquées comme n'étant pas réellement allouées.
Alors, au fur et à mesure que les programmes s'exécutent, la mémoire qui n'est pas en mémoire va signaler un piège de processeur lorsqu'un processeur tente d'y accéder. Ce piège saute vers le gestionnaire de mémoire du système d'exploitation. S'il reste de la mémoire disponible, une partie de celle-ci sera allouée dans la RAM physique et affectée à la page qui a été bloquée, et par souci d'efficacité, probablement un peu plus. Un avantage immédiat de ceci est que le programme, grâce à la gestion de la mémoire, peut obtenir un bloc contigu de mémoire, jusqu'aux 4 Go demandés dans ce cas, même si un bloc contigu n'existe pas dans la mémoire réelle, physique.
Mais que se passe-t-il s'il n'y a plus de mémoire ? Une option serait, bien sûr, de simplement signaler cela comme une erreur de mémoire insuffisante et de terminer le programme. Mais il y a longtemps, les concepteurs de systèmes d'exploitation ont réalisé que de nombreux programmes chargent du code qui n'est utilisé qu'une fois ou rarement. Les utilisateurs peuvent charger des programmes qui peuvent rester inactifs, consommant des ressources pour une faible valeur. Ainsi, les tables de gestion de la mémoire du système permettent également de savoir quelles pages MMU ont été utilisées, lesquelles ont été utilisées récemment, etc. Et cela permet au système d'exploitation de décharger de la mémoire inutilisée, pour répondre à ce besoin de plus de RAM pour le programme A.
Maintenant, si les pages de mémoire récupérées contiennent du code exécutable, c'est du code qui a été chargé à partir de l'image sur disque du programme. Cette page peut simplement être marquée comme n'étant pas en mémoire, et cette RAM récupérée. Cependant, si la mémoire contient des données, celles-ci doivent être placées quelque part. Ce quelque part est presque toujours un quelque part sur le disque. Les systèmes Windows ont un "fichier d'échange", tandis que les systèmes Linux ont généralement une "partition d'échange". Quoi qu'il en soit, il y a un morceau de disque quelque part, que vous utilisiez un disque dur ou un disque SSD, qui est là pour virtualiser votre RAM.
Le coup de performance de VM
Il y a donc une petite surcharge dans la gestion de base de la mémoire, ou du moins il semblerait. Après tout, chaque fois que votre programme prend un piège dans le gestionnaire de mémoire, c'est un morceau de temps mangé qui aurait été une seule instruction. Donc, d'une certaine manière, oui, cela rend les choses plus lentes.
Mais le vrai ralentissement va au disque plutôt qu'à la RAM. Peu importe que vous ayez un vieux disque IDE parallèle ou le tout dernier SSD M.2 sur quatre canaux PCIe, votre disque est beaucoup, beaucoup plus lent que votre DRAM. Et donc le tout premier gain d'avoir plus de mémoire est d'éviter les défauts de page, ces pièges pour le gestionnaire de mémoire qui ont besoin d'échanger sur le disque.
Le gain de performance de la VM
Considérez aussi que la mémoire virtuelle n'est pas apparue comme par magie un jour dans un OS moderne. Les concepteurs de systèmes d'exploitation, les programmeurs d'applications, etc. vivent avec la mémoire virtuelle depuis plus de cinquante ans. Il y a d'énormes avantages en termes de performances avec la mémoire virtuelle.
L'un d'entre eux est simplement de serrer cette application qui ne tiendrait pas autrement. Dans les années 1990, je travaillais dans une entreprise qui fabriquait une application de présentation multimédia. Cette application fonctionnait sous MS-DOS, mais en brassant beaucoup de photos et de vidéos, cela pouvait être un défi. MS-DOS, bien sûr, n'avait pas de mémoire virtuelle. Mais à l'époque, si vous exécutez un programme MS-DOS sur OS/2 d'IBM, il utilise le gestionnaire de mémoire OS/2 et voilà ! Mémoire virtuelle avec pagination. Ainsi, des présentations qui ne fonctionneraient pas sous MS-DOS fonctionneraient sous OS/2 sur la même plate-forme informatique limitée à cette époque.
Certaines autres fonctionnalités sont utilisées, qu'il y ait pagination ou non. Comme le gestionnaire de mémoire sait quelle mémoire a été allouée, il peut tout récupérer sans que les applications aient besoin de dépenser des efforts de codage pour la récupérer. Ce n'est pas une excuse pour une programmation bâclée, mais cela va de pair avec ce facteur de protection - les ressources d'un programme mort peuvent être retrouvées et rendues au système. D'autres aspects de la conception des programmes ont évolué pour tirer parti des systèmes de mémoire virtuelle également.
Et les systèmes d'exploitation eux-mêmes ont évolué. Puisqu'un système géré par la mémoire peut s'adapter à la RAM disponible, les systèmes d'exploitation modernes ne se contentent pas de laisser traîner la RAM inutilisée, ils l'allouent lorsqu'elle n'est pas utilisée autrement pour accélérer le système. Des tampons de mémoire plus grands, des morceaux de code qui pourraient être nécessaires plus tard, etc. peuvent être alloués sans crainte d'étouffer les programmes utilisateurs.
Ce n'est pas illimité, bien sûr. J'ai ici un système avec 64 Go de DRAM, exécutant un navigateur, un programme de CAO et quelques utilitaires, et j'utilise 21,8 Go. Cela pourrait facilement fonctionner sur un système de 16 Go, cela fonctionnerait assez bien sur un système de 8 Go. Mais les optimisations effectuées par le système d'exploitation pour accélérer les choses seraient perdues, et le système serait donc plus lent. Il est possible que dans le cas de 8 Go, je verrais suffisamment de pagination de la mémoire pour ralentir sensiblement encore plus.
Plus de RAM, plus de capacités... à la marge
Naturellement, en parlant de grande mémoire, on parle de systèmes 64 bits. La " règle du pouce " commune pour la mémoire est d'au moins 2 Go par cœur de CPU, donc aujourd'hui, 8 Go sur un système à 4 cœurs, 16 Go sur un système à 6 cœurs comme le mien (12 Go n'est pas une option). Ce chiffre est basé sur l'ancienne limite 32 bits de la plupart des systèmes d'exploitation, qui était de 2 à 3 Go par processus utilisateur, et sur la supposition que vous n'exécutez pas trop de programmes différents en même temps qui consomment réellement du temps CPU (ceux qui sont inactifs, bien sûr, peuvent être sortis de la mémoire sans trop de ralentissement). Mais ce n'est qu'une ligne directrice minimale.
Et certaines choses ne fonctionnent tout simplement pas dans des morceaux de mémoire plus petits, mais étant donné la taille de la RAM sur les ordinateurs moyens de nos jours, le nombre de ces applications vacille régulièrement. Avant ma dernière mise à niveau de mon PC, en 2013, j'avais un PC avec 16 Go de RAM, et cela me freinait. Je fais notamment des composites de photos de grande taille, et le principal programme que j'utilise pour cela est assez gourmand en mémoire. J'assemble des dizaines d'images de 16Mpixels ou 20Mpixels, et je me heurtais à un mur, manquant de mémoire même avec un fichier de page assez important.
J'ai donc construit mon nouveau PC avec 64 Go de DRAM, le maximum que la carte mère pouvait gérer, et j'ai procédé à l'exécution de certains de ces composites de photos... et j'ai immédiatement manqué de mémoire. C'était de ma faute - j'ai essayé d'en utiliser deux en même temps. En allant un à la fois, je suis plutôt bon ces jours-ci.