Access keyword

Access keyword

[Sébastien]

Hi,

I'd like to know if there is performance issue using the access keyword?

for instance the following code:

package MonTest is

   type Vecteur is
     record
       x: Integer;
       y: Integer;
     end record;

   function Norme(v: in Vecteur) return integer;
   function NormeAccess(v: access Vecteur) return integer;

end MonTest;

package body MonTest is

   function Norme(v: in Vecteur) return integer is
     n: Integer := v.x*v.x + v.y*v.y;
   begin
     return n;
   end Norme;

   function NormeAccess(v: access Vecteur) return integer is
     n: Integer := v.x*v.x + v.y*v.y;
   begin
     return n;
   end NormeAccess;

end MonTest;

Is NormeAccess faster because I'm using access keyword? I read that Ada 
compiler choose if a reference or a value mode is used in the Norme 
function, so it would mean that the access keyword should be used only 
for runtime allocated variable.

Sebastien

Re: Access keyword

[Peter Hermann]

Sebastien <seb.morand@gmail.com> wrote:
> I'd like to know if there is performance issue using the access keyword?

the indirection via access could even be more workload, if any.

A vector is usually an array of many more than 2 elements of
some floating point type (i.e. not integer).

Performance issues are not relevant below a dozen elements.

If a parameter is an array (or a record),
the parameter is handed over by reference, not by value (i.e. copy)
by most compilers.

Re: Access keyword

[Ludovic Brenta]

Sébastien wrote:
> I'd like to know if there is performance issue using the access keyword?
[snipped]
> Is NormeAccess faster because I'm using access keyword?

Have you measured a speed difference, or compared the assembly code
emitted by the compiler?

> I read that Ada
> compiler choose if a reference or a value mode is used in the Norme
> function, so it would mean that the access keyword should be used only
> for runtime allocated variable.

This is correct so, in your example, NormeAccess is unnecessary.
However there are legitimate uses of acces types beyond dymanic memory
allocation. For example a stack-allocated record may contain an access
to another stack-allocated record or array. Another use for access
types is access discriminants, but this is an advanced topic.

--
Ludovic Brenta.

Re: Access keyword

[stefan-lucks]

You should do some bechmarks. My guess is that on any decent compiler with
full optimisation switched on, the two are running at exactly the same
speed.

In general, avoiding the access keyword gives the compiler more options to
optimise the code, so if either function is faster than the other one,
Norme ought to be faster than NormeAccess.

> I read that Ada compiler choose if a reference or a value mode is used
> in the Norme function,

True. You don't need the access keyword to force the compiler to
(internally) using pointers ...

> so it would mean that the access keyword should
> be used only for runtime allocated variable.

This is a good rule of thumb. Actually, there are other legitimate uses of 
the access keyword. But optimising for speed is really bad usage of 
access, and may even fire back (degrade the performance, rather than 
improve it).



-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: Access keyword

[Sébastien]

All of you are rights (I'm sure you had do doubt about it :-) )

I ran some benchmark after posting and the results are significant:

Norme is 50% faster than NormeAccess
Norme is 25% slower than the C equivalent program using pointer

All compilation made with -02.

Sebastien

Re: Access keyword

[Gautier]

S�bastien wrote:

> All of you are rights (I'm sure you had do doubt about it :-) )
> 
> I ran some benchmark after posting and the results are significant:
> 
> Norme is 50% faster than NormeAccess
> Norme is 25% slower than the C equivalent program using pointer
> 
> All compilation made with -02.
> 
> Sebastien

Did you also set the -gnatp (suppress all checks) switch for Ada ?
Otherwise the comparison with C is clunky...

______________________________________________________________
Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: Access keyword

[Sébastien]

> Did you also set the -gnatp (suppress all checks) switch for Ada ?
> Otherwise the comparison with C is clunky...


Correct, I use -gnatVn but it looks like it's not the same (I don't 
inlined anything). With -gnatp, Results are even more suprising:

Norme is as fast as C and 30% faster than NormeAccess.

Sebastien

Re: Access keyword

[Gautier]

> Correct, I use -gnatVn but it looks like it's not the same (I don't 
> inlined anything). With -gnatp, Results are even more suprising:

