Comparaison des algorithmes malloc : de dlmalloc à snmalloc
En bref
- L'article retrace l'évolution des allocateurs mémoire, du malloc basique aux arènes modernes introduites vers 2006, en distinguant trois niveaux : OS, bibliothèque et CPU/core.
- Les allocateurs contemporains (jemalloc, tcmalloc, mimalloc) résolvent le problème historique de la contention sur le tas partagé par des mécanismes per-thread et per-CPU.
- Un tableau synthétise 11 allocateurs sur des critères : thread-safety, caches locaux, arènes, accès sans verrou, conscience NUMA, fragmentation.
- L'accès sans verrou rapide et la minimisation des opérations atomiques (CAS) distinguent les meilleures implémentations modernes.
Ce que dit la source
L'auteur affirme que les programmes multithréadés performants butter sur la contention du tas : quand plusieurs threads allouent/désallouent simultanément, l'allocateur les sérialise, ce qui ralentit les applications au fur et à mesure que le nombre de processeurs augmente. Malloc standard (libc) est présenté comme l'allocateur le moins adapté. La source retrace comment la conception s'est complexifiée au cours des 50 dernières années, des listes chaînées aux arènes modernes et aux stratégies lock-free, pour résoudre ce goulot d'étranglement.
- Les allocateurs modernes (jemalloc, tcmalloc, mimalloc) adoptent des caches per-thread et per-CPU pour réduire la contention sur les structures partagées.
- Mimalloc (Microsoft) affiche les plus faibles opérations atomiques par allocation/libération et minimise les risques de cacheline partagée, sur papier.
- Les arènes (concept clé depuis ~2006) séparent la mémoire par CPU ou core, principalement pour architectures NUMA et multithreads.
- Snmalloc (Microsoft Research) utilise un modèle de passage de messages sans CAS partagé, étudié en environnement académique mais pas en production largement.
- La conscience NUMA et la « first-touch memory » distinguent les allocateurs modernes des anciens designs monolithiques.
- Les allocateurs sans verrou (lock-free) réduisent la contention mais introduisent souvent des opérations CAS (Compare-And-Swap) plus coûteuses, un compromis sous-jacent.
Dans les commentaires
Débat limité en substance. Les critiques portent principalement sur l'accessibilité (erreurs SSL) et la rigueur historique (confusion entre la généalogie des arènes et le rôle spécifique de jemalloc), plus que sur le contenu technique lui-même.
- Le site affiche une erreur SSL restrictive (accepte uniquement ChaCha20/Poly1305), bloquant Chromium et certains navigateurs, ce qui a distrait une partie du fil des commentaires de la technique.
- Un commentateur relève deux erreurs factuelles : l'affirmation d'ouverture sur la sérialisation complète des allocateurs modernes est trop forte (contredite ensuite dans l'article) ; jemalloc n'a pas inventé les arènes (concept des années 1960-1990, terme du jemalloc depuis ~2005, non 2006).
- Un développeur rapporte un retour d'expérience prosaïque : remplacer l'allocateur dans une application réelle a produit un gain négligeable, malgré les différences théoriques visibles dans les tableaux comparatifs.
- Absence d'analyse sur le passage du theorie aux vrais benchmarks en production : aucun commentateur ne cite de métriques concrètes de speedup observées.
Notre lecture
Article utile comme référence structurée des allocateurs, mais entrâvé par des problèmes d'accessibilité (SSL) et d'imprécision historique qui nuisent à la crédibilité. Le tableau comparatif (11 allocateurs, contention CAS, NUMA) est le point fort ; les affirmations sur la performance des allocateurs modernes manquent de benchmarks concrets. Pour une DSI ou un tech lead : intéressant pour comprendre pourquoi mimalloc ou jemalloc peut améliorer un programme en forte contention, mais tester en conditions réelles reste obligatoire (le gap théorie-pratique est large, selon les retours du fil). Pas d'action immédiate sauf si vous gérez des systèmes haute performance ou haute concurrence.