Don't use musl if you care about performance

jjbellis about 3 hours ago 18 commentsRead Article on blog.brokk.ai

FR version is available. Content is displayed in original English for accuracy.

⚡ Community Insights

Discussion Sentiment

38% Positive

Analyzed from 579 words in the discussion.

Discussion (18 Comments)Read Original on HackerNews

marssaxman•about 2 hours ago

People have such different perspectives. 26% slower does not sound "terrible" to me; it sounds like quite a reasonable price one might choose to pay for the convenience musl offers. If musl's allocator were 2.6x slower, I might call that "not so great"... but in order to qualify as "terrible" I think the difference would have to be an order of magnitude!

loeg•about 1 hour ago

The 26% number at the top of the article is from using mimalloc (which is a high performance allocator, at least as fast as the glibc allocator) + musl for some task, and the slowdown is coming from (probably) slow musl implementations of memcpy/memset. The musl allocator is even worse.

Joker_vD•34 minutes ago

> the slowdown is coming from (probably) slow musl implementations of memcpy/memset.

It's wild that such a fundamental piece of code (you can't really implement operation on structs without those) is library-supplied. I wish compilers would just have something like __builtin_memcpy and __builtin_memset, and provided some highly optimized, specialist-crafted assembly in those, instead of having to inline the library code and hopefully be able to optimize it.

kvuj•20 minutes ago

Maybe you're being sarcastic, but I'm pretty sure clang + gcc do offer these.

The problems at first glance :

- Not having control over the implementation detail of the interface that your library provides is probably not wise. Sounds like a lot of bad bug reports and edge cases that you have no control over.

- Not all compilers may provide these.

fwsgonzo•31 minutes ago

You can fix both issues with an LLM in less than a day in a fork. Or just pick one that already did.

There is no longer any good reason for software to be slow.

stackskipton•16 minutes ago

Ops here, I think if you NEED that convenience, sure, rock with MUSL BUT I also see a ton of devs crowing about using MUSL on my 128GB x86 Kubernetes hosts. I have plenty of Disk Space, you can ship glibc based container.

bloppe•about 1 hour ago

This is only one aspect of "performance". glibc's allocator may be faster, but it also uses more memory.

For a much more technical discussion, see https://github.com/sharkdp/fd/issues/710

mattrighetti•about 1 hour ago

Posted this the other day but the whole musl allocator thing seems to be well known [0]

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

masklinn•16 minutes ago

Musl's allocator being awful is pretty well known, though mostly in that it's absolutely awful in multithreaded context. TFA points out that musl has a bunch of other noticeably slower functions, which is less well known (though they're also slower by a smaller factor, and they don't worsen as your parallelism increases).

grep_it•about 2 hours ago

I think the size of linked binaries and simplicity were always the main features?

jdc-pub•25 minutes ago

I haven’t dug into why, but for unknown-linux builds on x86, Rust binaries have been substantially smaller on musl than standard dynamic linking to glibc, for me. No idea if I’m doing something wrong or if the handful of cases I tried were all special in some way.

Joker_vD•about 1 hour ago

Yeah... I've recently had a chance to compare how fgets is implemented in both GNU libc and musl, and, well. With glibc, it was a challenge to even find where the fgets's code actually is.

OptionOfT•about 1 hour ago

Are there other options if I want to ship a 'FROM scratch' image with just a single Rust executable, and everything compiled in?

That to me is the main driver for MUSL.

masklinn•7 minutes ago

The best option would be the x86_64-unknown-linux-none target (https://doc.rust-lang.org/nightly/rustc/platform-support/x86...) however it currently a tier 3 with a single maintainer (so it is technically available but unsupported).

If this specific use case is of high interest to you and you have some available bandwidth, contributing to it, maybe becoming a maintainer, and eventually organising a tier 2 MCP would definitely be a good idea.

nazgulsenpai•about 1 hour ago

Same usecase here, I use musl for compiling self contained Nim utilities I use on containers and servers without having to deal with glibc hell.

desdenova•about 1 hour ago

Most of musl's performance issues come from their allocator. Using it with a third party high performance allocator allows you to benefit from static linking with very little performance loss.

loeg•about 1 hour ago

> Most of musl's performance issues come from their allocator. Using it with a third party high performance allocator allows you to benefit from static linking with very little performance loss.

This is addressed and disputed very early in the article. The very first benchmark presented shows a 26% regression using musl + mimalloc, a high-performance 3rd party allocator.

delduca•about 2 hours ago

Also musl is not a complete runtime