I suppose you meant -gnatn (-gnatV* switches validity checking).
BTW, -gnatn just allows cross-unit inlining of subprograms that have the pragma 
Inline(...). For inlining inside a unit you can use that pragma (without -gnatn) 
or use -O3 instead of -O2.

> Norme is as fast as C and 30% faster than NormeAccess.

It would be interesting to see the measurements with/without inlining and 
optimisation (-Ox).

______________________________________________________________
Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: Access keyword

[Ludovic Brenta]

Sébastien <seb.morand@gmail.com> writes:
> Correct, I use -gnatVn but it looks like it's not the same (I don't
> inlined anything). With -gnatp, Results are even more suprising:
>
> Norme is as fast as C and 30% faster than NormeAccess.

I don't find this surprising at all.  With -gnatp, the compiler emits
essentially the same object code as for the "equivalent" C program.
Using access values involves dereferencing a pointer multiple times,
so is bound to be slower.

-- 
Ludovic Brenta.

Re: Access keyword

[Adam Beneschan]

On Apr 29, 6:55 am, Sébastien <seb.mor...@gmail.com> wrote:
> Hi,
>
> I'd like to know if there is performance issue using the access keyword?
>
> for instance the following code:
>
> package MonTest is
>
>    type Vecteur is
>      record
>        x: Integer;
>        y: Integer;
>      end record;
>
>    function Norme(v: in Vecteur) return integer;
>    function NormeAccess(v: access Vecteur) return integer;
>
> end MonTest;
>
> package body MonTest is
>
>    function Norme(v: in Vecteur) return integer is
>      n: Integer := v.x*v.x + v.y*v.y;
>    begin
>      return n;
>    end Norme;
>
>    function NormeAccess(v: access Vecteur) return integer is
>      n: Integer := v.x*v.x + v.y*v.y;
>    begin
>      return n;
>    end NormeAccess;
>
> end MonTest;
>
> Is NormeAccess faster because I'm using access keyword?

Something to keep in mind is that "access" parameters require
additional information to be passed, in order to do accessibility
level checking.  For example, suppose the body looked like this:

   type Vec_Acc is access all Vecteur;
   Save_Vec_Acc : Vec_Acc;
   function NormeAccess(v: access Vecteur) return integer is
     n : Integer := v.x*v.x + v.y*v.y;
   begin
     Save_Vec_Acc := Vec_Acc(v);
   end NormeAccess;

Since you can't have a global access variable pointing to a local
variable belonging to some procedure, the program will have to check,
at run time, whether the "v" you passed in points to a global or
local; and this means that whoever calls NormeAccess will also have to
tell it the "accessibility level" of the access that it's passing in.
Now I realize that your NormeAccess doesn't actually do anything like
this with the access, but the compiler isn't going to know that when
it compiles the specification of MonTest, so the accessibility level
will need to be passed in somehow, regardless of whether it will be
used.  This will almost certainly use up a few extra cycles.

                                  -- Adam

Re: Access keyword

[Jeffrey R. Carter]

S�bastien wrote:
> 
> I'd like to know if there is performance issue using the access keyword?

"Premature optimization is the root of all evil."

-- 
Jeff Carter
"Go and boil your bottoms."
Monty Python & the Holy Grail
01

Re: Access keyword

[Maciej Sobczak]

On 29 Kwi, 15:55, Sébastien <seb.mor...@gmail.com> wrote:

> it would mean that the access keyword should be used only
> for runtime allocated variable.

Even this is not true - the subprogram parameter can be passed by
value or by reference even if the actual is an allocated object that
is kept by access variable at the calling site.

