AI a écrit un compteur Thread-Safe. Le processeur l'a rendu 5 fois plus lent.

DEV - 07/07
Rencontrez la ligne de cache. J'ai demandé à un assistant IA une chose simple : des compteurs par thread. Quatre fils,...

Rencontrez la ligne de cache.

J'ai demandé à un assistant IA une chose simple : des compteurs par thread. Quatre threads, chacun incrémentant son propre emplacement dans un tableau. Aucune variable partagée. Aucune serrure n'est nécessaire. Le code écrit était propre et correct :

compteurs long[] = new long[threadCount]; // le thread t fait : compteurs[t]++
Entrer en mode plein écran Quitter le mode plein écran

Chaque thread écrit uniquement sur son propre élément. Il n'y a pas de course ici. Toute révision de code le réussirait. Chaque test réussirait également.

Ensuite, je l'ai mesuré par rapport à une version qui fait exactement le même travail et le code correct est perdu 5x.

Les chiffres

Ceci vient de ma machine (Apple Silicon, .NET 10, 4 threads, 200 millions d'incréments par thread) :

Round 1 : adjacent (une ligne de cache) : 464 ms complété (ligne par thread) : 85 ms ratio : 5,4x Round 2 : adjacent (une ligne de cache) : 397 ms complété (ligne par thread) : 85 ms ratio : 4,7x
Entrer en mode plein écran Quitter le mode plein écran

Même boucle. Même nombre d'incréments. Idem "chaque thread ne touche que son propre compteur". La seule différence entre les deux versions réside dans l'emplacement en mémoire des compteurs.

Ce que fait réellement le matériel

Un processeur ne lit jamais un octet de la mémoire. Il déplace les données dans des blocs fixes appelés lignes de cache : 64 octets sur x86, 128 octets sur Apple Silico...
[Courte citation de 8% de l'article original]