Christophe Lecroq • Architecte & Lead Dev Go

📁 Courses/Performance-For-Backend/Slots • 📅 Mis à jour récemment • ⏱️ 8 min de lecture

Version précédente (v1.0)

Vous consultez actuellement une version archivée de cet article. Consulter la dernière version (v1.0) →

Version	Date	Description
v1.0
v1.0
v1.0
v1.0
v1.0 (Actuelle)
v1.0		Version initiale

2. Pile (Stack) : Zéro Allocation

La pile d'exécution est le stockage le plus rapide et le plus efficient pour les fonctions :

• Allocation Instantanée : Déplacement mécanique du pointeur de pile (RSP), coût O(1) de zéro cycle additionnel.
• Libération Automatique : Restitution immédiate de la mémoire au retour de la fonction (function return).
• Zéro Garbage Collection : Aucun travail d'analyse ni interruption pour le ramasse-miettes.
• Localité Maximale : Le sommet de pile réside en permanence dans le cache L1 ultra-rapide.

3. Le Tas (Heap) & Pression GC

Le tas est un espace mémoire dynamique partagé entre l'ensemble des goroutines et threads :

4. Stack vs Heap : Comparatif

Synthèse comparative des deux modes d'allocation mémoire du runtime :

Analyse d'Échappement

5. Analyse d'Échappement du Compilateur

Le compilateur analyse statiquement le code pour décider du placement mémoire optimal :

6. Les 4 Causes d'Échappement

Les scénarios classiques qui provoquent une allocation silencieuse sur le tas :

1. Retour de pointeur : Retourner l'adresse d'une variable locale return &user.
2. Assignation à une interface (any) : Provoque la mise en boîte (boxing) dynamique.
3. Tranches dynamiques : make([]byte, size) dont la taille n'est pas une constante à la compilation.
4. Capture dans une goroutine : Variable transmise par pointeur à une fonction asynchrone go func().

7. Diagnostic : Drapeaux d'Échappement

Pour inspecter les décisions du compilateur Go en ligne de commande :

1# Affiche les décisions d'inlining et d'échappement
2go build -gcflags="-m" ./...
3
4# Niveau de détail maximal avec le cheminement complet
5go build -gcflags="-m -m" ./...

• Sorties caractéristiques :
  • moved to heap: user : La variable a été déplacée sur le tas.
  • user does not escape : Optimisation réussie, la variable reste sur la pile.

Organisation & Alignement des Données

8. Alignement Mémoire Matériel

Sur une architecture 64 bits, chaque donnée doit être alignée sur une adresse multiple de sa taille :

• 8 octets : int64, float64, pointeurs (adresses multiples de 8).
• 4 octets : int32, float32 (adresses multiples de 4).
• 2 octets : int16 (adresses multiples de 2).
• 1 octet : bool, byte, int8 (toutes adresses).

9. Principes d'Alignement & Padding Mémoire

Sur architecture 64-bit, le processeur lit et écrit dans la mémoire par mots alignés de 8 octets. Le compilateur applique des contraintes matérielles strictes : chaque champ doit débuter à une adresse multiple de sa taille naturelle.

10. Cas Pratique : Structure Désordonnée vs Compactée

Comparaison de l'empreinte mémoire d'une même structure avant et après réorganisation des champs :

type CandidateBad struct {
    Found     bool   // 1B + 7B pad (aligné 8B)
    Attempts  int64  // 8B
    CharsetID byte   // 1B + 3B pad (aligné 4B)
    Length    int32  // 4B
    Target    string // 16B (Ptr 8B + Len 8B)
} // Total = 40 octets (10B de vide inutile !)

type CandidateGood struct {
    Attempts  int64  // 8B
    Target    string // 16B (Ptr 8B + Len 8B)
    Length    int32  // 4B
    Found     bool   // 1B
    CharsetID byte   // 1B + 2B pad final
} // Total = 32 octets (-20% de RAM !)

11. Le Piège du Faux Partage

Quand deux cœurs écrivent sur deux variables indépendantes situées sur la même ligne de 64 octets :

1// PIÈGE : Deux compteurs distincts sur la même ligne de 64 octets
2type BadCounters struct {
3    Core0Count uint64 // 8 octets (offset 0)
4    Core1Count uint64 // 8 octets (offset 8) -> Même Cache Line !
5}

12. Résoudre le Faux Partage

Pour éliminer l'invalidation matérielle, on sépare les variables par du remplissage (padding) :

 1// SOLUTION : Isoler chaque compteur sur sa propre ligne de 64 octets
 2type PaddedCounter struct {
 3    value uint64
 4    _     [7]uint64 // 56 octets de remplissage (total = 64 octets)
 5}
 6
 7type SafeCounters struct {
 8    Core0 PaddedCounter // Cache Line #1 dédiée
 9    Core1 PaddedCounter // Cache Line #2 dédiée
10}

• Chaque cœur modifie exclusivement sa propre ligne de cache sans interférer avec les autres.
• Les gains mesurés atteignent souvent x5 à x10 en situation de forte concurrence.

13. Synthèse Modèle Mémoire

Les 3 règles d'or pour la gestion mémoire du runtime :

TP Fil Rouge (Séance 3) : Zéro-Allocation & Struct Padding