The form of subprogram parameter should reflect what the subprogram is
doing with this parameter, not where it might originate from.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: Access keyword

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]

"S�bastien" <seb.morand@gmail.com> wrote in message
news:fv79c8$lik$1@registered.motzarella.org...

> I'd like to know if there is performance issue using the access keyword?

You are actually talking about "access parameters" (the access keyword
occurs in many contexts and the answer is likely to be different in many of
them - it is best to be precise). Yes, it is generally going to be slower,
for the reasons Adam mentioned. It would be possible for a compiler to
optimize away that extra overhead, but it would probably only be practical
if all of the calls and bodies are compiled together.

For this reason and others I recommend that access parameters only be used
in cases where a conventional Ada design would be more complicated. That
almost never happens.

You often need access *types* to implement the bodies of decent
abstractions, but it is rare that they need to be exposed in the interface
in any way.

Anonymous access types (a superset of access parameters) mainly exist in Ada
to make it easier for C++ and Java programmers to move their rotten designs
to Ada. Bah humbug.

                           Randy.

Re: Access keyword

[Gautier]

Randy Brukardt:

> Anonymous access types (a superset of access parameters) mainly exist in Ada
> to make it easier for C++ and Java programmers to move their rotten designs
> to Ada. Bah humbug.

If so, it would be fine for compilers to have a style-check warning saying that 
it is a "retro compatibility feature" that should not be used normally. 
Personally I was stunned the first time I saw Ada code with these anonymous 
access types in parameters. Funny that Ada 2005 reintroduces a design hack of 
the 1960's...

G.

Re: Access keyword

[Maciej Sobczak]

On 29 Kwi, 23:32, "Randy Brukardt" <ra...@rrsoftware.com> wrote:

> Anonymous access types (a superset of access parameters) mainly exist in Ada
> to make it easier for C++ and Java programmers to move their rotten designs
> to Ada.

Anonymous access types are used by Ada.Containers for iteration (among
others). "Rationale" by Barnes presents some nice examples with
downward closures as well.

Please comment on it.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: Access keyword

[Dmitry A. Kazakov]

On Wed, 30 Apr 2008 00:15:47 -0700 (PDT), Maciej Sobczak wrote:

> On 29 Kwi, 23:32, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> 
>> Anonymous access types (a superset of access parameters) mainly exist in Ada
>> to make it easier for C++ and Java programmers to move their rotten designs
>> to Ada.
> 
> Anonymous access types are used by Ada.Containers for iteration (among
> others). "Rationale" by Barnes presents some nice examples with
> downward closures as well.

But most (if not all) of these could certainly be addressed to the language
design faults. One does not need explicit pointers in order to implement
downward closures. The same is true for returning objects by reference.
There is no proper abstraction of array allowing "for Item in Container
loop". The notorious mix-in inheritance is often just a kludge, necessary
because the language lacks multiple inheritance or else, because certain
types (like tasks and protected objects) cannot be inherited from. The
Rosen trick is used because procedures cannot have results. Have I forgot
something?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Access keyword

[Georg Bauhaus]

Maciej Sobczak wrote:
> On 29 Kwi, 23:32, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> 
>> Anonymous access types (a superset of access parameters) mainly exist in Ada
>> to make it easier for C++ and Java programmers to move their rotten designs
>> to Ada.
> 
> Anonymous access types are used by Ada.Containers for iteration (among
> others). "Rationale" by Barnes presents some nice examples with
> downward closures as well.

Aren't these implementation types (needed in the body of an
Integrate procedure, say) rather than types exposed by some
public signature?

Similarly, the Process procedures, passed as access parameters
to Iterate in Ada.Containers, enable referring to parameters of
some surrounding subprogram (the downwards closures you mention
had not been in the original Charles-derived design, which had
started from generics (that cannot refer to parameters)).
So again, these access parameters are good for implementing
things. However, they need not be shown to public clients of
things.

