4 ms·
This recent blog post explains what happened here: https://www.tweag.io/blog/2023-08-10-rust-static-link-with-mimalloc/ https://www.tweag.io/blog/2023-08-10-rus
by croemer 3y ago
This recent blog post explains what happened here: https://www.tweag.io/blog/2023-08-10-rust-static-link-with-mimalloc/ https://www.tweag.io/blog/2023-08-10-rust-static-link-with-m...
"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."
- kragen 3y agoper-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
- mperham 3y ago> probably only a few dozen lines of code Classic HN.
- kragen 3y agoi'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
- techbrovanguard 3y agohi, 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.
- kragen 3y agoyou 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
- intelVISA 3y agoMost Good Things are a few dozen lines of code, don't let the Scrum Master fool you.
- pcwalton 3y agoIt'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.
- kragen 3y agoaha, thanks. it's true that i was thinking that just adding it to the receiver thread's pool would be sufficient