RE: [pooma-dev] HOARD memory allocator

[James Crotinger]

I believe Suvas and Sung looked at Hoard back when we were at LANL. Can't remember the details, but there was something about it that they didn't like. Suvas played with a modified version of GLIBC's malloc that maintained a heap per processor, but I don't believe that was ever enabled in a release version of SMARTS.

We've been relying on first-touch and affinity settings to give us locality (when using threads), but we know there are tons of problems with this.

       
        Jim

---------------------------------------------------
James A. Crotinger
Software Research Scientist
Proximation, LLC

-----Original Message-----
From: Allan Stokes [mailto:address@hidden]
Sent: Wednesday, April 18, 2001 3:15 AM
To: Poomadev
Subject: [pooma-dev] HOARD memory allocator

Hi guys,

This link came to my attention via a mathtools.net bulletin.

ftp://ftp.cs.utexas.edu/pub/emery/papers/asplos2000.pdf

From the Abstract
<<
Hoard combines one global heap and per-processor heaps with a novel
discipline that provably bounds memory consumption and has very low
synchronization costs in the common case.  Our results on eleven programs
demonstrate that Hoard yields low average fragmentation and improves overall
program performance over the standard Solaris allocator by up to a factor of
60 on 14 processors, and up to a factor of 18 over the next best allocator
we tested.
>>

http://www.cs.utexas.edu/users/emery/hoard/

Available for download under the LGPL.

I noted in an earlier post that the Pooma pool allocator is not doing much
to consider cache line efficiency.  If we wish to revisit allocation
strategies at some point, it would be worth looking at the design of Hoard
in more detail.

Allan