Date: Sat, 29 Nov 1997 11:57:55 -0500 (EST) Message-Id: <199711291657.LAA17674@delorie.com> From: DJ Delorie 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? Precedence: bulk > 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 . 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.