alloca(), #if, and other controversial things...

[Charles Marslett]

In article <1259 at garth.UUCP>, smryan at garth.UUCP (Steven Ryan) writes:
> Just to keep this fight going.....
> 
> I grew up with Algol 60, where dynamic bounds on arrays provide the
> equivalent of alloca(). I assumed Pascal's nonsense was something
> everybody would recognise as stupid and the next group would take care
> of.
> 
> Oh, well.
> 
> I couldn't care less about losing one register just to get back dynamic
> arrays. (While heap storage includes local storage, heaps are almost
> always slower; using an indirect address instead of a stack base+offset
> screws up the optimiser; remember to release everything at the end
> screws up the programmer. Local storage is a no-fuss, no-bother, no-problem
> solution to a need I have in near most every program I write.)

I have seen this point made many, many times in the "alloca" discussion --
and (having both used very good compilers and written mediocre ones) I find
it hard to believe you believe this.

(1) Heaps are in fact almost always slower than "alloca" -- and they are
    almost always more versatile and only rarely do I need to allocate
    enough items that the speed difference is important.  And then, the
    speed I gain using fixed (static or automatic) arrays beats alloca
    all round the block.

(2) Any alloca implementation that creates an base+offset reference to
    the dynamic stack allocation (for more than 1 alloca call, that is)
    appears to me to be no more efficient than the equivalent registered
    pointer variable (and just as hard to optimize).

(3) As far as ignoring the task of freeing memory -- I would not do this
    even were I using alloca -- this ties the structure of the problem
    code to a detail of the computer architecture (as has been mentioned
    several times before) and the detail is very much tied to traditional
    CISC architecture (that is a single big general purpose stack that is
    freely addressable).  Many studies show this to be a poor use of resources
    (stack access is heavily skewed to the top few locations, and register
    systems usually outperform stack systems when relativly good compilers
    are involved).  Some (many?) RISC processors use sliding stack frames
    and high overhead software stacks to take advantage of these characteristics
    but in the process make alloca code slow and error prone.  Note I did
    not say impossible, just not efficient (and that is the only claim to
    fame I really admit for alloca in the first two points).

Actually, this should probably all be carried on in the comp.philosopy.d
newsgroup (is there one?).  And I have rambled on too long, just like this
discussion (`^}] . . .


Charles Marslett <--- a lover of symmetry
STB Systems, Inc <--- where they don't even use malloc (often)
chasm at killer.dallas.tx.us  <--- where I usually get flamed (deservedly)