Re:Why does musl make my Rust code so slow? (2020)
by kragen on Tuesday December 12, 2023 @05:28PM
(#38619599)
per-thread malloc pools are probably enough to solve this problem and are probably only a few dozen lines of code? i haven't written one so i could be wrong, but it sounds like it might be an acceptable fix to musl
Re:Why does musl make my Rust code so slow? (2020)
by mperham on Tuesday December 12, 2023 @05:57PM
(#38619960)
> probably only a few dozen lines of code
Classic HN.
Re:Why does musl make my Rust code so slow? (2020)
by kragen on Tuesday December 12, 2023 @06:33PM
(#38620357)
i'm guessing you haven't done it either, so you don't have any basis for guessing whether that's an underestimate or an overestimate
'classic hn' in the negative sense is a one-line dismissal containing no reasoning or information. do better
Re:Why does musl make my Rust code so slow? (2020)
by techbrovanguard on Tuesday December 12, 2023 @08:00PM
(#38621238)
hi, i’m _reasonably_ familiar with libcs, specifically glibc and musl. even a cursory investigation would reveal how involved these things are. classic hn.
do better.
Re:Why does musl make my Rust code so slow? (2020)
by kragen on Tuesday December 12, 2023 @08:18PM
(#38621395)
you can of course make malloc arbitrarily complex, and a simple malloc will not be very efficient, but musl's entire malloc/free implementation is only 600 lines of c (`cloc musl-1.1.24/src/malloc`) and even a fair bit of that is no longer actually used (`#if 1 ... #else ... #endif`)
so i don't think a cursory investigation supports your vague innuendo, which seems to be implying that adding thread-local allocation pools to musl would require enormously more than 'a few dozen lines of code', as i said. the entire allocator is 50 dozen lines
the code isn't 'involved'; it's nice and straightforward, except for a clever algorithm or two from hacker's delight. what's involved is debugging it when you break it
Re:Why does musl make my Rust code so slow? (2020)
by intelVISA on Wednesday December 13, 2023 @07:53AM
(#38626624)
Most Good Things are a few dozen lines of code, don't let the Scrum Master fool you.
Re:Why does musl make my Rust code so slow? (2020)
by pcwalton on Wednesday December 13, 2023 @01:05AM
(#38623306)
It's not a few dozen lines of code because of, among other things, the case in which one thread allocates a lot of memory that is then sent to another thread to be freed. This actually happens more frequently than you'd think, because of producer/consumer patterns. In that case stop-the-world synchronization must happen in order to re-balance the pools in order to avoid what are essentially memory leaks. This is complex and is actually fairly similar to garbage collection.
"When it comes to musl, there’s a certain performance trap: its allocator does not perform well in multi-core environments."
"A common cause of the above symptom is thread contention: multiple threads are fighting to acquire the same resource instead of doing useful work. Although it’s better than deadlock or livelock, since the application runs to completion, it’s still a significant waste of CPU."
"The real source of thread contention is in the malloc implementation of musl. A malloc implementation must be thread-safe, as multiple threads may allocate memory at once or even free memory allocated in other threads. Thus, the thread synchronization logic could become a bottleneck.
Although I have not deep-dived into the musl malloc codebase to locate the contention, replacing it with a cutting-edge malloc implementation like mimalloc is sufficient to rectify the problem and enhance performance. Mimalloc minimizes contention and enhances multi-threaded performance. In fact, this replacement can make the application run even faster than the default glibc build."