mimalloc, le petit cheval de bataille mémoire de Microsoft, alimente discrètement l'IA à grande échelle

Dans le monde compétitif des allocateurs mémoire, un projet né au sein d'un laboratoire de Microsoft Research est devenu discrètement un cheval de bataille, non seulement pour les petits environnements d'exécution de langage de programmation, mais aussi pour les services cloud massifs. L'allocateur mimalloc (Microsoft malloc), un remplacement open-source de malloc et free, s'avère particulièrement efficace pour les charges de travail fortement concurrentes et gourmandes en mémoire qui définissent l'informatique moderne, y compris les grands modèles de langage (LLM). open-by-design-ai2-brings-fully-open-ai-infrastructure-online-with-nsf-omai

Développé par le groupe RiSE de Microsoft Research (MSR), mimalloc est apparu pour la première fois en 2020 en tant qu'allocateur rapide pour le prouveur de théorèmes Lean et le langage de programmation Koka, qui utilisent tous deux un comptage de références novateur guidé par le compilateur. Mais sa conception évolutive, ont écrit les chercheurs dans un récent article de blog, a extrêmement bien fonctionné pour les grands services de Microsoft, entraînant des améliorations importantes des temps de réponse pour des services comme Bing, grâce à une coopération étroite avec les équipes produit. microsoft-research-introduces-generative-causal-testing-to-turn-black-box-ai-brain-models-into-readable-theories

Aujourd'hui, mimalloc est largement utilisé à la fois en interne et en externe. Il propulse NoGIL CPython 3.13+, est intégré à Unreal Engine et à des jeux comme Death Stranding, et vit sur GitHub avec plus de 12 000 étoiles. Son wrapper Rust voit à lui seul plus de 100 000 téléchargements par jour. llms-corrupt-your-documents-when-you-delegate-a-close-look-at-the-delegate-52-benchmark

Base de code compacte, invariants solides

Malgré sa large gamme d'utilisation, des petits compilateurs aux services avec des empreintes mémoire dépassant les 500 GiB et des centaines de threads, la base de code de mimalloc reste compacte, autour de 12 000 lignes de C. Le projet met l'accent sur des structures de données internes claires avec des invariants solides, ce qui le rend plus facile à comprendre et à raisonner que de nombreux allocateurs industriels. Cette clarté a aidé à le porter sur Windows, macOS, Linux, FreeBSD, NetBSD, DragonFly et plusieurs consoles de jeu.

« Comme Fred Brooks l'a déjà fait remarquer dans son célèbre livre The Mythical Man-Month : 'Montrez-moi votre organigramme et cachez vos tableaux, et je continuerai à être mystifié. Montrez-moi vos tableaux, et je n'aurai pas besoin de votre organigramme ; ce sera évident,' » ont écrit les chercheurs, expliquant leur philosophie de conception.

Les structures de données transparentes ont également permis à Sam Gross et à d'autres d'adopter mimalloc comme allocateur concurrent pour NoGIL CPython, rendant simple la mise en œuvre du ramasse-miettes cyclique au-dessus de l'allocateur. how-local-llms-like-gemma-and-qwen-are-taming-open-source-repository-triage-at-scale

Chemin rapide avec synchronisation minimale

Au cœur de mimalloc, on trouve des tas thread-local (theaps), un peu comme d'autres allocateurs évolutifs tels que tcmalloc et jemalloc. Chaque thread obtient son propre tas, qui possède un ensemble de pages mimalloc (généralement 64 KiB). Chaque page contient des blocs de taille fixe, triés en classes de taille pour réduire la fragmentation interne. En donnant à chaque thread son propre tas et ses propres pages, l'allocation et la désallocation ne nécessitent généralement aucune synchronisation.

Les opérations atomiques n'interviennent que lorsqu'un thread libère un bloc alloué par un autre thread. En pratique, la plupart des allocations sont minuscules, souvent moins de 1 KiB, et pour celles-ci, mimalloc fournit un chemin incroyablement rapide. La fonction d'allocation principale se résume à seulement quelques instructions x64 avec seulement deux branches peu communes.

De même, mimalloc dispose d'un chemin rapide pour la libération des blocs. La plupart des blocs sont libérés par le thread qui les a alloués, et l'allocateur vérifie si l'ID du thread actuel correspond à l'ID stocké dans la page correspondante. Si c'est le cas, il pousse le bloc sur la liste libre de la page sans verrous ni opérations atomiques. aleph-alpha-builds-theoretical-inference-model-for-deepseek-deriving-performance-from-hardware-primitives

Trois listes libres et inspiration aléatoire

Une idée clé dans la conception de mimalloc est ses trois listes libres par page de 64 KiB : une pour les allocations, une pour les blocs libérés, et une pour les libérations inter-threads. Cela signifie qu'un programme peut facilement avoir des milliers de listes libres, essentielles pour l'évolutivité et la localité du cache.

Les chercheurs se sont inspirés d'algorithmes aléatoires. « De nombreux allocateurs multithreads s'appuient sur des structures de données concurrentes sophistiquées pour synchroniser l'accès aux listes libres partagées. En revanche, mimalloc utilise une liste libre thread-local par page, où n'importe quel thread peut pousser un bloc en utilisant une simple opération atomique compare-and-swap, » ont-ils écrit. « Parce qu'il existe des milliers de telles listes, la probabilité que plusieurs threads libèrent simultanément des blocs vers la même page est faible. En conséquence, la plupart des opérations push sont des mises à jour atomiques sans contention. »

Équilibrer évolutivité et efficacité mémoire

La conception aborde une tension fondamentale : donner à chaque thread une propriété exclusive minimise la synchronisation mais peut gaspiller de la mémoire. À l'autre extrême, partager toutes les pages globalement avec un seul verrou optimise l'utilisation de la mémoire mais tue l'évolutivité.

Les résultats de benchmark illustrent le compromis. L'allocateur système standard a montré une excellente efficacité mémoire (1,1x mémoire allouée par rapport aux données live) mais n'a alloué que 56 GiB sur la période de benchmark. Un autre allocateur hautement concurrent a alloué 262 GiB mais a engagé quatre fois plus de mémoire que les données live, un rapport qui devient inacceptable pour les grandes empreintes.

« Le graphique final montre l'allocateur mimalloc le plus récent. Comme le deuxième allocateur, il alloue 262 GiB sur la durée du benchmark, tout en réduisant la mémoire engagée à 1,3x les données live, ce qui atteint l'évolutivité et un partage mémoire efficace entre les threads, » ont noté les chercheurs.

Cette amélioration provient d'une technique de « vol de page » qui permet aux threads de s'approprier les pages sans synchronisation inter-threads coûteuse, développée en étroite collaboration avec l'équipe Azure Cosmos DB chez Microsoft. L'équipe indique qu'elle publiera bientôt un rapport technique sur ces améliorations. microsoft-open-sources-data-formulator-07-for-enterprise-ai-analytics