🚀 go-pugleaf

> In article <45o2n2$o48@gabi.gabi-soft.fr>, kanze@gabi-soft.fr (J. Kanze) writes:
> > There is a proposed extention to C which would do it, a sort of son of
> > noalias.  I don't know any of the details, but I'm sure that a question
> > in comp.std.c would reach people who did, or who could point you in the
> > right direction.

In article dkd@hawk.hcsc.com, bill@amber.ssd.hcsc.com (Bill Leonard) writes:
> I continue to think such extensions are a bad idea.  They basically force
> the compiler to trust the programmer, and historically that is not a
> reliable thing to do.

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.

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.

> ... The original programmer may have been careful to
> avoid aliasing, but what about the 50 other programmers who came later and
> made modifications to the program?  Worse still, you may have a bug lurking
> there for decades until you happen to compile with a compiler that takes
> advantage of the noalias declaration *and* does it in such a way that the
> illegal aliasing changes the behavior of the program.  Such bugs are
> extremely difficult to track down.

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 have a hard time (as do some compilers, apparently) just making sense
of my syntax errors in C++.  From my point of view, they've messed up
the language this much in the pursuit of efficiency, why stop now?
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.  Ask
yourself what other current feature in C++ enables such a speed boost,
under any circumstances?  Of the things that were left out (e.g.,
garbage collection) how did the perceived (better yet, measured) costs
compare with what is being given up here?  What's the very worst
slowdown anyone using the Boehm-Weiser collector has ever observed in a real
application?  I'll bet it's not even a factor of two.

> IMHO, the best answer is improved interprocedural analysis by compilers,
> because that is the safest and also the most optimal -- it detects aliasing
> when it is present, and detects lack of aliasing when it is absent (even if
> the programmer didn't know whether aliasing was present or not).

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.

speaking for myself,

David Chase


---
[ 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. ]