Re:Rust 1.32 released
by weberc2 on Thursday January 17, 2019 @03:51PM
(#18934518)
Can anyone link me to a breakdown of how jemalloc fairs against system allocators wrt Rust? I was of the impression that the standard system allocators had worse fragmentation properties? Is that not true, or is the idea that if you care about fragmentation, you should opt into jemalloc?
[ Parent
| on HN ]
Re:Rust 1.32 released
by jashmatthews on Thursday January 17, 2019 @05:10PM
(#18935144)
Rust doesn't have a runtime so this is almost completely application dependent.
What kinds of things does jemalloc perform better in? What are its "weaknesses"?
Re:Rust 1.32 released
by jashmatthews on Friday January 18, 2019 @05:21AM
(#18938311)
For example, jemalloc 3.x reduces memory usage of CRuby by ~50% and increases throughput by ~10%. It also makes an enormous difference with KV stores like Redis so it's compiled in by default.
Weakness is basically binary size and code complexity.
Re:Rust 1.32 released
by pantalaimon on Friday January 18, 2019 @08:07AM
(#18939014)
Why is jemalloc not included in glibc then?
Re:Rust 1.32 released
by jashmatthews on Friday January 18, 2019 @08:39AM
(#18939179)
jemalloc is the default allocator on FreeBSD. glibc uses ptmalloc for historical reasons.
jemalloc is a strong memory allocator. But I expect that the team felt that most applications don't need to ship their own memory allocator.
An issue that Rust has had to overcome is that it produces bloated binaries by default. Hello World type applications are hundreds of kilobytes long, because they ship jemalloc and libunwind. Removing one of those helps.
There was a mention somewhere that rustc (the compiler itself) still uses jemalloc, glibc 2.24(?) was about 10% slower. Compilers tend to use a lot of small allocations, so most code probably is less affected than that.
I think the big selling point of jemalloc when it appeared was that it was much better for multithreaded applications. But since then glibc has improved a lot in this area, and nowadays has a similiar design with per-thread pools etc.