🚀 go-pugleaf

From article <2133:Nov607:16:1090@kramden.acf.nyu.edu>, by brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
< In article <4950@avocado5.UUCP> wallach@motcid.UUCP (Cliff H. Wallach) writes:
<> In article <TED.90Oct26124614@kythera.nmsu.edu> ted@nmsu.edu (Ted Dunning) writes:
<> -if you compile the following code on a sun3 with -O4,
<    [ compiled array code ]
<   [ obviously faster hand code ]
<
< I observe that when I convert the original code into pointer code, the
< compiler produces very similar results to the hand version.
<
< Sure, Jim. Arrays are as efficient as pointers. Uh-huh.

I have never made the claim that arrays _are_ as efficient as
pointers.  I have made the claim that _most_ code I've seen are
_faster_ with arrays.  I've also frequently pointed out that a
_bad_ compiler can make anything happen.  The _basic_ claim I
always make is that there is no reason at the present state of
the art for arrays to ever be slower that the corresponding
pointer implementation.  If a given implementation implements
arrays slower, then it isn't state of the art.

By the way, I frequently make rather strong remarks about the
bad quality of C compilers.  Recently someone has pointed out
that there is a sound reason for it.  Since the optimizations
which I have been discussing are heavily impaired by the presence
of aliasing, and since things are almost always aliased in a
C context, C compiler writers simply don't bother to do those
optimizations.   It seems practical that a technique which is
almost always inhibited is not really worth implementing.  So,
any of you people out there writing C compilers, I apologize
if my remarks offend - there's nothing you can do about it
if the language itself makes it useless to optimize.  Still,
I would expect a truly "production quality" compiler to do
well with arrays - at least, if _I_ have to par for it.

J. Giles