A note on GNAT 3.05 performance

A note on GNAT 3.05 performance

[Robert Dewar]

We have discovered a very significant performance issue in GNAT 3.05. It is
not exactly a bug, but it is certainly a very undesirable inefficiency.

Up to now, we have always arranged that the default calling sequence for
Ada should be the same as C. 

We discovered that there was one respect in which we did not follow this
rule in GNAT 3.04, namely we did not pass records in a manner consistent
with C. In C if you pass a record, a copy is always made, so that the
caller can mess with the record without changing the value in the caller.

So, we "fixed" this "bug".

The trouble is that the result is that all records get copied on calls
to all Ada subprograms. This has pretty significant efficiency consequences.
For example, all unbounded and bounded strings are records. 

Although the result is closer to our pure concept of making C and Ada
calling sequences the same, this clearly will not do. The reason that it
does not affect C much is that it is very unusual in C to pass records,
and it is especially unusual to pass large ones (instead pointers are
almost always passed).

So we will have to back this change out and figure out exactly the best
approach. We will plan to issue a 3.06 version fixing this problem early
next week. 

Sorry for the inconvenience. Note again that this is only a performance
issue, so if you don't have significant performance requirements, or don't
pass records around much, then it won't make a difference, but clearly
enough users are affected that it is worth issuing a new release.

This is one kind of bug that our test suites don't catch -- indeed we
*do* have a test whose fix depends on this undesirable change (it was
made in response to an error report!)

Anyway, I thought I would post this right away, so that perhaps you
might delay picking up 3.05 if you don't urgently need it and wait
the extra few days for 3.06.

Robert Dewar
ACT

Re: A note on GNAT 3.05 performance

[Michael F Brenner]

Is this why djgpp DOS interrupts don't work any more...because
the structure containing the registers is a record type?

Re: A note on GNAT 3.05 performance

[Jerry van Dijk]

Michael F Brenner (mfb@mbunix.mitre.org) wrote:

: Is this why djgpp DOS interrupts don't work any more...because
: the structure containing the registers is a record type?

DOS interrupts work perfectly with GNAT 3.04/5.

Maybe you have been bitten by the changes from djgpp 1.12m4 to 2.0.
Although I find that highly unlikely.

-- 
-----------------------------------------------------------------------
--  Jerry van Dijk       --   e-mail: jerry@jvdsys.nextjk.stuyts.nl  --
--  Banking Consultant   --              Member Team-Ada             -- 
--  Ordina Finance BV    --    Located at Haarlem, The Netherlands   --

Re: A note on GNAT 3.05 performance

[Robert Dewar]

"Michael F Brenner (mfb@mbunix.mitre.org) wrote:

: Is this why djgpp DOS interrupts don't work any more...because
: the structure containing the registers is a record type?
"

The best guess is that this relates to code that improperly assumes
that records are passed by reference. In Ada (and in GNAT) whether
a record is passed by reference or copy is implementatoin dependent
and may change from one version of the compiler to another, or
from one port to another (for example, in some ports, small records
are passed by value in registers).

If you want something passed by reference and your code depends on it,
either use an access parameter (if the value is guaranteed to be non-null)
or an explicit access type. This is the only legitimate way to be sure
that a record is passed by reference.

Re: A note on GNAT 3.05 performance

[progers]

In <dewar.835605407@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes:
>"Michael F Brenner (mfb@mbunix.mitre.org) wrote:
>
>: Is this why djgpp DOS interrupts don't work any more...because
>: the structure containing the registers is a record type?
>"
>
>The best guess is that this relates to code that improperly assumes
>that records are passed by reference. In Ada (and in GNAT) whether
>a record is passed by reference or copy is implementatoin dependent
>and may change from one version of the compiler to another, or
>from one port to another (for example, in some ports, small records
>are passed by value in registers).
>
>If you want something passed by reference and your code depends on it,
>either use an access parameter (if the value is guaranteed to be non-null)
>or an explicit access type. This is the only legitimate way to be sure
>that a record is passed by reference.
>

