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

The Hoard Memory Allocator

hoard.org

Post reply on HN
Print view View original

11–20 of 21 posts

Re: The Hoard Memory Allocator

#11

Post by ZeroGravitas »

maqr wrote: post #2

I see the license is both GPLv2 and proprietary for commercial use. I was unaware that licensing could be done that way. Is that a valid use of GPL?

It's actually GPLv2 or proprietary for "commercial use" at the choice of the user which is reasonably common.

Since "commercial use" can include cases where GPLv2 is acceptable to the user (either because you don't care about handing out the source code e.g. because you're selling expensive hardware or consulting, or because you're running it on a server so the GPL doesn't apply to you) you can't forbid those uses and offer GPL, but you can offer things beyond the GPL (i.e. keeping modifications closed, which is what they're trying to imply with "commercial use").

Re: The Hoard Memory Allocator

#12

Post by gregburd »

Hoard is fine, but if we're going to start talking about various scalable memory allocators designed for concurrent, multi-core/cpu systems then...

libumem is the user space slab memory allocator first available in Solaris 9 (SunOS 5.4) now the default allocator on Solaris (and Illumos, SmartOS, OpenIndiana, etc.). There is a fork of libumem that has been ported to other popular operating systems, such as Linux, Windows and *BSD systems (including Darwin/OSX) by OmniTI (https://labs.omniti.com/labs/portableumem). I maintain a fork of portable libumem (https://github.com/gburd/libumem) that includes changes made by Joyent as part of their ongoing work to improve SmartOS.

I have deployed this allocator to dozens of production systems to improve the performance of highly concurrent memory-intensive applications (such as Riak) and found it to be an excellent, stable and fast allocator.

In addition to fast allocations it includes excellent statistics and memory leak detection (https://blogs.oracle.com/pnayak/entry/finding_memory_leaks_w...) as well as a few different allocator heap-fit algorithm choices.

It is licensed under the CDDL.

Re: The Hoard Memory Allocator

#14

Post by scott_s »

I published a paper about a lock-free allocator back in 2006 that performed very well against Hoard and TCMalloc (http://goog-perftools.sourceforge.net/doc/tcmalloc.html), you can find the paper and source code here: http://people.cs.vt.edu/~scschnei/streamflow/

I think that our techniques worked very well, but TCMalloc is a better engineered allocator. That is, it's production quality code. People have used our allocator in their research projects when they wanted a low-latency, highly scalable allocator, but I'm not aware of anyone using it for production - and I no longer maintain it, so that's probably for the best.

There was recently a paper in PACT last year that extended on our design. Myself and my advisor would like to release a tech report with a more full description of our algorithms and designs, but both of us are busy with our current work.

Re: The Hoard Memory Allocator

#15

Post by scott_s »

TwoBit wrote: post #3

We've looked into Hoard. It's fast only if you have a large number of threads that are -constantly- allocating memory, and even then it wastes more memory than a regular heap. The large majority of real-world applications don't do this, but some server applications might. I think Hoard could be useful for that. On the other hand, if performance was critical to you then you'd change your code to not allocate memory so…

On the other hand, if performance was critical to you then you'd change your code to not allocate memory so much.

This was a problem we ran into with the Streamflow project (http://people.cs.vt.edu/~scschnei/streamflow/). There was no benchmark suite for multithreaded allocators, so we had to pull from HPC benchmark suites, but what's the first optimization many people do when improving an application's performance? Remove dynamic memory allocation.

We were motivated to do our work because of runtimes for multithreaded programming that need to dynamically allocate memory to represent parallel tasks. And I think that motivation remains, but that pain wasn't felt until recently.

Re: The Hoard Memory Allocator

#16

Post by onemoreact »

scott_s wrote: post #15
TwoBit wrote: post #3

We've looked into Hoard. It's fast only if you have a large number of threads that are -constantly- allocating memory, and even then it wastes more memory than a regular heap. The large majority of real-world applications don't do this, but some server applications might. I think Hoard could be useful for that. On the other hand, if performance was critical to you then you'd change your code to not allocate memory so…

On the other hand, if performance was critical to you then you'd change your code to not allocate memory so much. This was a problem we ran into with the Streamflow project ( http://people.cs.vt.edu/~scschnei/streamflow/ ). There was no benchmark suite for multithreaded allocators, so we had to pull from HPC benchmark suites, but what's the first optimization many people do when improving an application's performance…

I don't think the parent post was suggesting you completely avoid dynamic allocation just minimize it. Because it's not a question of dynamic vs static memory but # of allocations / second / thread. And often it's a question of delayed optimization where you suspect what your doing needs to change, but you avoid optimizing until you have some performance data.

Re: The Hoard Memory Allocator

#18

Post by scott_s »

onemoreact wrote: post #16
scott_s wrote: post #15

Earlier quoted context omitted.

On the other hand, if performance was critical to you then you'd change your code to not allocate memory so much. This was a problem we ran into with the Streamflow project ( http://people.cs.vt.edu/~scschnei/streamflow/ ). There was no benchmark suite for multithreaded allocators, so we had to pull from HPC benchmark suites, but what's the first optimization many people do when improving an application's performance…

I don't think the parent post was suggesting you completely avoid dynamic allocation just minimize it. Because it's not a question of dynamic vs static memory but # of allocations / second / thread. And often it's a question of delayed optimization where you suspect what your doing needs to change, but you avoid optimizing until you have some performance data.

I was more talking about the difficulty of testing the performance of a multithreaded dynamic memory allocator. Because moving dynamic memory allocation off the critical path of an application is a common first optimization, it was difficult to find interesting applications to use as benchmarks.

Re: The Hoard Memory Allocator

#19

Post by scott_s »

simonster wrote: post #17

Jason Evans's benchmarks ( http://www.facebook.com/notes/facebook-engineering/scalable-... , 3/4 of the way down the page) don't look good for Hoard, but they may be a little biased.

That's similar to what I found. (See my paper referenced elsewhere in the thread.)

Re: The Hoard Memory Allocator

#20

Post by scott_s »

gregburd wrote: post #12

Hoard is fine, but if we're going to start talking about various scalable memory allocators designed for concurrent, multi-core/cpu systems then... libumem is the user space slab memory allocator first available in Solaris 9 (SunOS 5.4) now the default allocator on Solaris (and Illumos, SmartOS, OpenIndiana, etc.). There is a fork of libumem that has been ported to other popular operating systems, such as Linux, Wind…

Any writeups on the design and algorithms used?
Post reply on HN