51–60 of 77 posts
For those curious, Musl's malloc implementation is currently being re-written for higher performance and robustness, see https://github.com/richfelker/mallocng-draft
Do you have any extra readings on the rationale of building their own malloc rather than integrating mimalloc or jemalloc?
Earlier quoted context omitted.
I had the opposite experience. Jemalloc uses a lot less (virtual) memory, especially with multithreaded applications. The glibc allocator wastes quite a lot of memory mappings from a thread and never cleans them up even if a thread only had a burst of allocations (there is an upstream bug open about, they don't consider it a leak)
I was about to say nobody cares about virtual memory usage, but I can see how those who are extremely sensitive to runtime performance might care about page table entries or VMAs. I think most people are more concerned about RSS.
...Not the Intel guy, if anyone else had to pause for a second.
I get that a lot!
Do you have any hobbies that would be out of character for Intel's Andy Grove? I think the world has room for a ficttionalized Andy Grove talking about how to cook french pastries, train bonsai, intermittent fasting, or preparing for a marathon.
Earlier quoted context omitted.
For a long time glibc was maintained by someone who was of the opinion that if you wanted to statically link 3rd party libraries, then you shouldn't be allowed to build binaries.
It's interesting because there is an opposite cult (I believe some prominent plan9 and go people are adherents) that believes dynamic linking should literally not be a thing. I even recall reading some essays that introduction of a dynamic linker was some kind of tragic downfall in Unix history. I think the truth is that both have costs and benefits. Dynamic linking is good for security patches, memory and disk usage…
Earlier quoted context omitted.
Do you have any extra readings on the rationale of building their own malloc rather than integrating mimalloc or jemalloc?
Not any first hand, but reading their principles suggests that simplicity and ease of deployment are probably relevant. https://musl.libc.org/about.html
Earlier quoted context omitted.
Benchmarking in Docker in general is a mistake I believe.
Why? The only overhead you have in Docker is on syscalls (due to permission checks, namespaces, ...), everything else runs at 100% native speed - unlike assisted virtualization (at least IOMMU overhead plus overhead for anything involving the filesystem) or emulated virtualization (obvious overheads here).
That is super dangerous and shook my confidence in Docker.
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.
Yeah, upvoted. 30x slower on 48 core (?) system sounds suspiciously like excessive lock contention (or some other shared resource). Non-NUMA aware allocator (or other code) might also contribute to the issue. Should be fairly easy to investigate.
"Ballista is an experimental distributed compute platform, powered by Apache Arrow, with support for Rust and JVM (Java, Kotlin, and Scala)."
Plus he's got Docker, the Rust library, musl, and jemalloc sometimes. There's no application. All this is just infrastructure.
Musl doesn't do much on its own. But it does do stdio buffering. Could it be that the buffering system is making too many I/O calls, like flushing on every write?
Earlier quoted context omitted.
Do you have any extra readings on the rationale of building their own malloc rather than integrating mimalloc or jemalloc?
well one of the stated goals of musl is to be simple and correct, and all those mallocs are anything but simple
Earlier quoted context omitted.
I was about to say nobody cares about virtual memory usage, but I can see how those who are extremely sensitive to runtime performance might care about page table entries or VMAs. I think most people are more concerned about RSS.
Just wanted to add that I strongly suggest thinking about the correct allocator for your applications and never using "the system allocator". In production context there should never be "a system allocator" anyway. Uninstall libc in prod. Force yourself to make a rational choice of memory allcoator.
When you start to miss the thrill of it :D
Earlier quoted context omitted.
It's interesting because there is an opposite cult (I believe some prominent plan9 and go people are adherents) that believes dynamic linking should literally not be a thing. I even recall reading some essays that introduction of a dynamic linker was some kind of tragic downfall in Unix history. I think the truth is that both have costs and benefits. Dynamic linking is good for security patches, memory and disk usage…
Note also that while it probably is a net-win for security to use dynamic linking, it's not 100% a win. I've seen security vulnerabilities introduced because of upgrades to dependencies.