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

In article <fi4taa$ljq$3@xxxxxxxxxxxxxxxxxx>,
jyrki@xxxxxxxxxxxxxxxxxxxxxxx says...
nospam <nospam@xxxxxxxxxxxxxx> wrote:

Given that it takes just a few lines of code to get access to
64MB of RAM in a single big buffer, I see no particular
point in a lot of new() and free(0) or malloc() statements in
a program written for a modern PC.

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?

Since this discussion started about a lexer, at least I find it quite
unlikely that a custom memory allocator can be any faster than a generic
one; a lexer simply needs a generic allocator (unless all the tokens of
the language are, let's say fixed to sizeof(char).. :)).

Hey, memory is cheap. Simple fix each element to a defined maximum
size, say 100 bytes. Then allocate enough memory for an array of
64,000 of those elements. (64,000 * 100 bytes ~= 64MBytes.).
How much simpler than

char *nextptr = &bigbuf[0];


elemptr = &nextptr;
nextptr+= 100;


can your hypothetical generic memory allocator get???
The above two lines of C should compile down to about
two instructions on a 32-bit processor. You can't get
much more efficient than that.


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: ten thousand small processes
    ... "stack and data have different VM protections and, ... >> writing a general purpose malloc is significantly more complicated, ... Calling mallocfor the first time causes a 16K spike in memory usage under ... are wonderful decisions for a memory allocator tuned for a very ...
    (freebsd-performance)
  • Re: malloc options
    ... Malloc was significantly changed with 7.0 and reading through the malloc man page there are a number of flags that can be set with /etc/ malloc.conf. ... If you did recompile it and it is behaving differently then it is probably because your program contains bugs in how it manages memory that happened to be working by accident with the old memory allocator. ...
    (freebsd-questions)
  • Re: malloc options
    ... probably because your program contains bugs in how it manages memory that happened to be working by accident with the old memory allocator. ... e.g. because you were making use of memory after it had been freed, but before the allocator returned it to some other malloc() call. ... Your description looks like a use-after-free bug. ...
    (freebsd-questions)
  • Re: Benchmark: STLs list vs. hand-coded one
    ... if you bother to check the pointer from malloc or use newand throw ... buffer to 640MBytes. ... To support your efficient memory management you limit symbol size to ... Yes you could require the compiler to jump ...
    (comp.arch.embedded)
Loading