Re: (glibc's opinion on malloc) Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator

On Mon, Jun 25, 2007 at 08:07:55AM -0700, Russ Allbery wrote: > Oleg Verych <[EMAIL PROTECTED]> writes: > > Message-ID: <[EMAIL PROTECTED]> > > WWW: > The problem with this theory (basically, that glibc is taking a > performance penalty by

Re: (glibc's opinion on malloc) Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator

Gabor Gombas <[EMAIL PROTECTED]> 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 memo

Re: (glibc's opinion on malloc) Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator

On Mon, Jun 25, 2007 at 08:07:55AM -0700, Russ Allbery wrote: > The problem with this theory (basically, that glibc is taking a > performance penalty by giving memory back to the system and hence being > more space efficient) is that not only is Hoard significantly faster than > glibc for OpenLDAP

Re: (glibc's opinion on malloc) Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator

Steinar H Gunderson <[EMAIL PROTECTED]> writes: > On Mon, Jun 25, 2007 at 08:07:55AM -0700, Russ Allbery wrote: >> The problem with this theory (basically, that glibc is taking a >> performance penalty by giving memory back to the system and hence being >> more space efficient) is that not only is

Re: (glibc's opinion on malloc) Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator

On Mon, Jun 25, 2007 at 08:07:55AM -0700, Russ Allbery wrote: > The problem with this theory (basically, that glibc is taking a > performance penalty by giving memory back to the system and hence being > more space efficient) is that not only is Hoard significantly faster than > glibc for OpenLDAP,

Re: (glibc's opinion on malloc) Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator

Oleg Verych <[EMAIL PROTECTED]> writes: > Message-ID: <[EMAIL PROTECTED]> > WWW: The problem with this theory (basically, that glibc is taking a performance penalty by giving memory back to the system and hence being more space efficient)

(glibc's opinion on malloc) Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator

* From: Russ Allbery * Date: Sun, 24 Jun 2007 22:36:21 -0700 * Organization: The Eyrie > > Bernd Zeimetz <[EMAIL PROTECTED]> writes: [] > >> 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 Ope

Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator

Steve Greenland <[EMAIL PROTECTED]> 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

Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator

Bernd Zeimetz <[EMAIL PROTECTED]> writes: >> What's the downsides? I'd guess that if it's GPLed and not in glibc, >> there's a catch somehow. glibc is not GPL'd. It's LGPL. > there're also the google perftools[1], which are suppsed to work very > well and we have libgoogle-perftools in Debian.

Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator

On 24-Jun-07, 17:46 (CDT), "Steinar H. Gunderson" <[EMAIL PROTECTED]> wrote: > 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 > > u

Re: Bug#430140: ITP: hoard -- 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. >>

Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator

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

Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator

Package: wnpp Severity: wishlist Owner: Russ Allbery <[EMAIL PROTECTED]> * Package name: hoard Version : 3.6.2 Upstream Author : Emery Berger <[EMAIL PROTECTED]> * URL : http://www.hoard.org/ * License : GPL (with some docs under Apache 2.0) Programming Lang: