🚀 go-pugleaf

In article <465q4m$j07@wcap.centerline.com>, chase@centerline.com (David Chase)
 writes:
> I'm not sure that I agree with this.  I haven't been following the
> proposals, but if the annotations appear in the function declaration
> (like const) then I think it ok.  The reason for this is that it
> proclaims, loud and clear, to clients:
> 
>   these arrays had better not overlap.
> 
> and
> 
>   future versions of this code (i.e., recompilations) reserve the right
>   to access these array elements in a different order than they do now.
> 
> or (rephrased)
> 
>   the order in which the elements of the arrays are referenced is an
>   implementation detail; clients should not rely on this.

But programmers, even the best ones, make mistakes.  Now I'd be the first
to agree that no language can prevent programmers from making mistakes, but
I also believe one needs to strike a balance between benefits and cost.
Bugs due to mistakenly declaring an absence of aliasing are extremely
costly to find and fix.

> After all, *I* am perfectly capable of rewriting matrix multiplication
> in a pipelined, register-blocked, cache-blocked style, and any client
> who relied on weird aliasing properties of my original subroutine will
> find his code just as broken as if the compiler had rewritten it.

But will he?  Or will the code work for several years until just the right
data is fed to the program, or until he makes a seemingly innocuous change
to one of the calls to your subroutine?

> True, but why should that matter to users of C or C++ :-).  If I wanted
> reliable code, I'd be using Modula-3, or Ada, or something like that.

I won't try to respond to that. :-)

> Note, too, that when this one wins, it wins big.  Automatic
> vectorization and parallelization and cache-access optimizations can
> yield (I have observed, so have customers of former employers -- in one
> case, a factor of 18) integer-factor performance increases.

Agreed.  But in my opinion it's the wrong solution to the right problem.
If such performance is so important, and we can't wait for compilers to do
it automatically, then let's try to find a solution that doesn't depend on
taking the programmer's word for it.

> Virtual functions?  Decent results (in pointerful languages like C) are just
> now emerging from research land.  C++, what with its virtual functions and
> virtual base classes, is an additional can of worms.  I'd love to be working
> on this problem (I've worked on it in the past) but I wouldn't bet the farm
> on it.

I don't see that virtual functions add so much additional complexity.  Most
performance gains can be obtained if one merely collects the full set of
possible functions called and merge their aliasing information.  One can do
better by propagating type information to narrow the possible set, but I'd
be willing to bet that 90% of the performance gains can be had without
that.

The real problem, as I see it, is managing interprocedural analysis
information efficiently, and converting the C/C++ world to using
compilation systems that rely on global program databases.

-- 
Bill Leonard
Harris Computer Systems Corporation
2101 W. Cypress Creek Road
Fort Lauderdale, FL  33309
Bill.Leonard@mail.hcsc.com

These opinions and statements are my own and do not necessarily reflect the
opinions or positions of Harris Computer Systems Corporation.

------------------------------------------------------------------------------
I feel like I've been sent for and couldn't go, and weren't needed after I
got there.
------------------------------------------------------------------------------
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]