Performance of access type : a tiny mistake in the WikiBook ?

Performance of access type : a tiny mistake in the WikiBook ?

[Hibou57 (Yannick Duchêne)]

Hi folks,

I was looking at the WikiBook, the section about access types.

I do not know it is a tiny mistake or something I did not understood.

http://en.wikibooks.org/wiki/Ada_Programming/Types/access

In one place, it is said “ Depending on the implementation an access
might also render better performance than access all. ” which match
what I had believed for long, but later, there is a list of best to
worst performance comparing access techniques :

“
1) "in" modifier : parameter is passed into the subprogram.
2) "out" modifier : parameter is passed from the subprogram.
3) "in out" modifier : parameter may be modified by the subprogram.
4) access all : access to any (aliased) object.
5) pool access : the access is always within a storage pool and only
checks for not null are performed upon dereference.
6) anonymous access : complex "stack deeps level" checks are needed so
an "anonymous access" can be safely converted from and to an "access
all" or "pool access".
 ”
Pool Access is quoted after Access All, at position 5

Just a detail, but I wonder

Re: Performance of access type : a tiny mistake in the WikiBook ?

[(see below)]

On 07/10/2009 21:59, in article
91ad7397-27a8-4b9d-811e-6e62d485645c@v2g2000vbb.googlegroups.com, "Hibou57
(Yannick Duch�ne)" <yannick_duchene@yahoo.fr> wrote:

> �
> 1) "in" modifier : parameter is passed into the subprogram.
> 2) "out" modifier : parameter is passed from the subprogram.
> 3) "in out" modifier : parameter may be modified by the subprogram.
> 4) access all : access to any (aliased) object.
> 5) pool access : the access is always within a storage pool and only
> checks for not null are performed upon dereference.
> 6) anonymous access : complex "stack deeps level" checks are needed so
> an "anonymous access" can be safely converted from and to an "access
> all" or "pool access".
>  �
> Pool Access is quoted after Access All, at position 5

If that ranking is to be of any use (I'm not convinced that it is),
surely it should indicate the likely effect of the "not null"
and "access constant" options as well.

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Performance of access type : a tiny mistake in the WikiBook ?

[Yannick Duchêne Hibou57]

Hi Bill, and thanks for your reply

On 8 oct, 00:38, "(see below)" <yaldni...@blueyonder.co.uk> wrote:
> surely it should indicate the likely effect of the "not null"
> and "access constant" options as well.
That's a relevant comment indeed
You're right with that point

I came into it because I'm seeking about common performance
considerations. So I've found this article on WikiPedia.

I'm also seeking about informations on the average impact of inlined
in generics. The same WikiBook states it has bad impact on
performance, in the way it prevents the compiler from using code
sharing. But I wonder if it applies only to the actually inlined
methods or to the whole package.

I also wonder about any possible impact of an “ Object :
Object_Type'Class ” procedure/function argument type compared to a
view conversion in the method's body providing its argument type is
Object_Type instead of Object_Type'Class. In short, is there a typical
performance impact if I use (when the choice can be made) an
Object_Type'Class argument type or if I use an Object_Type argument
and a “ My_Type'Class (My_Object) ” inside the body (this latter
question is more related to references as well).

Re: Performance of access type : a tiny mistake in the WikiBook ?

[(see below)]

On 08/10/2009 00:30, in article
31da5154-9739-4ead-8437-aaa5d70dc7e8@h30g2000vbr.googlegroups.com, "Yannick
Duch�ne Hibou57" <yannick_duchene@yahoo.fr> wrote:

> Hi Bill, and thanks for your reply
> 
> On 8 oct, 00:38, "(see below)" <yaldni...@blueyonder.co.uk> wrote:
>> surely it should indicate the likely effect of the "not null"
>> and "access constant" options as well.
> That's a relevant comment indeed
> You're right with that point
> 
> I came into it because I'm seeking about common performance
> considerations. So I've found this article on WikiPedia.
> 
> I'm also seeking about informations on the average impact of inlined
> in generics. The same WikiBook states it has bad impact on
> performance, in the way it prevents the compiler from using code
> sharing. But I wonder if it applies only to the actually inlined
> methods or to the whole package.
> 
...

Do you have any solid reason to believe that such micromanagement has a
significant effect on your program's performance? If it has, it might well
be contrary to such generalized rules of thumb as the Wikibook propounds.

I have a 14KSLOC program that runs three times as fast when I inline the
appropriate (small, but heavily-used) subprograms.

It runs *half* as fast if I replace the 3-statement body of one of these
subprograms by 2 statements that seem "obviously" more efficient.

The only way to answer such questions is to experiment with the
alternatives, after you've done the really difficult stuff (i.e., getting it
right, for now and for the foreseeable future), and then have a demonstrated
need for better performance.

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Performance of access type : a tiny mistake in the WikiBook ?

