Algorithmes De Remplacement De Page De Mémoire Virtuelle

Ces résultats sont raisonnables compte tenu de votre mise en œuvre actuelle. les raisons qui sous-tendent cela, cependant, mérite une discussion.

Lorsque l'on considère les algorithmes en général, il est très important de considérer les propriétés des algorithmes actuellement en cours d'inspection. Plus précisément, notez leur cas d'angle et les meilleures et les pires conditions. Vous êtes probablement déjà familier avec cette méthode laconique d'évaluation, donc c'est surtout pour le bénéfice de ceux qui lisent ici qui ne peuvent pas avoir un fond algorithmique.

Décomposons votre question par algorithme et explorons leurs propriétés de composants dans leur contexte:

1. FIFO affiche une augmentation des défauts de page à mesure que la taille de votre ensemble de travail (axe de longueur) augmente.

   C'est un comportement correct, cohérent avec l'anomalie de Bélády pour le remplacement de FIFO. Comme la taille de votre jeu de pages de travail augmente, le nombre de défauts de page devrait également augmenter.

2. FIFO montre une augmentation des défauts de page comme la stabilité du système (axe 1 - Profondeur) diminue .

   En notant votre algorithme pour l'ensemencement de la stabilité (if random.random() < stability), vos résultats deviennent moins stables à mesure que la stabilité (S ) approche 1. Lorsque vous augmentez fortement l'entropie dans vos données, le nombre de défauts de page augmente également fortement et propage l'anomalie de Bélády.

   Jusqu'à présent, donc Bien.

3. LRU montre la cohérence avec FIFO. Pourquoi?

   Notez votre algorithme d'ensemencement. norme LRU est le plus optimal lorsque vous avez des demandes de pagination structurées en trames opérationnelles plus petites. Pour les recherches ordonnées et prévisibles, il améliore FIFO en vieillissant les résultats qui n'existent plus dans le cadre d'exécution actuel, qui est une propriété très utile pour l'exécution par étapes et l'opération modale encapsulée. Encore une fois, de sorte ici, tout va bien.

   Cependant, rappelez-vous comment vous avez ensemencé vos données d'entrée: en utilisant random.random, vous donnant ainsi un distribution uniforme de données avec votre niveau d'entropie contrôlable. Pour cette raison, toutes les valeurs sont également susceptibles de se produire, et parce que vous l'avez construit dans espace à virgule flottante, les récurrences sont hautement improbables.

   Par conséquent, votre LRU perçoit chaque élément comme se produisant un petit nombre de fois, puis comme étant complètement ignoré lorsque la valeur suivante a été calculée. Il pagine donc correctement chaque valeur lorsqu'elle tombe hors de la fenêtre, vous donnant des performances exactement comparables à FIFO. Si votre système tenait correctement compte de la récurrence ou d'un espace de caractères compressé, vous verriez des résultats nettement différents.

4. Pour random, la période de stabilité et la taille de l'ensemble de travail ne semblent pas du tout affecter les performances. Pourquoi voyons - nous ce gribouillage sur tout le graphique au lieu de nous donner un relativement collecteur lisse ?

   Dans le cas d'un schéma de pagination aléatoire, vous vieillissez hors de chaque entrée stochastique. Soi-disant, cela devrait nous donner une forme de collecteur lié à l'entropie et à la taille de notre ensemble de travail... droit?

   Ou devrait-il? Pour chaque ensemble d'entrées, vous attribuez aléatoirement un sous-ensemble à la page en fonction du temps. Cela devrait donner des performances de pagination relativement égales, indépendamment de la stabilité et indépendamment de votre ensemble de travail, comme longtemps que votre profil d'accès est à nouveau uniformément aléatoire.

   Donc, en fonction des conditions que vous vérifiez, c'est un comportement tout à fait correct compatible avec ce que nous attendons de. Vous obtenez une performance de pagination uniforme qui ne se dégrade pas avec d'autres facteurs (mais, inversement, n'est pas améliorée par eux) qui convient à une charge élevée, un fonctionnement efficace. Pas mal, mais pas ce à quoi vous pourriez vous attendre intuitivement.

Donc, en un mot, c'est la panne que votre projet est actuellement appliquée.

Comme un exercice pour explorer davantage les propriétés de ces algorithmes dans le contexte de différentes dispositions et distributions de données d'entrée, je recommande fortement de creuser dans scipy.stats pour voir ce que, par exemple, une distribution gaussienne ou logistique pourrait faire à chaque graphique. Ensuite, je reviendrais à les attentes documentées de chaque algorithme et les projets de cas où chacun est unique le plus et le moins approprié.

Dans l'ensemble, je pensez que votre professeur sera fier. :)