Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SuperMalloc: A Super Fast Multithreaded Malloc for 64-bit Machines

conf.researchr.org

Post reply on HN
Print view View original

21–30 of 33 posts

Re: SuperMalloc: A Super Fast Multithreaded Malloc for 64-bit Machines

#21

Post by thrownaway2424 »

jws wrote: post #11

I think the significant design decision is that in a 64 bit world, virtual address space is no longer scarce. This allows a simpler implementation, roughly half the code. The micro benchmarks are great, the whole program level benchmarks show nothing earth shaking. But I'll take ok performance and half the code any day.

Can you explain? It seems like the address space is getting more scarce, not less. Several years ago when x86-64 adoption really took off, 48 bits was a lot bigger than the actual amount of memory one might put in a system, but now it isn't (48 bits virtual vs. 40 bits physical).

Re: SuperMalloc: A Super Fast Multithreaded Malloc for 64-bit Machines

#22

Post by collector »

Fast, multicore-scalable, low-fragmentation memory allocation through large virtual memory and global data structures [1]

An allocator that is designed for scalability from the ground up. Similar design to Streamflow (based on so-called spans) that eagerly returns memory (latency-aware) and a backend that also makes use of fragmenting virtual memory, which is plentiful available on 64bit systems.

[1]: http://dl.acm.org/citation.cfm?doid=2814270.2814294

Re: SuperMalloc: A Super Fast Multithreaded Malloc for 64-bit Machines

#24

Post by scott_s »

collector wrote: post #22

Fast, multicore-scalable, low-fragmentation memory allocation through large virtual memory and global data structures [1] An allocator that is designed for scalability from the ground up. Similar design to Streamflow (based on so-called spans) that eagerly returns memory (latency-aware) and a backend that also makes use of fragmenting virtual memory, which is plentiful available on 64bit systems. [1]: http://dl.acm.o…

You all are giving me a lot of reading material.

Re: SuperMalloc: A Super Fast Multithreaded Malloc for 64-bit Machines

#25

Post by scott_s »

halayli wrote: post #23
thrownaway2424 wrote: post #20

Comparison to tcmalloc suspiciously omitted.

Came here to say just that. tcmalloc performs better than jemalloc in various cases.

Interesting - I had noticed the omission, but I had assumed that meant that jemalloc had emerged as the agreed-upon allocator best for production. Are you aware of any recent published experiments with the two?

Re: SuperMalloc: A Super Fast Multithreaded Malloc for 64-bit Machines

#26

Post by jws »

thrownaway2424 wrote: post #21
jws wrote: post #11

I think the significant design decision is that in a 64 bit world, virtual address space is no longer scarce. This allows a simpler implementation, roughly half the code. The micro benchmarks are great, the whole program level benchmarks show nothing earth shaking. But I'll take ok performance and half the code any day.

Can you explain? It seems like the address space is getting more scarce, not less. Several years ago when x86-64 adoption really took off, 48 bits was a lot bigger than the actual amount of memory one might put in a system, but now it isn't (48 bits virtual vs. 40 bits physical).

The algorithm sparsely uses 512MB of virtual address space for its allocation and caches. For each of about 40 sizes, it keeps an array of fixed size blocks, plus a bunch of per thread and per CPU caches.

In a 32bit world, taking 1/4 to 1/8 of the address space would be impolite. In a 64 (or 48) bit world it doesn't matter.

Re: SuperMalloc: A Super Fast Multithreaded Malloc for 64-bit Machines

#27

Post by halayli »

scott_s wrote: post #25
halayli wrote: post #23

Earlier quoted context omitted.

Came here to say just that. tcmalloc performs better than jemalloc in various cases.

Interesting - I had noticed the omission, but I had assumed that meant that jemalloc had emerged as the agreed-upon allocator best for production. Are you aware of any recent published experiments with the two?

tcmalloc is great for small random sized allocations. when using std::string without .reserve() it performed much better from the testing I've done last year.

Re: SuperMalloc: A Super Fast Multithreaded Malloc for 64-bit Machines

#28

Post by thrownaway2424 »

scott_s wrote: post #25
halayli wrote: post #23

Earlier quoted context omitted.

Came here to say just that. tcmalloc performs better than jemalloc in various cases.

Interesting - I had noticed the omission, but I had assumed that meant that jemalloc had emerged as the agreed-upon allocator best for production. Are you aware of any recent published experiments with the two?

I'm not aware of any serious published works. Really the only way to choose an allocator is to try them all on your benchmark workload. Any other benchmarks are likely to be irrelevant.

I think tcmalloc vs. jemalloc is basically a wash. One is written by google people and the other is written by facebook people. Facebook is much more forward about their open source project than is Google, so more people have heard of jemalloc.

Re: SuperMalloc: A Super Fast Multithreaded Malloc for 64-bit Machines

#29

Post by binarycrusader »

thrownaway2424 wrote: post #21
jws wrote: post #11

I think the significant design decision is that in a 64 bit world, virtual address space is no longer scarce. This allows a simpler implementation, roughly half the code. The micro benchmarks are great, the whole program level benchmarks show nothing earth shaking. But I'll take ok performance and half the code any day.

Can you explain? It seems like the address space is getting more scarce, not less. Several years ago when x86-64 adoption really took off, 48 bits was a lot bigger than the actual amount of memory one might put in a system, but now it isn't (48 bits virtual vs. 40 bits physical).

Yes, in the x86 world, things are not as rosy as they could be.

SPARC moved to a 64-bit address space a long time ago. 32 terabytes of memory in a single server? Sure, why not.

But as the other poster pointed out, this really isn't an issue given the approach they've taken, even on x86.

Re: SuperMalloc: A Super Fast Multithreaded Malloc for 64-bit Machines

#30

Post by stass »

thrownaway2424 wrote: post #28
scott_s wrote: post #25

Earlier quoted context omitted.

Interesting - I had noticed the omission, but I had assumed that meant that jemalloc had emerged as the agreed-upon allocator best for production. Are you aware of any recent published experiments with the two?

I'm not aware of any serious published works. Really the only way to choose an allocator is to try them all on your benchmark workload. Any other benchmarks are likely to be irrelevant. I think tcmalloc vs. jemalloc is basically a wash. One is written by google people and the other is written by facebook people. Facebook is much more forward about their open source project than is Google, so more people have heard of…

jemalloc is unaffiliated with FB. It was developed and integrated into FreeBSD and Firefox long before the author started working for Facebook.
Post reply on HN