Or make it limited.

pat
---------------
Patrick Rogers
progers@acm.org

Re: A note on GNAT 3.05 performance

[Robert A Duff]

In article <dewar.835605407@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>If you want something passed by reference and your code depends on it,
>either use an access parameter (if the value is guaranteed to be non-null)
>or an explicit access type. This is the only legitimate way to be sure
>that a record is passed by reference.

6.2 lists several cases where you are guaranteed to get pass-by-ref:
tagged types, limited records, etc.

In most cases, I prefer the explicitness of access types, though (either
access parameters or named access types, as appropriate).

- Bob

Re: A note on GNAT 3.05 performance

[Robert Dewar]

Michael Brenner says

"Is this why djgpp DOS interrupts don't work any more...because
the structure containing the registers is a record type?"

Please report the behavior you are seeing, with an exact example to
report@gnat.com. The folks maintaining the DOS port at ACT do not
read CLA.

Sorry to sound like a broken record on this, but it seems a continual
problem that people post GNAT reports to CLA without copying to 
report@gnat.com. Most of the people at ACT have abandoned reading CLA
(too high a noise to signal ratio), and I don't get on every day
necessarily any more (and I certainly do not forward bug reports
from CLA, since there is no simple way to do that for me while
retaining proper tracking headers, subject lines etc.)

Re: A note on GNAT 3.05 performance

[Dale Pontius]

In article <dewar.835245019@schonberg>,
        dewar@cs.nyu.edu (Robert Dewar) writes:
>We have discovered a very significant performance issue in GNAT 3.05. It is
>not exactly a bug, but it is certainly a very undesirable inefficiency.
>
>Up to now, we have always arranged that the default calling sequence for
>Ada should be the same as C.
>
>We discovered that there was one respect in which we did not follow this
>rule in GNAT 3.04, namely we did not pass records in a manner consistent
>with C. In C if you pass a record, a copy is always made, so that the
>caller can mess with the record without changing the value in the caller.
>
>So, we "fixed" this "bug".
>
>The trouble is that the result is that all records get copied on calls
>to all Ada subprograms. This has pretty significant efficiency consequences.
>For example, all unbounded and bounded strings are records.
>
When I first began looking at Ada, I wondered if if was 'pass by value'
or 'pass by reference'. The answer was, apparently, 'neither and both'.
It seemed to me that Ada was attempting to 'idealize' a concept by
using copy-in/copy-out that it shouldn't be.

Now maintaining copy-in and copy-out will apparently have a performance
penalty, yet changing that aspect to pass-by-reference will not be
consistant with regular 'in' parameter passing.

Are Ada pragmas frozen in concrete the way the rest of the language
is? Is it feasible to make 'pass by copy' and 'pass by reference'
for record parameters adjustable on a pragma basis? Is it desirable?

Thanks,
Dale Pontius
(NOT speaking for IBM)

Re: A note on GNAT 3.05 performance

[Robert Dewar]

Dale said

When I first began looking at Ada, I wondered if if was 'pass by value'
or 'pass by reference'. The answer was, apparently, 'neither and both'.
It seemed to me that Ada was attempting to 'idealize' a concept by
using copy-in/copy-out that it shouldn't be.

   Ada was not doing anything new here. Fortran has also always had an
   implementation defined choice between pass by reference and pass by
   copy for exactly the same reason (efficiency).

Now maintaining copy-in and copy-out will apparently have a performance
penalty, yet changing that aspect to pass-by-reference will not be
consistant with regular 'in' parameter passing.

   Regular in parameter passing allows records to be passed by copy or
   reference, so there is no inconsistency here. The issue was being
   consistent with C by default, there is no problem at the Ada
   semantic level.

Are Ada pragmas frozen in concrete the way the rest of the language
is? Is it feasible to make 'pass by copy' and 'pass by reference'
for record parameters adjustable on a pragma basis? Is it desirable?

   New pragmas can be added (see the features file in the GNAT distribution
   for many interesting ones added to GNAT). We will be implementing all the
   Dec pragmas in the near future, which among other things allow this level
   of control.

   Of course the use of pragma Convention (or Import or Export) will in
   practice control the choice of record passing semantics.

