Testing Memory Allocators: ptmalloc2 vs. tcmalloc vs. hoard vs. jemalloc
1–10 of 43 posts
Re: Testing Memory Allocators: ptmalloc2 vs. tcmalloc vs. hoard vs. jemalloc
#2It would help to generalise the conclusions if a few different types of workloads were tested. Even as simple as a an application with a heavy skew toward lots of small allocations, and same for large allocations.
Re: Testing Memory Allocators: ptmalloc2 vs. tcmalloc vs. hoard vs. jemalloc
#3It would help to generalise the conclusions if a few different types of workloads were tested. Even as simple as a an application with a heavy skew toward lots of small allocations, and same for large allocations.
I think this is a really hard thing to generalize, the broader an attempt would be likely to make mistakes and casual readers would overlook a lot of context sensitive information (OS, OS version, CPU ISA and particular uarch, configuration of policy things like superpages, NUMA, scheduler) that limit applicability outside of the benchmark and run itself. I like the article's conclusion and call to action.
Re: Testing Memory Allocators: ptmalloc2 vs. tcmalloc vs. hoard vs. jemalloc
#4Before a majority of Operating Systems adopted Bonwicks Slab allocator, custom allocators made sense. These days, it's best to let the OS worry about the allocations since it knows about available storage devices (eg. NNVM), cache levels and threads, power management, etc, and it can return overallocated (yet unused) memory which custom allocators cannot.
Re: Testing Memory Allocators: ptmalloc2 vs. tcmalloc vs. hoard vs. jemalloc
#5It would help to generalise the conclusions if a few different types of workloads were tested. Even as simple as a an application with a heavy skew toward lots of small allocations, and same for large allocations.
I think this is a really hard thing to generalize, the broader an attempt would be likely to make mistakes and casual readers would overlook a lot of context sensitive information (OS, OS version, CPU ISA and particular uarch, configuration of policy things like superpages, NUMA, scheduler) that limit applicability outside of the benchmark and run itself. I like the article's conclusion and call to action.
Agreed. The only thing I think you can take from the benchmarks given is that for 99% of cases it's not going to be worth the effort to do your own benchmarks and choose a different allocator, the wins simply aren't going to be big enough.
Re: Testing Memory Allocators: ptmalloc2 vs. tcmalloc vs. hoard vs. jemalloc
#6Before a majority of Operating Systems adopted Bonwicks Slab allocator, custom allocators made sense. These days, it's best to let the OS worry about the allocations since it knows about available storage devices (eg. NNVM), cache levels and threads, power management, etc, and it can return overallocated (yet unused) memory which custom allocators cannot.
On POSIX systems at least, the API provided to userspace to allocate memory is too low level to remove the need for a higher level allocator, so you will be using a separate allocator.
> and it can return overallocated (yet unused) memory which custom allocators cannot.
These allocators allocate memory out of buffers they've gotten from the kernel, so overallocation is very much possible depending on your kernel config.
Re: Testing Memory Allocators: ptmalloc2 vs. tcmalloc vs. hoard vs. jemalloc
#7Before a majority of Operating Systems adopted Bonwicks Slab allocator, custom allocators made sense. These days, it's best to let the OS worry about the allocations since it knows about available storage devices (eg. NNVM), cache levels and threads, power management, etc, and it can return overallocated (yet unused) memory which custom allocators cannot.
On POSIX systems at least, the API provided to userspace to allocate memory is too low level to remove the need for a higher level allocator, so you will be using a separate allocator. > and it can return overallocated (yet unused) memory which custom allocators cannot. These allocators allocate memory out of buffers they've gotten from the kernel, so overallocation is very much possible depending on your kernel conf…
Yep, this two layer approach is also desirable since in userspace you aren't context switching to the kernel all the time and can make some assumptions to avoid certain locking and external fragmentation with the kmem. Short lived allocs are really cheap coming out of i.e. jemalloc arenas and that is important for a lot of programming ergonomics.
Re: Testing Memory Allocators: ptmalloc2 vs. tcmalloc vs. hoard vs. jemalloc
#8glibc malloc has been optimized a lot during the last couple years, mostly to improve multithreaded performance. The work was done by DJ Delorie (of DJGPP fame).
Re: Testing Memory Allocators: ptmalloc2 vs. tcmalloc vs. hoard vs. jemalloc
#9Before a majority of Operating Systems adopted Bonwicks Slab allocator, custom allocators made sense. These days, it's best to let the OS worry about the allocations since it knows about available storage devices (eg. NNVM), cache levels and threads, power management, etc, and it can return overallocated (yet unused) memory which custom allocators cannot.
OS allocators allocate pages, userspace allocators use the OS allocator to allocate bytes.
Re: Testing Memory Allocators: ptmalloc2 vs. tcmalloc vs. hoard vs. jemalloc
#10tcmalloc has a lot of parameters, and the defaults are not suited to any workload I've ever seen, so I'd be interested to know if these knobs were turned for this benchmark. Things like total thread cache size make a huge difference. Also note that the tcmalloc being tested here, from the Debian package, lacks the fast-path improvements released in gperftools 2.6, which represented a roll-up of years of internal Google improvements to tcmalloc.