Re: (glibc's opinion on malloc) Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator
Gabor Gombas <gombasg@sztaki.hu> writes:
> Looking at the links there is no mention what "memory size" means here.
> Is it the amount of RAM mapped, or the amount of memory dirtied?
> Mapping more memory is less important (unless you're running out of
> address space of course). Dirtying more memory is certainly much more
> telling.
I believe it's the amount of memory that's mapped, although I'm not
certain. However, I'm fairly certain that Hoard also has better
performance in terms of how much memory is dirtied, or at least the
locality of memory that's dirtied, since one of the things that Hoard
specifically focuses on doing better than glibc malloc is cache locality.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to:
- References:
- Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator
- From: Russ Allbery <rra@debian.org>
- Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator
- From: "Steinar H. Gunderson" <sgunderson@bigfoot.com>
- Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator
- From: Bernd Zeimetz <bernd@bzed.de>
- Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator
- From: Russ Allbery <rra@debian.org>
- (glibc's opinion on malloc) Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator
- From: Oleg Verych <olecom@flower.upol.cz>
- Re: (glibc's opinion on malloc) Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator
- From: Russ Allbery <rra@debian.org>
- Re: (glibc's opinion on malloc) Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator
- From: Gabor Gombas <gombasg@sztaki.hu>