mimalloc разносит glibc в 5 раз

В 2019 году исследователь из Microsoft опубликовал работу «Free List Sharding in Action» и показал: стандартный malloc оставляет большой запас производительности. В качестве drop-in замены он выкатил mimalloc, и бенчмарки оказались жёсткими.

glibc malloc проектировался как универсальный аллокатор под любые сценарии. За универсальность приходится платить. Внутри лежит один глобальный free list на размерный класс, защищённый локом. Под реальной многопоточной нагрузкой все потоки выстраиваются в очередь за одним и тем же замком, и масштабирование умирает.

Фикс простой по идее. Вместо одного большого free list на размерный класс, каждой 64-килобайтной странице выдаётся собственный free list. Плюс на странице живут два отдельных списка: один для освобождений в том же потоке, второй для освобождений, прилетевших из других потоков. Кросс-поточный free превращается в один atomic compare-and-swap без лока, а локальная аллокация вообще не трогает блокировки.

Цифры с бенчмарка larson server: mimalloc в 2,5 раза быстрее tcmalloc и jemalloc под тяжёлой многопоточкой. На Linux он же обгоняет glibc malloc в 5,3 раза и при этом ест на 50% меньше резидентной памяти.

Где это уже работает: Death Stranding, Unreal Engine, NoGIL CPython 3.13, Microsoft Bing. Redis по умолчанию идёт с jemalloc, но на большинстве нагрузок mimalloc выигрывает у него по бенчмаркам.

Fast path в исходниках занимает 7 инструкций на x64 с единственным условным переходом. Комментарий в файле alloc.c так и говорит: «fast path for mi_malloc, in release mode the (inlined) routine is about 7 instructions with a single test».

Источник: https://x.com/TrisH0x2A/status/2058138773578457521