[Yannick Duchêne Hibou57]

On 8 oct, 02:30, "(see below)" <yaldni...@blueyonder.co.uk> wrote:
> Do you have any solid reason to believe that such micromanagement has a
> significant effect on your program's performance? If it has, it might well
> be contrary to such generalized rules of thumb as the Wikibook propounds.
>
> I have a 14KSLOC program that runs three times as fast when I inline the
> appropriate (small, but heavily-used) subprograms.
>
> It runs *half* as fast if I replace the 3-statement body of one of these
> subprograms by 2 statements that seem "obviously" more efficient.
>
> The only way to answer such questions is to experiment with the
> alternatives, after you've done the really difficult stuff (i.e., getting it
> right, for now and for the foreseeable future), and then have a demonstrated
> need for better performance.
>
> --
> Bill Findlay
> <surname><forename> chez blueyonder.co.uk
I understand what you mean about testing, but I am mainly looking for
average answers. Just things to know and to have in mind. Even if
there is no required implementation, it is well known that a lot of
compilers share some common implementation designs. I'm seeking for
informations about it, just like the way I'm sometime reading about
general tips or thoughts (I used to do the same with some prior
languages like Pascal and Eiffel, it's a bit part of learning the
thing).

Re: Performance of access type : a tiny mistake in the WikiBook ?

[Dmitry A. Kazakov]

On Wed, 7 Oct 2009 17:48:56 -0700 (PDT), Yannick Duch�ne Hibou57 wrote:

> I understand what you mean about testing, but I am mainly looking for
> average answers.

The average answer is that any static constraint known to hold must be
specified.

Rationale: this weakens the precondition, which the compiler should
otherwise check dynamically, i.e. possibly generate some additional code.

For non-static constraints the rule is opposite, because it strengthens the
precondition.

So:

in before in out
constant before <nothing>
pool specific before general access

But:

not null vs. <nothing> depends on the where that constraint was put
subtype vs. type, ditto
specific type vs. class, ditto

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

Re: Performance of access type : a tiny mistake in the WikiBook ?

[Gautier write-only]

> I understand what you mean about testing, but I am mainly looking for
> average answers. Just things to know and to have in mind. Even if
> there is no required implementation, it is well known that a lot of
> compilers share some common implementation designs. I'm seeking for
> informations about it, just like the way I'm sometime reading about
> general tips or thoughts (I used to do the same with some prior
> languages like Pascal and Eiffel, it's a bit part of learning the
> thing).