Re: Access keyword

[Adam Beneschan]

On Apr 30, 12:15 am, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> On 29 Kwi, 23:32, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>
> > Anonymous access types (a superset of access parameters) mainly exist in Ada
> > to make it easier for C++ and Java programmers to move their rotten designs
> > to Ada.
>
> Anonymous access types are used by Ada.Containers for iteration (among
> others).

I suspect that Randy was talking only about anonymous access-to-object
parameters.  Those aren't used by the language's definition of
Ada.Containers, or at least I didn't spot any.

Anonymous access-to-subprogram parameters (which Ada.Containers does
use) are a different animal altogether.  They do serve a legitimate
purpose; downward closures are important but couldn't be done
satisfactorily in Ada 95.  In a way, I think that calling this an
"access" parameter is more of a syntax choice than a real "access"
thingy.  Anonymous access-to-subprogram parameters can't be stored in
variables and thus don't really serve the same purposes as other
access types; for that reason, I think the designers could have done
this without an "access" type, simply by saying they would pass a
procedure or function around, as is done in Algol and Pascal, I
believe.  But doing it as an access type fits in well with the
language rules and syntax that already existed in Ada 95.  Just my
humble opinion here...

                                 -- Adam

Re: Access keyword

[Adam Beneschan]

On Apr 30, 12:15 am, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> On 29 Kwi, 23:32, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>
> > Anonymous access types (a superset of access parameters) mainly exist in Ada
> > to make it easier for C++ and Java programmers to move their rotten designs
> > to Ada.
>
> Anonymous access types are used by Ada.Containers for iteration (among
> others). "Rationale" by Barnes presents some nice examples with
> downward closures as well.

I suspect that Randy was talking only about anonymous access-to-object
parameters.  Those aren't used by the language's definition of
Ada.Containers, or at least I didn't spot any.

Anonymous access-to-subprogram parameters (which Ada.Containers does
use) are a different animal altogether.  They do serve a legitimate
purpose; downward closures are important but couldn't be done
satisfactorily in Ada 95.  In a way, I think that calling this an
"access" parameter is more of a syntax choice than a real "access"
thingy.  Anonymous access-to-subprogram parameters can't be stored in
variables and thus don't really serve the same purposes as other
access types; for that reason, I think the designers could have done
this without an "access" type, simply by saying they would pass a
procedure or function around, as is done in Algol and Pascal, I
believe.  But doing it as an access type fits in well with the
language rules and syntax that already existed in Ada 95.  Just my
humble opinion here...

[Apologies if this is a duplicate post... Google Groups, which is
apparently written in C++, was not behaving right...]

                                    -- Adam

Re: Access keyword

[Maciej Sobczak]

On 30 Kwi, 17:20, Adam Beneschan <a...@irvine.com> wrote:

> I suspect that Randy was talking only about anonymous access-to-object
> parameters.

Then I don't really see what kind of "rotten" design they could
possibly support.
The only documented use for them in Ada that I've seen was to simplify
the definition of List_Node-like records. Looks like a reasonable
rationalization. What are the pitfalls?

> Anonymous access-to-subprogram parameters (which Ada.Containers does
> use) are a different animal altogether.  They do serve a legitimate
> purpose

Yes - I was afraid that this legitimate use was considered harmful.

> [Apologies if this is a duplicate post... Google Groups, which is
> apparently written in C++, was not behaving right...]

If we are already trolling, then some correction is in order here. As
far as I know, Google Groups was written in Java and indeed is a crap
(I'm using it as well). When it comes to C++, however, then as far as
I know, it was used for the search engine, which not only works
perfectly and blazing fast, but actually allowed Google to become what
they are - the IT giant - to the point where they can later write
crappy newsgroups system in Java and it's still OK because everybody
uses it anyway. Oh well... ;-)

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: Access keyword

[Adam Beneschan]

