Hacker News Reader

HNHacker News

Top New Best Ask Show Jobs

Comment by ducktective | Hacker News Reader

Full thread

ducktective·

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

View on HN

These ones found no difference:

http://www.etalabs.net/compare_libcs.html

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-...

These found Musl a bit slower with LTO:

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.

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.

How could anyone who cares about allocator performance be satisfied with glibc's allocator in the first place?

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.

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()?

This is what ChimeraLinux has done.

https://chimera-linux.org/docs/configuration/musl

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.

Reply on news.ycombinator.com