"Hoard is a scalable memory allocator (malloc replacement) for multithreaded applications. Hoard can dramatically improve your application's performance on multiprocessor machines. No changes to your source are necessary; just link it in. Hoard scales linearly up to at least 14 processors. The supported platforms include Linux, Solaris, and Windows NT/2000/XP."
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2006-01-06
I got to work and ran some tests.
Machine: 8 core clovertown 1.6GHz, 8GB ram. gentoo ~amd64
Process:
threaded ortho rectification.
3 pipelines, 8 threads each
- Input IO
- Ray production & solid intersection
- Pixel Rasterization and output tiling.
Test dataset: 210MP input image (smallest I coul find)
Run each data set twice, take second timing.
Process is 64bit optimized. Memory usage numbers are somewhat misleading because of the kernel paging, but hover between 3.2GB & 3.8GB regardless of the allocator.
Interesting observation:
During libhoard runs occasionally the system levels would dramatically spike (seen in both gkrellm2 & htop)
Timing:
default gcc allocator
real 1m19.477s
user 9m10.210s
sys 0m8.993s
hoard:
real 1m9.135s
user 7m23.508s
sys 0m37.102s
tcmalloc:
real 1m2.222s
user 6m58.014s
sys 0m5.032s
Edited 2007-05-29 15:28 UTC
Member since:2006-01-06
Member since:
2007-05-28
Hi,
I just downloaded and tried nedmalloc against a particularly brutal benchmark called "larson" on a dual processor Linux box. With Hoard, its throughput was 790,614 memory operations per second, while with Nedmalloc it was 188,706 ops/sec. Compare to GNU libc (the default allocator), whose throughput was 192,485 ops/sec. In short, Hoard outperforms Nedmalloc by more than a factor of 4X.
I'd be interested to hear what happens with your application.
Best,
-- Emery Berger