Re: Benchmark: STL's list vs. hand-coded one

In article <qi8ek3l0b7shp51a6vgfm036ll43h283i9@xxxxxxx>,
nospam@xxxxxxxxxxxxxx says...
Mark Borgerson <mborgerson@xxxxxxxxxxx> wrote:

In article <easdk3ts6v2hloabfe3n7s9b1qh1b7ruu0@xxxxxxx>,
nospam@xxxxxxxxxxxxxx says...
Mark Borgerson <mborgerson@xxxxxxxxxxx> wrote:

And having 64MB buffer allocated you will need to write your own new(),
free(), or malloc() implementations to manage memory in the buffer and do
you *know* they are going to be more efficient than the library and OS code
you are avoiding?


Hmmm, can you tell me how

myptr = malloc(UNITSIZE1);

can be more efficient than

myptr1 = &bigbuf(Endptr);
Endptr += UNITSIZE1;

Hmm, if you bother to check the pointer from malloc or use new() and throw
an exception when you meet a big enough program instead of producing
garbage or crashing would that be more efficient?


"Big enough program"??? Have you ever seen a program that would need
more than one million symbol table entries of 64 bytes each?
If that isn't enough, spend another $100 on RAM and increase the
buffer to 640MBytes.

To support your efficient memory management you limit symbol size to
something significantly less that 64 characters? What about debug
information? What about tags support requiring all symbol references to be
stored? What about all the other memory a compiler needs? Function and data
structure definitions, call trees for register tracking, optimisation
structures etc, etc, etc are you going to allocate 64 (or 640)MB big
buffers for all these too?

Sure---why not. I see no particular problem with 10 separate 64MByte
buffers, one for each function.

If limiting symbol names to 64 bytes is a problem, just double the
size for that buffer and limit the size to 128 bytes. Or you
could just allocate room for 512,000 symbols of 256 bytes--similar
to the decorated symbol names used in VC++.

In any case, there's no reason the compiler should crash or produce
garbage with your hypothetical large program. The program can
certainly keep track of the number of symbol table entries used
and throw an exception as easily as you could with malloc().

Yes you could require the compiler (and programmer writing it) to jump
through hoops to make up for deficiencies in the memory management system
you are suggesting,

I don't see the deficiencies being any more annoying than those inherent
in malloc() and free(), but then I don't write compilers, but do write
application programs for embedded systems. There, the problems with
malloc() are more significant.


Mark Borgerson


.

Relevant Pages

  • Re: C 99 compiler access
    ... > nm> reliably allocating some piece of memory. ... We're not talking about implementing malloc in portable C - it's part of the ... concern is that library implementations are not implementing the required ... using malloc to allocate the buffer memory. ...
    (comp.lang.c)
  • Re: NTFS - Kernel memory leak in driver for kernel 2.4.28?
    ... I should say that the malloc() succeeds, but the 16mb I need for the ... buffer are not available. ... memory tied up in the inode and dentry cache. ... kernel attempts to use for the dentry/inode cache, or make it much, ...
    (Linux-Kernel)
  • Re: style question,itoa
    ... sensible to have the caller pass in a buffer. ... technically useless malloc and free calls, ... priori when memory allocations would fail. ...
    (comp.unix.programmer)
  • Re: Segmentation fault in mallopt/malloc call
    ... > overflows or buffer underflows, or some other random data corruption. ... > using a memory debugger (e.g. electric fence, ... > a bug in malloc(), ...
    (comp.lang.c)
  • Re: Whats the difference between the heap and the freestore?
    ... your assumption that new and malloc share something ... > What I though was that both new and malloc allocated memory in a common ... still different types and if a compiler chose to make longs 64 bits wide, ... The standard allows for more important differences. ...
    (comp.lang.cpp)