Newsgroups: comp.lang.dylan,comp.lang.misc,comp.lang.lisp,comp.object,comp.arch
Path: cantaloupe.srv.cs.cmu.edu!rochester!udel!news.mathworks.com!newsfeed.internetmci.com!nntp-hub2.barrnet.net!olivea!charnel.ecst.csuchico.edu!csusac!csus.edu!netcom.com!NewsWatcher!user
From: hbaker@netcom.com (Henry Baker)
Subject: Re: allocator and GC locality (was Re: cost of malloc)
Message-ID: <hbaker-0408950815320001@192.0.2.1>
Sender: hbaker@netcom16.netcom.com
Organization: nil organization
References: <9507261647.AA14556@aruba.apple.com> <3v8g7l$cge@jive.cs.utexas.edu> <3vac07$ptf@info.epfl.ch> <3vb382$dtr@jive.cs.utexas.edu> <3vbl70$bht@fido.asd.sgi.com> <hbaker-3107951026250001@192.0.2.1> <justin-0108951458440001@158.234.26.212> <hbake <jyuynr@bmtech.demon.co.uk> <hbaker-0208950816000001@192.0.2.1> <jyvgwh@bmtech.demon.co.uk>
Date: Fri, 4 Aug 1995 16:15:32 GMT
Lines: 88
Xref: glinda.oz.cs.cmu.edu comp.lang.dylan:4966 comp.lang.misc:22490 comp.lang.lisp:18552 comp.object:36318 comp.arch:60116

In article <jyvgwh@bmtech.demon.co.uk>, Scott Wheeler
<scottw@bmtech.demon.co.uk> wrote:

> >> In Article <hbaker-0108950939380001@192.0.2.1> Henry Baker writes:
> >> >All you've said, is that if you go along with Stroustrup/Coplien's
> >> >programming styles, you can get the job done, sort of.  However, I
> >> >would argue that following their advice can cost you 3X - 100X in
> >> >performance, because you drive the poor allocator/deallocator 
> crazy.
> >> >Forcing a program to go 2 indirections to access array/string 
> elements
> >> >because C++ has no way to store the length of the array/string 
> along
> >> >with the array/string is probably the most irritatingly obvious
> >> indication of the problem, but the problem is a good deal more
> >> widespread than this.
> >>
> >> Surely you are not claiming that a Pascal/BASIC-type string 
> arrangement
> >> in memory is going to run at least 3x faster than a typical C++ 
> string?
> >> This strains credibility.
> >
> >If you allocate/deallocate these things very often, 3x may be 
> >conservative. You pay some overhead simply accessing the string on a 
> >machine with a longer cache line, because the string header will cause 
> >a cache fault, and proceed to bring in a lot of stuff that won't be 
> >used, followed by an indirection which causes another cache fault when 
> >you start gaining access to the characters themselves.
> >
> >The C++ beginner is sucked in because 1) strings are 0x00 terminated,
> >and therefore don't usually require that the programmer keep separate
> >track of a length, and 2) the actual length of the storage is kept in
> >a 'hidden' location managed by the allocator itself.  Thus, you get
> >another example of hidden overhead that you can't even access yourself
> >-- e.g., to get a rough idea of how big the string is before searching
> >for the 0x00.
> 
> I had assumed from your "2 indirections" that you were talking about 
> C++ strings, not C strings - the former are usually implemented with 
> length stored explicitly, not relying on null termination. Data 
> representation is something like
> 
> class str {
>     int iCount;
>     char *pachData;
> };
> 
> Of course this can mean that the length count and character array 
> pointer are stored separately from the array itself, which was what I 
> thought your complaint was. My reference to Pascal and BASIC was 
> because they are usually implemented similarly but with the count and 
> the character array stored contiguously, avoiding one level of 
> indirection and only allocating one block of memory. Data 
> representation is often something like
> 
> class str {
>     int iCount;
>     char achData[256];
                   ^^^   This is silly.  The usual C solution is:
      char achData[];  /* Whatever length you need */
> };
> 
> with the obvious problems in terms of fixed maximum length of the 
> string.

If you want to be able to increase the size of the string, then you will have
to reallocate the string and store a new pointer into the header.  But
anyone using such 'growable' strings would presumably be ready to pay
this penalty.  

I would contend that the vast majority of strings are not only fixed
length, but _constant_, and since there is no need to grow the string,
there is also no need to force a second indirection.  The problem with
C++ is that there is no sanctioned way to store the length field contiguously
with the characters themselves without a lot of casting to get around
the type system.  You basically have to go back to C mode and perhaps
even call malloc directly.  You lose all of the 'advantages' of the C++
type system and ctors/dtors.

> I am afraid I am now unclear as to what you are saying can be more 
> than 3x faster than the C++ means of handling strings in respect of 
> allocate/deallocate. Can you sketch out your preferred solution, and 
> perhaps we can work out some way of benchmarking it?

-- 
www/ftp directory:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html
