Re: should I be interested in ada?

[robert_dewar@my-dejanews.com]

In article <7ald0t$sb$1@plug.news.pipex.net>,
  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:

> I concede this; it is true.

Well that's a remarkable statement, yes I agree something
being true should be reason to "concede" :-) :-)

> However, I would assert that situations where the
> occurrence of aliasing cannot be disproved are rare, in
> practice. It is moderately unusual for a subprogram to be
> declared which has two parameters of the same type (or
> the same dimensionality and base type), and which
> updates one or both.

Well as I said before, more and more, I suspect you have
not written many large Fortran codes. Certainly in the
Fortran systems I have worked on, this is not "moderately
unusual" it is absolutely typical. Furthermore, this is
not a consequence of the language, but rather it is typical
of numerical codes.

A trivial case would be a transposition of a square matrix
with an input array and an output array. A Fortran compiler
can just assume that the two parameters are not aliased,
but an Ada compiler may not make this assumption (even in
Ada 83, where the rules were vaguer and may have allowed
more liberal assumptions, this one is tricky).

Nick, I assume you are aware of the fairly radical change
between Ada 83 and Ada 95 here. In Ada 83, programs that
whose behavior depended on whether parameters are passed
by reference or value are considered erroneous, but in Ada
95 such programs are merely non-deterministic. This can
actually make the situation worse in Ada 95 (the reason
for the change was that the Ada 83 statement was impossible
to formalize). The history here is odd, the original Ada 83
design was an attempt to copy the freedom of Fortran, but
it did not get it quite right, and in particular, the very
clean Fortran rule on when aliasing is invalid was not
copied. The Fortran rule is that assignment via one path
is erroneous if there is more than one path to a variable.

There is no doubt at all that the aliasing information that
can be gathered in an Ada program is less precise than that
in a corresponding Fortran program in this particular case,
and that this situation arises pretty frequently in
practice (Nick, there was a long discussion of this point
in the design process, but I do not know if clear
documentation of this discussion survives).

What is not clear is how much effect this has in practice.
It is reminiscent of the argument that Ada can get more
precise aliasing information than C, and that therefore
Ada compilers should be able to generate better code than
C compilers, other things being equal.

The trouble is that other things are almost never equal,
and individual optimizations are almost always
disappointing in practice.

I would therefore tend to agree that the bottom line effect
here is probably infrequent, but it may occur in tricky
situations. For example, it is easy for a general
formulation of matrix multiplication to run into trouble:

  type X is array (integer range <>,
                   integer range <>) of float;

  procedure Matrix_Mult (A, B : in X; C : out X);

Now remember the Ada rules here, you cannot assume that
A and B are not aliased with C.

If this aliasing *does* occur, it means that the effect
of the code in the body of Matrix_Mult must reflect the
proper semantics with respect to the ordering of statements
if the parameters are passed by reference.

This can *considerably* restrict the ability of the
compiler to reorder statements. For example, if one of
the multiplications in the processing causes a
Constraint_Error, then we must be able to see that exactly
the "right" set of assignments has occured up to that
point, and we can see that effect on the calling
parameters.

This means that at least theoretically, the Fortran
compiler may have an advantage. As I say, whether this
advantage is important in practice, who knows. But note
that this is VERY different from the point Nick makes.
Nick is claiming that this situation does not arise in
practice, when in fact it does arise very often in
practice. The question is not whether it arises, but
how significant it is when it does arise.


> It is quite possible for the compiler to generate two
> object code versions for such a subprogram (one for
> parameters definitely non-aliased, one for
> otherwise), and call the appropriate one at different
> call sites.

Maybe possible ... practical, no!


> I would be interested if anyone could cite (or show) an
> example of a real world Fortran or Ada program having
> such a subprogram which is called using parameters that
> could be aliased, and where an optimiser is unlikely to
> be able to determine they are not. (I suspect that there
> are such programs, but that they are very rare.)

They are in fact common, I gave two obvious examples here,
but if you want more, look at any large linear algebra
package.

One piece of history here is that when this issue was
discussed (rather extensively) by the DR's, I cannot
remember anyone making Nick's claim that the situation
was uncommon. On the contrary we all agreed it was common,
the issue was

(a) can we figure out clean rules in Ada that would allow
appropriate aliasing assumptions to be made (bottom line
answer, we couldn't, the Fortran approach seemed to
radical, since it invalidated previously valid programs).

(b) is the difference important enough to worry about.
Bootom line answer: probably not, based on the kind of
reasoning given above.


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own