Mémoire et processeur
Progression
#Mémoire et processeur
À quoi ça sert: nourrir le CPU en données/instructions malgré une mémoire principale lente. Comment: hiérarchie (registres → L1 → L2 → L3 → RAM), TLB pour la traduction, cohérence de cache entre cœurs, et code pensé pour la localité.
Objectifs d’apprentissage
- Décrire la hiérarchie mémoire (L1/L2/L3/RAM) et l’impact des cache‑miss.
- Expliquer TLB et adressage virtuel; notions de pages, fautes mineures/majeures.
- Comprendre cohérence de cache (MESI) et false sharing sur multi‑cœurs.
- Appliquer des conseils de localité et de réduction des branchements.
#Hiérarchie mémoire
La hiérarchie aligne vitesse et capacité: registres, L1, L2, L3, RAM puis disque. La localité temporelle et spatiale rend prévisible le prochain accès, ce que le matériel exploite via des lignes de cache et des stratégies d’écriture (write‑back ou write‑through). Optimiser un parcours de données consiste d’abord à respecter cette localité.
Registre/L1: ~0.5–4 ns • L2: ~7–15 ns • L3: ~20–40 ns • RAM: ~60–120 ns. Les valeurs réelles varient selon CPU et fréquences. L’important: l’écart de plusieurs ordres de grandeur entre registres/caches et RAM.
#Exécution
Le pipeline, la prédiction de branchement et l’exécution hors‑ordre maintiennent le CPU occupé. Un miss cache profond ou une mauvaise prédiction font chuter l’IPC et gonflent la latence effective. Sur des parcours irréguliers, le coût des ratés de TLB s’ajoute à celui des ratés de cache.
#Expérience: localité de cache (Python)
Cette démo Pyodide illustre la localité, mais les chiffres absolus diffèrent du natif. Retenez la tendance: parcours séquentiel exploite mieux les caches.
#Simulateur : hiérarchie et miss ratio
Hiérarchie mémoire — simulateur
Ajustez la taille d’ensemble de travail, le pas d’accès et le nombre de threads pour estimer la répartition des hits dans la hiérarchie cache et l’impact sur la latence moyenne.
Ensemble de travail
256 KB
Volume de données actives que le code parcourt en boucle.
Stride / pas d’accès
×8
Distance entre deux accès consécutifs (1 → séquentiel).
Threads concurrents
1
Plus de threads ⇒ compétition sur les caches partagés.
Prélecture matérielle
La prélecture est bénéfique pour les accès réguliers; sur accès aléatoires, elle gaspille de la bande passante.
Répartition des hits
Latence moyenne estimée
43.9 ns
Combinaison pondérée hits caches + accès DRAM
Bande passante effective
120.0 Go/s
Hypothèse: ligne de cache 64 B
La majorité des accès (47%) finit en DRAM. Réduisez l’ensemble chaud (actuellement 256 KB) ou améliorez la localité (stride 8).
Profils d’accès
- Localité spatiale : stride 1 exploite les lignes de cache; un stride élevé saute des blocs entiers.
- Localité temporelle : petits working sets revisitent les mêmes lignes → hits L1/L2.
- Contention : plusieurs threads partagent L3/DRAM → miss ratio augmente.
- Prélecture : utile si l’accès est régulier; nuisible sinon.
Cette simulation reste indicative mais permet de raisonner: réduisez l’ensemble de travail « chaud », regroupez les données et préférez des parcours séquentiels pour que les caches fassent leur travail.
#Conseils perf
Les parcours séquentiels et les structures contiguës exploitent naturellement la localité. Groupez les champs accédés ensemble et limitez l’empreinte mémoire « chaude » pour garder vos données dans les caches. Les préfetchs explicites n’aident que si l’accès est prévisible et assez en avance; sinon, ils gaspillent de la bande passante. Sur multi‑cœurs, évitez le false sharing en séparant les données écrites concurremment par différents threads.
Deux threads écrivant sur des variables différentes mais dans la même ligne de cache se ralentissent par invalidations (cohérence MESI). Aligner/séparer les données écrites fréquemment.
#VM/TLB (aperçu)
L’adressage virtuel découpe la mémoire en pages (ex: 4K) et le TLB met en cache les traductions virtuel→physique. Un raté TLB est coûteux et s’ajoute aux ratés cache. Des accès irréguliers et des ensembles de travail trop grands pénalisent fortement; des structures contiguës, la réutilisation spatiale/temps et parfois des huge pages améliorent la situation. Sur des systèmes SMP, les invalidations de TLB inter‑cœurs (« TLB shootdowns ») expliquent certaines pauses lors de changements de mappings.