cvs.gedasymbols.org/archives/browse.cgi   search  
Mail Archives: djgpp/1997/10/30/11:55:45

Message-Id: <m0xQsCl-000S1fC@inti.gov.ar>
Comments: Authenticated sender is <salvador AT natacha DOT inti DOT gov DOT ar>
From: "Salvador Eduardo Tropea (SET)" <salvador AT inti DOT edu DOT ar>
Organization: INTI
To: "John Machin" <sjmachin AT lexicon DOT net DOT au>
Date: Thu, 30 Oct 1997 13:58:34 +0000
MIME-Version: 1.0
Subject: Re: malloc()
CC: djgpp AT delorie DOT com

"John Machin" <sjmachin AT lexicon DOT net DOT au> wrote:
> > "John Machin" <sjmachin AT lexicon DOT net DOT au> wrote:
> > 
> > > As mentioned in some discussions in this list, and in the
> > > comments in malloc.c, the algorithm that is used allocates (or is
> > > supposed to allocate) blocks of size 2^n. Of this, 4 bytes are
> > > overhead. So a malloc(2044) -> 2048-byte block, malloc(2045) ->
> > > 4096-byte block, etc. This means (approximately) an overhead of 0%
> > > to 100% on the requested size, or a waste of 0% to 50% of the memory
> > > grabbed.
> > > 
> > > HOWEVER, experimental results, confirmed by reading the source, show
> > > that the simplistic algorithm has been twiddled for request sizes
> > > over 2044 bytes so that it skews the world by 4096 bytes. The
> > > results are:
> > [snipped values] 
> > You are missing something: If you have enough swap it doesn't matter
> > because the memory that you allocate and don't touch just wastes
> > virtual memory but is well remaped by the DPMI host so your % aren't
> > true. Is hard to say the real waste.
> 
> Oh. I thought if you allocated a page of memory (4096 bytes) and 
> touched only the first byte then it was all mapped ... what is the 
> unit of mapping???
Is 4K, but if you allocate 16384+overhead=16386 => 32768 => 8 pages only 5 will 
be touched and hence the wastage can be messured as 50%.
  
> > > This could be fixed, but I am puzzled why DJ hasn't snarfed a better
> > > malloc from somewhere -- I understand his comments about GNU GPL
> > > that he made in a posting, but what about public-domain stuff???
> > Eli pointed why and I'll point an additional thing:
> > DJGPP's malloc is HYPER fast. I know how it works (I even modified
> > it) and I know how the Borland's one works (I have the sources) and
> > beleive me, in a program that uses heavilly the heap the DJGPP's
> > version is much, MUCH more faster.
> 
> Speed is not the only consideration. 
7 times! that's too much difference.

> Robustness in the face of varied 
> patterns of malloc/free requests may be another consideration for 
> some ... Allocators which don't split/coalesce free blocks can break 
> down if the program allocates a large number of blocks of size x, 
> frees them, allocates/frees ditto sizes y,z, etc (where x,y,z etc 
> belong in different power-of-two buckets) --- unrealistic? No, e.g. 
> program == text editor, x == average len of source file line, y == 
> average len of record in data file1,...

1) Until now only a marginal number of persons experimented real problems with 
it. The fact is that this malloc is working for a long time.
2) My modified version of malloc (is in my site) lets work normally to malloc, 
but when all the memory is allocated it starts to split/join chuncks. I did it 
because I saw problems in my text editor.
 
> > > Pardon me if this has been considered and rejected it for 
> > > reasons that I can't guess, but I'd suggest that "Doug Lea's malloc" 
> > > would be a good substitute. I got it off the web, whacked in a few 
> > > #defines, compiled it, and happiness prevailed; see below which is 
> > > the first few lines of the source file with my changes and his 
> > > "advertisement" and URLs.
> > 
> > I got just a portion of the file.
> > 
> 
> Like I said, "the first few lines of the source file".
Ok, as you can see in my other mail I was able to recreate the file.

Greetings, SET 
------------------------------------ 0 --------------------------------
Visit my home page: http://www.geocities.com/SiliconValley/Vista/6552/
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Alternative e-mail: set-sot AT usa DOT net - ICQ: 2951574
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA
TE: +(541) 759 0013

- Raw text -


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