|
Home > Archive > Debian Developers > June 2007 > Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator
|
|
| Russ Allbery 2007-06-22, 1:25 pm |
| Package: wnpp
Severity: wishlist
Owner: Russ Allbery <rra@debian.org>
* Package name : hoard
Version : 3.6.2
Upstream Author : Emery Berger <emery@cs.umass.edu>
* URL : http://www.hoard.org/
* License : GPL (with some docs under Apache 2.0)
Programming Lang: C++
Description : Fast, scalable, and efficient replacement memory allocator
Hoard is a replacement memory allocator that can be used instead of glibc
malloc without recompiling binaries. It is faster and more efficient
under many load patterns than the default glibc malloc, and is particularly
good for multithreaded programs running on multiple processors.
I'm primarily packaging Hoard for use with OpenLDAP, where it increases
performance significantly over the default glibc allocator.
There are some papers included in the upstream source package under
non-free licenses which will be removed in the Debian package.
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.18-4-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steinar H. Gunderson 2007-06-24, 7:27 pm |
| On Fri, Jun 22, 2007 at 09:27:49AM -0700, Russ Allbery wrote:
> Hoard is a replacement memory allocator that can be used instead of glibc
> malloc without recompiling binaries. It is faster and more efficient
> under many load patterns than the default glibc malloc, and is particularly
> good for multithreaded programs running on multiple processors.
What's the downsides? I'd guess that if it's GPLed and not in glibc, there's
a catch somehow.
/* Steinar */
--
Homepage: http://www.sesse.net/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Greenland 2007-06-25, 1:24 am |
| On 24-Jun-07, 17:46 (CDT), "Steinar H. Gunderson" <sgunderson@bigfoot.com> wrote:
> On Fri, Jun 22, 2007 at 09:27:49AM -0700, Russ Allbery wrote:
>
> What's the downsides? I'd guess that if it's GPLed and not in glibc, there's
> a catch somehow.
Without having any knowledge of the specifics of hoard, the phrase
"faster and more efficient under many load patterns" does not eliminate
the possibility of "pathologically horrible behaviour under other load
patterns". Bubble sort works pretty well if the input data is already
sorted :-)
Steve
--
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world. -- seen on the net
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Russ Allbery 2007-06-25, 1:24 am |
| Bernd Zeimetz <bernd@bzed.de> writes:
glibc is not GPL'd. It's LGPL.
[vbcol=seagreen]
> there're also the google perftools[1], which are suppsed to work very
> well and we have libgoogle-perftools in Debian.
Hoard is noticably better for OpenLDAP's load profile than Google
perftools (although both of them annihilate the glibc allocator).
> [2] is very interesting to read in this case. I'd be really interested
> to know why one of those implementations is not the default in glibc,
> and if hoard or perftools provides the better/faster malloc.
> [1] http://sourceforge.net/projects/goog-perftools/
> [2] http://bugs.mysql.com/bug.php?id=27063
Well, I don't know if this is a full explanation, but at least Hoard would
have to be relicensed to LGPL to be included in glibc. It's also written
in C++, which I expect would be a problem.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Russ Allbery 2007-06-25, 1:24 am |
| Steve Greenland <steveg@moregruel.net> writes:
> Without having any knowledge of the specifics of hoard, the phrase
> "faster and more efficient under many load patterns" does not eliminate
> the possibility of "pathologically horrible behaviour under other load
> patterns". Bubble sort works pretty well if the input data is already
> sorted :-)
There is that too.  Hoard is particularly good for applications that
are either multithreaded or that allocate memory once and then use it
frequently. Applications that don't fit either of those profiles may see
little benefit. I don't know if there are pathological cases; I've
personally only used it with OpenLDAP.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|