Subject: Re: Thread benchmarks, round 2
To: Adam Hamsik <firstname.lastname@example.org>
From: matthew sporleder <email@example.com>
Date: 10/05/2007 11:03:51
On 10/5/07, Adam Hamsik <firstname.lastname@example.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> On Oct 5, 2007, at 3:18 PM, matthew sporleder wrote:
> > On 10/5/07, Kris Kennaway <email@example.com> wrote:
> >> Andrew Doran wrote:
> >>> So, I learned a few things since I put up the previous set of
> >>> benchmarks:
> >>> - The erratic behaviour from Linux is due to the glibc memory
> >>> allocator.
> >>> Using Google's tcmalloc, the problem disappears.
> >> Well you have to be careful there, tcmalloc apparently defers
> >> frees, and
> >> is not really a general purpose malloc. The linux performance
> >> problems
> >> are (were? I haven't tried recent kernels) real though.
> > I don't want to get too into linux tuning for this, but horde is a
> > good alternative to tcmalloc if there are concerns about using
> > tcmalloc in this capacity. (horde also works on solaris, and could
> > probably be ported further)
> Did you mean hoard memory allocator?