On Apr 30, 2:32 pm, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> On 30 Kwi, 17:20, Adam Beneschan <a...@irvine.com> wrote:
>
> > I suspect that Randy was talking only about anonymous access-to-object
> > parameters.
>
> Then I don't really see what kind of "rotten" design they could
> possibly support.
> The only documented use for them in Ada that I've seen was to simplify
> the definition of List_Node-like records.

That would be an anonymous-access type of a record component (which
was added in Ada 2005), not an anonymous-access subprogram parameter
(which was added in Ada 95).

                               -- Adam

Re: Access keyword

[Adam Beneschan]

On Apr 30, 2:32 pm, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> On 30 Kwi, 17:20, Adam Beneschan <a...@irvine.com> wrote:
>
> > I suspect that Randy was talking only about anonymous access-to-object
> > parameters.
>
> Then I don't really see what kind of "rotten" design they could
> possibly support.
> The only documented use for them in Ada that I've seen was to simplify
> the definition of List_Node-like records. Looks like a reasonable
> rationalization. What are the pitfalls?
>
> > Anonymous access-to-subprogram parameters (which Ada.Containers does
> > use) are a different animal altogether.  They do serve a legitimate
> > purpose
>
> Yes - I was afraid that this legitimate use was considered harmful.
>
> > [Apologies if this is a duplicate post... Google Groups, which is
> > apparently written in C++, was not behaving right...]
>
> If we are already trolling, then some correction is in order here. As
> far as I know, Google Groups was written in Java and indeed is a crap
> (I'm using it as well).

Sorry, let me rephrase that:

[Apologies if this is a duplicate post... Google Groups, which is
apparently written in Java which is supposed to be the future of
programming and be totally superior to other existing languages like
Ada in addition to being way more cool, was not behaving right.]

                                 -- Adam

Re: Access keyword

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message
news:2cc577f4-704a-4235-aad4-a29186309c02@k10g2000prm.googlegroups.com...
> On Apr 30, 12:15 am, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
...
> > Anonymous access types are used by Ada.Containers for iteration (among
> > others). "Rationale" by Barnes presents some nice examples with
> > downward closures as well.
>
> I suspect that Randy was talking only about anonymous access-to-object
> parameters.  Those aren't used by the language's definition of
> Ada.Containers, or at least I didn't spot any.
>
> Anonymous access-to-subprogram parameters (which Ada.Containers does
> use) are a different animal altogether.  They do serve a legitimate
> purpose; downward closures are important but couldn't be done
> satisfactorily in Ada 95.

I agree with this, although the syntax is rotten.
Anonymous-access-to-subprogram parameters have special semantics and cannot
be stored (you'll get an accessibility error if you try). So they act like
parameters that are subprograms rather than an access type. I think the
syntax is rotten because these are access types only in the sense that a
compiler will implement them this way.

I do include regular anonymous-access-to-subprogram types in the category of
useless features.

And I do plead guilty to not opposing the expansion of this misfeature in
the Amendment hard enough. I was temporarily swayed by arguments that they
would allow using far fewer useless type conversions. The problem is that in
practice it is not true: you still need type conversions unless you purge
all of your named access types from the program. But then you lose the
ability to have storage pools -- a nasty trade-off. Essentially, they don't
provide the feature that was advertised, and thus should never have been
approved.

Beyond that, I agree with Dmitry that Ada needs a real iterator construct;
passing a subprogram into another subprogram is much less understandable
than
     for Element in Container loop
         ...
     end loop;

And that would eliminate much of the need for "downward closures". (But not
all! I don't want to get into a silly argument about that...)

                              Randy.

Re: Access keyword

[Sébastien]

> You often need access *types* to implement the bodies of decent
> abstractions, but it is rare that they need to be exposed in the interface
> in any way.


I got the point, it's exaclty what happen in some example of chain 
linked implementation, I understood this usage and why they shouldn't be 
used in the way of C/C++ (the world where I come from actually).