From owner-freebsd-hackers Wed Oct 23 9:59:45 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A52737B401 for ; Wed, 23 Oct 2002 09:59:44 -0700 (PDT) Received: from HAL9000.homeunix.com (12-232-220-15.client.attbi.com [12.232.220.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5CD443E65 for ; Wed, 23 Oct 2002 09:59:43 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.6/8.12.5) with ESMTP id g9NGxT2w008039; Wed, 23 Oct 2002 09:59:29 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id g9NGxTDv008038; Wed, 23 Oct 2002 09:59:29 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Wed, 23 Oct 2002 09:59:29 -0700 From: David Schultz To: Danny Braniss Cc: Poul-Henning Kamp , freebsd-hackers@FreeBSD.ORG Subject: Re: malloc Message-ID: <20021023165929.GA7863@HAL9000.homeunix.com> Mail-Followup-To: Danny Braniss , Poul-Henning Kamp , freebsd-hackers@FreeBSD.ORG References: <1821.1035206059@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thus spake Danny Braniss : > > What a lame program... > > > > If this program is indicative of your real-world work-load, you can > > optimize a lot by getting better programmers. > > > > If it is not indicative, then forget about it. > > i wish i could :-) A non-technical answer to your question is that GNU malloc has special hacks to speed up allocations of 64 bytes or less. FreeBSD malloc does not. The reason people are getting annoyed at you is that allocating memory one word at a time is bad practice anyway, and you shouldn't expect the general-purpose memory allocator to be efficient in this special case. Any microbenchmark is going to expose differences, but that doesn't indicate anything about real-world behavior. For example, you might have noticed in your own test that GNU malloc makes a *huge* waste of space; for every one-word chunk of memory you allocate, it allocates another word to keep track of the allocation. PHKMalloc allocates just one bit in the same case (plus space to keep track of the page directory). You can find a somewhat more thorough comparison of malloc implementations at http://citeseer.nj.nec.com/440671.html . Note that the implementation referred to as GNU malloc in the paper has been replaced by Doug Lea's malloc in glibc (and good riddance!) You'll notice that both PHKMalloc and Lea Malloc do reasonably well in all of the tests, and that they both excel in different conditions. Disclaimer: The paper isn't all that great. The authors incorrectly assume that all of the overhead in their tests is due to fragmentation, but much of it is actually due to the size of the malloc metadata. Moreover, a good analysis is lacking. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message