Date: Wed, 23 Oct 2002 09:59:29 -0700 From: David Schultz <dschultz@uclink.Berkeley.EDU> To: Danny Braniss <danny@cs.huji.ac.il> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, freebsd-hackers@FreeBSD.ORG Subject: Re: malloc Message-ID: <20021023165929.GA7863@HAL9000.homeunix.com> In-Reply-To: <E183svj-000Q0E-00@cse.cs.huji.ac.il> References: <1821.1035206059@critter.freebsd.dk> <E183svj-000Q0E-00@cse.cs.huji.ac.il>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Danny Braniss <danny@cs.huji.ac.il>: > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021023165929.GA7863>