www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/11/29/12:00:18

Date: Sat, 29 Nov 1997 11:57:55 -0500 (EST)
Message-Id: <199711291657.LAA17674@delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: crough45 AT amc DOT de
CC: djgpp AT delorie DOT com
In-reply-to: <97Nov29.183752gmt+0100.17026@internet01.amc.de> (message from
Christopher Croughton on Sat, 29 Nov 1997 17:36:07 +0100)
Subject: Re: Alternate malloc?

> Were these other ones (your 'test*') ones which you invented, or other
> available ones which you've kept anonymous so we're not prejudiced?  If
> they're ones you invented, how do these compare to the other ones people
> have talked about on the list/newsgroup?

All the malloc*.c files are my own invention.  No sense replacing
BSD's malloc with yet another copyrighted malloc.  I don't know how
they compare with other published malloc packages.  Try them and see.

> If I'm reading your charts right, it seems that the DJGPP/BSD one is 
> about the fastest but also wastes half the space (although how much 
> it really wastes depends on the paging boundaries; that's not easy to
> calculate).  It seems to me that 'test6' is a fairly good compromise.

test1 is similar in speed to BSD, but wastes slightly less in my
tests.  That may not be the case in "normal" applications, though.
test6 is my other favorite.  I realize it's about 3x slower than
test1, but I don't think the extra overhead is really that significant
in a "normal" application, and it does save a lot of memory.

> Can someone do them on an ix86 platform?  I don't know what a "R5000 SGI"
> is but it doesn't sound like a PC to me <g>.  This could make a difference
> both to the memory overhead and to the speed; the latter will also be
> influenced by the compiler switches (which could optimise some algorithms
> better than others).

SGI is not an intel platform.  I used that for various reasons,
including (1) it's my favorite, (2) there's no chance of my code
crashing the system, and (3) it provides *two* commercial malloc
implementations to test against.  It also happens to be the one with
the web server on it, so I can do my development right in the web
server directory and it's automatically published.

Since I realize my benchmark may not reflect "normal" applications, I
saw no point in trying to get that accurate with my results.  I just
wanted a rough comparison.  The memory overhead results are accurate,
since they rely only on the algorithm itself.  Only the timing results
would depend on the compiler and/or machine you're running on, and I
suspect that the relative values would be similar.  Obviously, the
absolute timings will change as you change CPUs and clock speeds.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019