Live data from Hacker News

Why does musl make my Rust code so slow?

andygrove.io

21–30 of 77 posts

Re: Why does musl make my Rust code so slow?

#21
post #18

Earlier quoted context omitted.

It's the other way around now, though the post that iou linked is from an earlier period when things worked differently. By default today, Rust programs use the same allocator that C programs use, which I think is provided by libc on Linux, and you have the option of using a custom allocator, like jemalloc. Historically however, all Rust programs used to use jemalloc by default.

I suppose there's no option to link statically against glibc because of the implications with LGPL (static linking triggers additional license clauses).

A key phrase I found googling "rust system allocator" is "provided by the operating system". On Unix, a dynamically linked libc would certainly fit the bill.

On Windows the C runtime is technically provided by the compiler and its runtime, so even that would make sense why they use HeapAlloc from Win32. (It's also common on Windows for different DLLs in the same process to have separate, incompatible libc mallocs, so I guess it might solve that too.)

Re: Why does musl make my Rust code so slow?

#22
post #15

Earlier quoted context omitted.

Benchmarking in Docker in general is a mistake I believe.

You should probably be measuring your app's performance in a production-like environment though.

You should load test in a realistic environment. Comparative benchmarks should be done in a consistent environment.

Re: Why does musl make my Rust code so slow?

#24
post #18

Earlier quoted context omitted.

I suppose there's no option to link statically against glibc because of the implications with LGPL (static linking triggers additional license clauses).

Also, it’s extremely common to leave libc dynamically linked for operational reasons. It’s my understanding that by default Go statically links everything but libc.

Sure. Wasn't suggesting it as the default. Just curious why it wasn't an option.

Re: Why does musl make my Rust code so slow?

#26
post #18

Earlier quoted context omitted.

I suppose there's no option to link statically against glibc because of the implications with LGPL (static linking triggers additional license clauses).

I think it's mainly that glibc has poor support for statically linking.

Ah, okay. Searched a bit, and it apparently requires you to find your own with dns client lookup library, avoid dlopen(), set GCONV_PATH, and so on.

Re: Why does musl make my Rust code so slow?

#27
post #24

Earlier quoted context omitted.

Also, it’s extremely common to leave libc dynamically linked for operational reasons. It’s my understanding that by default Go statically links everything but libc.

Sure. Wasn't suggesting it as the default. Just curious why it wasn't an option.

I always assumed that that’s done for portability reasons, since libc deals with a lot of os specific details.

Re: Why does musl make my Rust code so slow?

#30
post #15
post #4

This actually someone asking and not an investigation and explanation. There isn't even a lot of due diligence to figuring it out - no profiling or resource usage other than CPUs. Also it is musl combined with docker causing a 30x slowdown. If something is running 30x slower from linking in a different libc, I'm guessing it should not be that difficult to narrow down the cause at least a little bit.

Benchmarking in Docker in general is a mistake I believe.

I think it makes sense for software that is intended to run in Docker and frameworks like Kubernetes that use Docker.
Post reply on HN