From: Hibou57 (Yannick Duchêne) on
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
From: (see below) on
On 07/10/2009 21:59, in article
91ad7397-27a8-4b9d-811e-6e62d485645c(a)v2g2000vbb.googlegroups.com, "Hibou57
(Yannick Duch�ne)" <yannick_duchene(a)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


From: Yannick Duchêne Hibou57 on
Hi Bill, and thanks for your reply

On 8 oct, 00:38, "(see below)" <yaldni...(a)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).
From: (see below) on
On 08/10/2009 00:30, in article
31da5154-9739-4ead-8437-aaa5d70dc7e8(a)h30g2000vbr.googlegroups.com, "Yannick
Duch�ne Hibou57" <yannick_duchene(a)yahoo.fr> wrote:

> Hi Bill, and thanks for your reply
>
> On 8 oct, 00:38, "(see below)" <yaldni...(a)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

From: Yannick Duchêne Hibou57 on
On 8 oct, 02:30, "(see below)" <yaldni...(a)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).