So here is my rule: use only "in" (whenever possible), "in out" and
"out" and you will be happy.
These modes are meaningful for you and the compiler knows how to
handle it efficiently. Especially the compiler will consider passing
by copy, even through a register (and not on the stack), an "in"
parameter:

  procedure P_in(i: in Integer; s: in String) is
  begin
    Put_Line(Integer'Image(i));
    Put_Line(s);
  end;

The call P_in(5678,s) is compiled by GNAT GPL 2008 with (-gnatp -O2)
as:

        movl    %edi, %edx
        movl    %esi, %ecx
        movl    $5678, %eax
        call    _test_in_out__p_in.1893
_________________________________________________________
Gautier's Ada programming -- http://sf.net/users/gdemont/
NB: For a direct answer, e-mail address on the Web site!

Re: Performance of access type : a tiny mistake in the WikiBook ?

[Yannick Duchêne Hibou57]

On 8 oct, 11:55, Gautier write-only <gautier_niou...@hotmail.com>
wrote:
> The call P_in(5678,s) is compiled by GNAT GPL 2008 with (-gnatp -O2)
> as:
>
>         movl    %edi, %edx
>         movl    %esi, %ecx
>         movl    $5678, %eax
>         call    _test_in_out__p_in.1893

I was always using the -S option to be passed to GCC, but this was not
building to whole application, so this was not meaningful.

I've just learned the -save-temps is to be used instead : this keep
assembly files *and* build the whole application (providing the
compiler is or is based on GCC)

Otherwise generics does not show anything, this option solve to it.

Do some one have examples from other Ada compilers ? (GNAT is not the
only one).

Re: Performance of access type : a tiny mistake in the WikiBook ?

[Yannick Duchêne Hibou57]

There is also an option named -fverbose-asm which leaves more
informations in the assembly, like some variable names and other more
or less readable stuff, but seemingly no source line numbers. This
help to see interesting things.

Re: Performance of access type : a tiny mistake in the WikiBook ?

[Gautier write-only]

On 8 oct, 18:04, Yannick Duchêne Hibou57 <yannick_duch...@yahoo.fr>:
> Do some one have examples from other Ada compilers ? (GNAT is not the
> only one).

Sure, for instance Aonix ObjectAda 7.2.2 SE (release mode, optim.
level 2) compiles this (P_in defined as above)...
  P_in(i,s);
  P_in(5678,s);
  P_in(6789,"direct!");
into...
   22| 000024 00000000
   22| 000028 8B4D                        MOV    ECX, [EBP-8]
   22| 00002A F8
   22| 00002B 894D                        MOV    [EBP-12], ECX ;  i
   22| 00002D F4
;  Source Line # 23
   23| 00002E 68                          PUSH   __lcl.00000002
   23| 00002F 00000000
   23| 000033 8D55                        LEA    EDX, [EBP-4] ;  s
   23| 000035 FC
   23| 000036 52                          PUSH   EDX
   23| 000037 51                          PUSH   ECX
   23| 000038 E8                          CALL   test_in_out.p_in
   23| 000039 00000000
;  Source Line # 24
   24| 00003D 68                          PUSH   __lcl.00000002
   24| 00003E 00000000
   24| 000042 8D75                        LEA    ESI, [EBP-4] ;  s
   24| 000044 FC
   24| 000045 56                          PUSH   ESI
   24| 000046 68                          PUSH   5678
   24| 000047 2E160000
   24| 00004B E8                          CALL   test_in_out.p_in
   24| 00004C 00000000
;  Source Line # 25
   25| 000050 68                          PUSH   __lcl.00000004
   25| 000051 00000000
   25| 000055 68                          PUSH   __lcl.00000003
   25| 000056 00000000
   25| 00005A 68                          PUSH   6789
   25| 00005B 851A0000
   25| 00005F E8                          CALL   test_in_out.p_in
   25| 000060 00000000
_________________________________________________________
Gautier's Ada programming -- http://sf.net/users/gdemont/
NB: For a direct answer, e-mail address on the Web site!

Re: Performance of access type : a tiny mistake in the WikiBook ?

[Yannick Duchêne Hibou57]

On 8 oct, 21:41, Gautier write-only <gautier_niou...@hotmail.com>
wrote:
> Sure, for instance Aonix ObjectAda 7.2.2 SE (release mode, optim.
> level 2) compiles this (P_in defined as above)...
>   P_in(i,s);
>   P_in(5678,s);
>   P_in(6789,"direct!");
> into...
>    22| 000024 00000000
>    22| 000028 8B4D                        MOV    ECX, [EBP-8]
>    22| 00002A F8
>    22| 00002B 894D                        MOV    [EBP-12], ECX ;  i
>    22| 00002D F4
> ;  Source Line # 23
>    23| 00002E 68                          PUSH   __lcl.00000002
>    23| 00002F 00000000
>    23| 000033 8D55                        LEA    EDX, [EBP-4] ;  s
>    23| 000035 FC
>    23| 000036 52                          PUSH   EDX
>    23| 000037 51                          PUSH   ECX
>    23| 000038 E8                          CALL   test_in_out.p_in
>    23| 000039 00000000
> ;  Source Line # 24
>    24| 00003D 68                          PUSH   __lcl.00000002
>    24| 00003E 00000000
>    24| 000042 8D75                        LEA    ESI, [EBP-4] ;  s
>    24| 000044 FC
>    24| 000045 56                          PUSH   ESI
>    24| 000046 68                          PUSH   5678
>    24| 000047 2E160000
>    24| 00004B E8                          CALL   test_in_out.p_in
>    24| 00004C 00000000
> ;  Source Line # 25
>    25| 000050 68                          PUSH   __lcl.00000004
>    25| 000051 00000000
>    25| 000055 68                          PUSH   __lcl.00000003
>    25| 000056 00000000
>    25| 00005A 68                          PUSH   6789
>    25| 00005B 851A0000
>    25| 00005F E8                          CALL   test_in_out.p_in
>    25| 000060 00000000

Thanks for the Gesture :)

It's a long time I haven't seen a LEA (load effective address) in an
assembly listing

That's strange : the opcode 16#E8# stands for a Call instruction which
is encoded with a relative offset, and the relative offset is always
zero (16#00000000#) here, whatever is the location of the Call
instance. It's funny (there must be a trick somewhere).

Re: Performance of access type : a tiny mistake in the WikiBook ?

[sjw]

On Oct 9, 7:14 am, Yannick Duchêne Hibou57 <yannick_duch...@yahoo.fr>
wrote:
> On 8 oct, 21:41, Gautier write-only <gautier_niou...@hotmail.com>
> wrote:
[..]
> >    25| 00005F E8                          CALL   test_in_out.p_in
> >    25| 000060 00000000
>
> Thanks for the Gesture :)
>
> It's a long time I haven't seen a LEA (load effective address) in an
> assembly listing
>
> That's strange : the opcode 16#E8# stands for a Call instruction which
> is encoded with a relative offset, and the relative offset is always
> zero (16#00000000#) here, whatever is the location of the Call
> instance. It's funny (there must be a trick somewhere).

Presumably it's fixed up at link time.