4 ms·

Has there ever been an empirical study on the performance hit of switching from glibc to musl?

IshKebab 2y ago
These ones found no difference: http://www.etalabs.net/compare_libcs.html http://www.etalabs.net/compare_libcs.html https://users.rust-lang.org/t/optimizing-rust-binaries-observation-of-musl-versus-glibc-and-jemalloc-versus-system-alloc/8499 https://users.rust-lang.org/t/optimizing-rust-binaries-obser... This guy found Musl much slower for multithreaded allocation: https://www.linkedin.com/pulse/testing-alternative-c-memory-allocators-pt-2-musl-mystery-gomes/ https://www.linkedin.com/pulse/testing-alternative-c-memory-... These found Musl a bit slower with LTO: https://github.com/vectordotdev/vector/issues/2313 https://github.com/vectordotdev/vector/issues/2313 Except for that LinkedIn one (which feels like it might be a bug), it seems like there isn't really much in it, which is what I'd expect tbh. Kind of like Clang vs GCC. Sometimes one is faster, but probably not by much.
SubjectToChange 2y ago
Not that I'm aware of. However, I would expect large regressions (20%+) in general, e.g. the malloc implementation in musl is famously primitive.
- jeffbee 2y ago
  How could anyone who cares about allocator performance be satisfied with glibc's allocator in the first place?
  - SubjectToChange 2y ago
    Yeah, I suppose that's fair. Still, the musl malloc implementation is just the most infamous example of its subpar performance. Obviously glibc comes with an enormous amount of functionality and performance optimizations. Somewhat unrelated, but I'm looking forward to llvm-libc becoming a practical replacement for musl. I'd love a modern, non-gnu libc implementation that isn't so dogmatic.
- XorNot 2y ago
  To ask a very stupid question: why don't they just replace it with a better one? Aren't allocator functions fairly well studied and by definition have source code already written? What's stopping them being able to just drop-in someething else to provide malloc()?
  - stock_toaster 2y ago
    This is what ChimeraLinux has done. https://chimera-linux.org/docs/configuration/musl https://chimera-linux.org/docs/configuration/musl
pantalaimon 2y ago
It’s often the case that you can trade size for speed - musl tries to be small, glibc tries to be fast. You have to choose one.

These ones found no difference: http://www.etalabs.net/compare_libcs.html http://www.etalabs.net/compare_libcs.html https://users.rust-lang.org/t/optimizing-rust-binaries-observation-of-musl-versus-glibc-and-jemalloc-versus-system-alloc/8499 https://users.rust-lang.org/t/optimizing-rust-binaries-obser... This guy found Musl much slower for multithreaded allocation: https://www.linkedin.com/pulse/testing-alternative-c-memory-allocators-pt-2-musl-mystery-gomes/ https://www.linkedin.com/pulse/testing-alternative-c-memory-... These found Musl a bit slower with LTO: https://github.com/vectordotdev/vector/issues/2313 https://github.com/vectordotdev/vector/issues/2313 Except for that LinkedIn one (which feels like it might be a bug), it seems like there isn't really much in it, which is what I'd expect tbh. Kind of like Clang vs GCC. Sometimes one is faster, but probably not by much.

SubjectToChange 2y ago

Not that I'm aware of. However, I would expect large regressions (20%+) in general, e.g. the malloc implementation in musl is famously primitive.

jeffbee 2y ago
How could anyone who cares about allocator performance be satisfied with glibc's allocator in the first place?
- SubjectToChange 2y ago
  Yeah, I suppose that's fair. Still, the musl malloc implementation is just the most infamous example of its subpar performance. Obviously glibc comes with an enormous amount of functionality and performance optimizations. Somewhat unrelated, but I'm looking forward to llvm-libc becoming a practical replacement for musl. I'd love a modern, non-gnu libc implementation that isn't so dogmatic.
XorNot 2y ago
To ask a very stupid question: why don't they just replace it with a better one? Aren't allocator functions fairly well studied and by definition have source code already written? What's stopping them being able to just drop-in someething else to provide malloc()?
- stock_toaster 2y ago
  This is what ChimeraLinux has done. https://chimera-linux.org/docs/configuration/musl https://chimera-linux.org/docs/configuration/musl

pantalaimon 2y ago

It’s often the case that you can trade size for speed - musl tries to be small, glibc tries to be fast. You have to choose one.