musl: скрытая цена простоты — до 26% потери производительности

Don't use musl if you care about performance

musl: скрытая цена простоты — до 26% потери производительности

Инженер Jonathan Ellis перевёл свои Rust-проекты на musl ради статической линковки, но обнаружил, что аллокатор musl работает настолько плохо, что даже с mimalloc производительность остаётся на 26% ниже, чем с glibc. Бенчмарки Bifrost показали, что проблема не только в аллокаторе: некоторые стандартные функции работы с памятью в musl также значительно медленнее. Автор предупреждает, что простота musl обходится дорого, и убирает его из Bifrost, оставляя для менее критичных проектов.

Я думаю, musl должен поставляться без аллокатора и заставлять вас выбирать его самостоятельно.
  1. matherial

    Если ваш алгоритм выполняет огромное количество мелких выделений памяти до такой степени, что аллокатор становится узким местом, вы уже делаете это неправильно. Аллокатор неизбежно несёт много накладных расходов, поскольку должен учитывать разнообразные случаи использования, избегать фрагментации и, в идеале, реализовывать различные проверки безопасности. Если вы делаете что-то интенсивное по выделению памяти, вы, вероятно, выделяете и освобождаете много одинаковых структур, и вам было бы лучше взять непрерывный блок памяти и управлять им самостоятельно, специфичным для задачи образом.

    Но реальность такова, что почти никого на самом деле не волнует производительность, потому что вычисления дешевле, чем экспертиза и труд, по крайней мере, в краткосрочной перспективе. Всё становится всё более раздутым и медленным, и мы просто компенсируем это добавлением ядер CPU, гигабайтов и гигагерц.

  2. marssaxman

    У людей такие разные взгляды. Замедление на 26% не звучит для меня как «ужасно»; это звучит как вполне разумная цена, которую можно заплатить за удобство, которое предлагает musl. Если бы аллокатор musl был в 2,6 раза медленнее, я бы назвал это «не очень хорошо»... но чтобы квалифицировать это как «ужасно», я думаю, разница должна быть на порядок!

  3. bloppe

    Это лишь один аспект «производительности». Аллокатор glibc может быть быстрее, но он также использует больше памяти.

    Для гораздо более технического обсуждения см. https://github.com/sharkdp/fd/issues/710

  4. mattrighetti

    Публиковал это на днях, но вся эта тема с аллокатором musl, похоже, хорошо известна [0]

    [0]: https://news.ycombinator.com/item?id=45143347

  5. grep_it

    Я думаю, что размер связанных бинарников и простота всегда были основными особенностями?

Ещё за этот день

2026-08-28