Re: A note on GNAT 3.05 performance

[Norman H. Cohen]

In article <4qm21c$qig@mdnews.btv.ibm.com>, pontius@btv.ibm.com
(Dale Pontius) writes: 

|> When I first began looking at Ada, I wondered if if was 'pass by value'
|> or 'pass by reference'. The answer was, apparently, 'neither and both'.
|> It seemed to me that Ada was attempting to 'idealize' a concept by
|> using copy-in/copy-out that it shouldn't be.

Ada distinguishes the semantic model from the implementation.  The
semantic model is that all parameters are passed by copy-in/copy-out, but
the Ada rules allow this effect to be implemented for composite
parameters using pass by reference.  A pass-by-reference implementation
achieves the effect of a copy-in/copy-out semantic model as long as there
is no aliasing and as long as result parameters are not examined after a
procedure call that propagates an exception.

|> Now maintaining copy-in and copy-out will apparently have a performance
|> penalty, yet changing that aspect to pass-by-reference will not be
|> consistant with regular 'in' parameter passing.

It will be consistent with regular 'in' parameter passing as long as
programmers adhere to the sensible guidelines noted above:  Be careful
about aliasing and regard a subprogram call that propagates an exception
as leaving its out and in out parameters in an undefined state.

The reason GNAT 3.05 used a pass-by-copy IMPLEMENTATION. rather than the
pass-by-reference implementation most Ada compilers use for composites
longer than a word or two, was to be consistent with the implementation
of parameter passing that gcc uses for C.

This is not a problem unique to Ada.  Consider the following C++
declarations: 

   class T { ... };
   void f1 (T x);
   void f2 (T& x);
   void f3 (T* x);

Clearly, in the gcc C++ compiler, f1 must use the C parameter-passing
convention for passing a struct by copy and f3 must use the C
parameter-passing convention for passing a pointer-to-struct by copy.
However, f2 has the SEMANTIC MODEL of passing a struct by reference,
which is almost certainly IMPLEMENTED in the same way as f3.

This is quite close to the Ada situation.  (And the declaration

   void f2 (const T& x);

is quite similar to an Ada in parameter passed by reference.) GNAT simply
has to document that its conventions for passing a record are the same as
those for passing a C++ struct or class by reference.  Even if it were
not for Ada, this would have to be a full-fledged part of the gcc
parameter-passing scheme, even though it does not arise in C.

|> Are Ada pragmas frozen in concrete the way the rest of the language
|> is? Is it feasible to make 'pass by copy' and 'pass by reference'
|> for record parameters adjustable on a pragma basis? Is it desirable?

That was (a small) part of the motivation for access parameters.  If RT
is a record type and you are concerned about the potential inefficiency
of passing RT parameters by copy, and you don't trust your compiler to do
the right thing, you can write

   procedure P (X: access RT);

instead of

   procedure P (X: in RT);

and replace calls such as P(Actual) with P(Actual'Access).  However, this
is not a problem in practice (except momentarily, in GNAT 3.05, but
that's being fixed with alacrity).  Programmers are not encouraged to
engage in this sort of efficiency micromanagement unless there is a known
performance problem that can be shown to be attributable to parameter
passing by copy.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: A note on GNAT 3.05 performance

[Robert Dewar]

Norman said

"That was (a small) part of the motivation for access parameters.  If RT
is a record type and you are concerned about the potential inefficiency
of passing RT parameters by copy, and you don't trust your compiler to do
the right thing,..."

This would be more useful if there were not the restriction that an
access parameter must be non-null. There has even been some discussion
of dropping this (rather arbitrary) restriction for interfaced
subprograms. In practice it means that access parameters are not nearly
as useful as they first seem for interfacing, and that you have to use
named access types anyway.

Note also that an access parameter requires a junk acessibility level
hidden parameter to be passed. This at least one hopes is suppressed
for foriegn conventions.