J'admire tous ces beaux raisonnements sur la gestion de la mémoire. Ils sont amha parfaitement pertinents sur une installation temps réel, mono-tâche, ou multi-tâche non préemptif.
Mais, préemption, segmentation, pagination et mémoire virtuelle remettent, amha, en question tous ces raisonnements ?
Par exemple, cette assertion:
... La mémoire est une matrice, et le temps d'accès à tel ou tel endroit de la mémoire est le même, ...
n'est plus vraie dans ce mode de fonctionnement. La notion de localité prend une importance considérable: les unités logicielles (au sens sémantique et non pas syntaxique) devraient être contenues dans les limites d'une page (sous Intel et Cie: 4 K0) pour éviter de trop nombreux défauts de pages. Celà tendrait à promouvoir l'utilisation de langage évolué de type objet, malheureusement la localisation dans ce type de langage est, la plupart du temps, uniquement syntaxique. Lors de l'exécution, code et données sont, en général, dans des pages séparées.
Toujours dans ce mode de fonctionnement, mémoire physique et mémoire logique n'ont pas de correspondance directe: la mémoire physique est obligatoirement fragmentée. Et comme les caches de type L2 travaillent au niveau de la mémoire physique ... C'est le type de fonctionnement sous Linux: 2 segments (kernel, user) et mémoire paginée à 2 niveaux.
Il est beaucoup plus dommageable pour les performances de gérer de nombreux défauts de page que de gérer des "défaut de cache" (néologisme de mon cru ?). Les défauts de page se gèrent en terme de dizaines de ms, les défaut de cache en terme de dizaines de nanos secondes.
De toute façon, dans le contexte d'un système d'exploitation multi-tâche préemptif, il ne s'agit pas d'optimiser telle ou telle application, mais d'optimiser l'utilisation globale du couple matériel-logiciel.
# Beaux raisonnements
Posté par abgech . En réponse au journal La mémoire, goulot d'étranglement : optimiser le cache processeur.. Évalué à 10.
Mais, préemption, segmentation, pagination et mémoire virtuelle remettent, amha, en question tous ces raisonnements ?
Par exemple, cette assertion:
n'est plus vraie dans ce mode de fonctionnement. La notion de localité prend une importance considérable: les unités logicielles (au sens sémantique et non pas syntaxique) devraient être contenues dans les limites d'une page (sous Intel et Cie: 4 K0) pour éviter de trop nombreux défauts de pages. Celà tendrait à promouvoir l'utilisation de langage évolué de type objet, malheureusement la localisation dans ce type de langage est, la plupart du temps, uniquement syntaxique. Lors de l'exécution, code et données sont, en général, dans des pages séparées.
Toujours dans ce mode de fonctionnement, mémoire physique et mémoire logique n'ont pas de correspondance directe: la mémoire physique est obligatoirement fragmentée. Et comme les caches de type L2 travaillent au niveau de la mémoire physique ... C'est le type de fonctionnement sous Linux: 2 segments (kernel, user) et mémoire paginée à 2 niveaux.
Il est beaucoup plus dommageable pour les performances de gérer de nombreux défauts de page que de gérer des "défaut de cache" (néologisme de mon cru ?). Les défauts de page se gèrent en terme de dizaines de ms, les défaut de cache en terme de dizaines de nanos secondes.
De toute façon, dans le contexte d'un système d'exploitation multi-tâche préemptif, il ne s'agit pas d'optimiser telle ou telle application, mais d'optimiser l'utilisation globale du couple matériel-logiciel.