Historique
Les CPU modernes utilisent des protocoles de cohérence de cache tels que MESI pour synchroniser les données à travers les caches L1 privés de différents cœurs. Lorsque des threads indépendants écrivent à des emplacements mémoire distincts qui résident accidentellement dans la même ligne de cache (généralement 64 ou 128 octets), le matériel sérialise ces opérations en invalidant et en transférant continuellement la propriété de cette ligne, un phénomène appelé partage faux. C++17 a introduit std::hardware_destructive_interference_size pour exposer la largeur de ligne de cache de l'architecture, permettant aux développeurs de séparer les données mutables afin que les variables chaudes de chaque thread occupent des lignes distinctes et évitent cette surcharge de synchronisation.
Problème
Appliquer alignas(std::hardware_destructive_interference_size) à une variable avec une durée de stockage automatique garantit que l'adresse de départ de l'objet est un multiple de la taille de ligne de cache dans le cadre de pile spécifique de son thread. Cependant, cet alignement est local à la vue mémoire du thread et ne garantit pas l'occupation exclusive de la ligne de cache physique. Si l'objet est plus petit que la ligne de cache, des variables adjacentes sur la même pile — ou des variables sur les piles de différents threads qui se trouvent allouées à des adresses physiques différentes par des multiples de la taille de ligne — peuvent se mapper à la même ligne de cache physique. Par conséquent, le matériel subit toujours du trafic de cohérence lorsqu'un autre thread écrit à une variable différente sur cette même ligne, rendant la spécification alignas insuffisante pour l'isolation.
Solution
Pour garantir l'évitement du partage faux, les données doivent être remplies pour consommer la totalité de la ligne de cache, assurant qu'aucune autre donnée ne partage le stockage physique, quel que soit l'agencement d'adresses à l'exécution. Cela est accompli en définissant une structure qui est à la fois alignée et dimensionnée selon std::hardware_destructive_interference_size.
#include <new> #include <cstddef> #include <atomic> struct alignas(std::hardware_destructive_interference_size) PaddedCounter { std::atomic<int> value; // Le remplissage occupe le reste de la ligne de cache pour éviter le partage char padding[std::hardware_destructive_interference_size - sizeof(std::atomic<int>)]; }; // Le tableau garantit que chaque élément réside sur une ligne de cache distincte PaddedCounter thread_counters[8];
Description du problème
Un processeur de données de marché à faible latence utilise huit threads de travail, chacun maintenant un compteur de ticks par thread dans un tableau global de std::atomic<int> stats[8]. Chaque thread incrémentait exclusivement son propre index sans verrouillage, mais le profilage a révélé que le débit stagnait à une fraction du maximum théorique, les compteurs CPU montrant des cycles de cohérence de cache excessifs plutôt que des calculs en mode utilisateur. L'enquête a confirmé que les entiers atomiques, bien que logiquement indépendants, étaient empilés contiguës dans une seule ligne de cache de 64 octets, provoquant une interférence destructrice entre les cœurs.
Solution 1 : Variables locales alignées
L'équipe a d'abord tenté de déclarer alignas(64) std::atomic<int> local_stat à l'intérieur de la fonction d'exécution de chaque thread, passant des pointeurs à un thread de surveillance. Cette approche nécessitait peu de refactoring et évitait l'état global. Cependant, elle s'est révélée peu fiable car le compilateur pouvait placer d'autres variables automatiques adjacentes à local_stat dans la même ligne de cache, et les allocations de pile de différents threads pouvaient être séparées par des multiples exacts de 64 octets, causant l'aliasing des variables alignées sur la même ligne physique et perpétuant le partage faux.
Solution 2 : Allocation sur le tas avec des pointeurs bruts
Une autre approche considérée a alloué chaque compteur via new std::atomic<int> dans l'espoir que l'allocateur de tas éparpillerait les allocations à travers des adresses mémoire éloignées. Bien que cela réduisît parfois la contention, cela a introduit des performances non déterministes car de petites allocations sont souvent servies à partir de blocs contigus, et les métadonnées de l'allocateur peuvent placer des objets distincts sur la même ligne de cache. De plus, cela nécessitait une gestion manuelle de la mémoire et ne fournissait pas de garanties de temps de compilation d'alignement ou de remplissage.
Solution choisie et résultat
L'implémentation finale a adopté la structure PaddedCounter définie ci-dessus, stockant des instances dans un tableau statique. Cette solution a été sélectionnée car elle imposait de manière déterministe la séparation de la ligne de cache grâce à un remplissage et un alignement à la compilation, éliminant la contention au niveau matériel, quel que soit l'agencement de la mémoire à l'exécution. La consommation de mémoire est passée de 32 octets à 512 octets, ce qui était acceptable pour le gain de performance. Le résultat a été une augmentation du débit par douze et une réduction de la variance de latence, respectant les exigences de traitement sub-microseconde.
Pourquoi appliquer alignas(std::hardware_destructive_interference_size) à un petit objet échoue-t-il à empêcher le partage faux avec d'autres données sur le même thread ?
alignas ne contrôle que l'alignement de l'adresse de départ de l'objet, pas son étendue. Si l'objet est plus petit que la ligne de cache (par exemple, un entier de 4 octets sur une ligne de 64 octets), les octets restants de cette ligne de cache peuvent contenir d'autres variables. Lorsque le compilateur place une autre variable sur cette même ligne, ou lorsque la variable d'un thread différent se mappe à cette ligne physique, le partage faux se produit. La véritable isolation nécessite que l'objet occupe la totalité de la ligne via un remplissage, non seulement d'être aligné à son départ.
Quelle est la distinction entre std::hardware_destructive_interference_size et std::hardware_constructive_interference_size, et quand le regroupement des données pour s'adapter au sein de ce dernier améliorerait-il la performance ?
std::hardware_destructive_interference_size est la séparation minimale requise pour éviter le partage faux, tandis que std::hardware_constructive_interference_size est la taille maximale de données qui bénéficie de la localité spatiale sur une seule ligne de cache. Regrouper des champs fréquemment accédés (par exemple, les coordonnées x, y, z d'un point) dans une structure qui tient dans la taille constructive garantit qu'ils résident sur la même ligne, maximisant les taux de frappe de cache et l'efficacité du préchargement, tandis que la taille destructive est utilisée pour séparer des données mutables non liées.
Comment le partage faux impacte-t-il les opérations std::atomic utilisant memory_order_relaxed, et pourquoi l'ordre de mémoire détendu ne résout-il pas la dégradation des performances ?
Même avec memory_order_relaxed, qui n'impose aucune contrainte d'ordre sur les opérations mémoire environnantes, une écriture atomique nécessite toujours que le cœur du CPU acquière la propriété exclusive de la ligne de cache (un cycle Lire-Pour-Être-Propriété). Si un autre thread a récemment modifié une variable différente sur cette même ligne, le protocole de cohérence du cache force la ligne à rebondir entre les cœurs. Cette synchronisation au niveau matériel se produit indépendamment des garanties logiques du modèle mémoire C++, ce qui signifie que le partage faux entraîne une latence de cache manqué complet, quel que soit l'ordre de mémoire spécifié.