4 ms·

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

by TwoBit 15y ago

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 much. A practical problem we have with Hoard is that it lacks diagnostics. By diagnostics I mean extensive heap reports, fragmentation information, free space, what's the largest block I can safely allocate, give me a callback for every malloc so I can do stats tracking, etc.

scott_s 15y ago
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/ 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.
- onemoreact 15y ago
  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.
  - scott_s 15y ago
    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.

by TwoBit 15y ago

scott_s 15y ago

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/ 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.

onemoreact 15y ago
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.
- scott_s 15y ago
  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.