"Your code is fast - if you're lucky" : pourquoi vos micro-benchmarks mentent
CraftRéservé aux abonnés 11/07/2026 à 17h146Ajouter aux favoris
Un billet viral remet en cause la fiabilité des micro-benchmarks : le même code peut varier de 30% selon l'ordre des symboles, la position en mémoire, ou le nom d'utilisateur. Ce que ça change pour le craft.
In plain terms
Un développeur a montré qu'un même bout de code peut être 30% plus rapide ou plus lent selon des paramètres qui n'ont rien à voir avec l'algorithme : ordre des symboles au link-time, taille des variables d'environnement, alignement mémoire. Autrement dit, une bonne partie de ce qu'on mesure en microseconde tient à la chance.
L'histoire
L'auteur, sur tiki.li/blog/lucky_code, reprend un fil déjà bien connu chez les compilateurs (Emery Berger, Stabilizer, ASPLOS 2013) et le remet au goût du jour : il exécute un même binaire, sans le modifier, et fait varier des paramètres périphériques (nom du répertoire de build, ordre de link des fichiers objets, taille de $PATH). Les runtimes bougent significativement, jusqu'à plus de 30% sur des micro-benchmarks. La cause : l'alignement des instructions dans les caches L1i/uop, le décodeur x86, et la prédiction de branchement, qui sont sensibles à l'adresse virtuelle du code.
Le point qui devrait déranger tout le monde : dans la vraie vie, on compare une PR avant/après, on note un gain de 8%, on merge. Combien de ces gains sont du signal réel ? Combien du bruit d'alignement ?
Under the hood
- Stabilizer (Berger 2013) randomise l'allocation stack, heap et code à chaque run - les mesures deviennent des distributions, pas des points.
- Hyperfine +
-warmup+-runs 50ne résout PAS le problème : il moyenne, mais l'alignement reste le même à chaque run d'un même binaire. - La bonne pratique : recompiler avec des offsets aléatoires (Stabilizer, ou padding manuel) OU exécuter avec
-randomize-addresset rapporter un IC 95%, pas une moyenne.
So what
Trois conséquences pour le craft. Un : tout gain de perf sous 10% sur un micro-benchmark unique est probablement du bruit. Le rejeter, ou le refaire sous randomisation. Deux : les régressions de perf CI (type Codspeed) doivent adopter la randomisation, sinon on va laisser passer des vraies régressions et paniquer sur du bruit. Trois : les benchmarks marketing des compilateurs et runtimes (Bun vs Node, Zig vs C…) sont à lire avec ce filtre. La perf, à ce niveau, tient autant du build engineering que de l'algorithme.
Contenu réservé aux membres
Créez un compte gratuit pour accéder à l'intégralité de nos contenus et à la revue hebdomadaire.
Article produit par intelligence artificielle, relu sous contrôle éditorial humain.
Commentaires (6)
Connectez-vous pour rejoindre la discussion.
Alex 11 Jul 2026 · 17:55
Ces variations sont impressionnantes. On se demande combien d'optimisations reposent sur du hasard plutôt que sur des données fiables.
Alex_London 11 Jul 2026 · 17:35
Est-ce que ces variations affectent vraiment les applications du quotidien, ou c'est juste une question de labo ?
ArtLover88 11 Jul 2026 · 16:50
Les micro-benchmarks sont vraiment peu fiables. Il faut en tenir compte quand on évalue les performances.
SkepticSam 11 Jul 2026 · 16:07
Est-ce qu'il existe des outils pour fiabiliser les micro-benchmarks ?
HistoryBuff 11 Jul 2026 · 15:55
On a bien fait de le rappeler : les micro-benchmarks sont trompeurs. Il faut les prendre avec des pincettes.
TechSavvy 11 Jul 2026 · 18:32
Et les différences matérielles qui faussent encore plus les résultats !
Dr. J. 11 Jul 2026 · 15:20
Je croyais aux benchmarks, mais là c'est inquiétant. Comment croire en ces mesures maintenant ?
