Child vs nested package : efficiency matter

Child vs nested package : efficiency matter

[Yannick Duchêne (Hibou57)]

Hillo,


For some reasons, I've turned some nested package -- packages nested in  
the body of package -- into a set of child packages instead.

I've noticed the application's execution time is now an average of 125% of  
that of the old implementation.

The implementation did not changed otherwise and is still the same.

What can make invokation of subprograms slower when the subprograms are in  
a child package rather than in a nested package ?

Note: this is with optimization enabled -- with -O -- and both old and new  
implementation was compiled with the same options.

I can't explain that and can't imagine a reason why. That's a mystery to  
me.

Re: Child vs nested package : efficiency matter

[BrianG]

Yannick Duchï¿œne (Hibou57) wrote:
> Hillo,
> 
> 
> For some reasons, I've turned some nested package -- packages nested in 
> the body of package -- into a set of child packages instead.
> 
> I've noticed the application's execution time is now an average of 125% 
> of that of the old implementation.
> 
> The implementation did not changed otherwise and is still the same.
> 
> What can make invokation of subprograms slower when the subprograms are 
> in a child package rather than in a nested package ?
> 
> Note: this is with optimization enabled -- with -O -- and both old and 
> new implementation was compiled with the same options.
> 
> I can't explain that and can't imagine a reason why. That's a mystery to 
> me.
Presuming you're using GNAT (a guess based on your previous posts), 
could using -gnatN (as opposed to -gnatn) help?

--Bg

Re: Child vs nested package : efficiency matter

[Adam Beneschan]

On May 29, 5:56 am, Yannick Duchêne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:
> Hillo,
>
> For some reasons, I've turned some nested package -- packages nested in  
> the body of package -- into a set of child packages instead.
>
> I've noticed the application's execution time is now an average of 125% of  
> that of the old implementation.
>
> The implementation did not changed otherwise and is still the same.
>
> What can make invokation of subprograms slower when the subprograms are in  
> a child package rather than in a nested package ?
>
> Note: this is with optimization enabled -- with -O -- and both old and new  
> implementation was compiled with the same options.
>
> I can't explain that and can't imagine a reason why. That's a mystery to  
> me.

I can't say anything about any particular compiler.  One possibility:
if procedure A calls procedure B, and A and B are in the same source,
a compiler may be able to put the code of B inline in procedure A's
code---i.e. the code for A will include B's code, rather than
including a "call" instruction.  If it does this, then in the process,
it may also to be able to eliminate instructions in B's code that have
no effect on A.  It's a lot harder to do this if A and B are in
different sources, which I'm assuming is happening if you are pulling
code out of a nested package and putting it in a child package.

Again, this is just a wild guess; without knowing anything about your
source, and with my limited knowledge of GNAT, I can't say anything
for certain.

                                       -- Adam

Re: Child vs nested package : efficiency matter

[Yannick Duchêne (Hibou57)]

Le Tue, 01 Jun 2010 17:03:44 +0200, Adam Beneschan <adam@irvine.com> a  
écrit:
> I can't say anything about any particular compiler.  One possibility:
> if procedure A calls procedure B, and A and B are in the same source,
> a compiler may be able to put the code of B inline in procedure A's
> code---i.e. the code for A will include B's code, rather than
> including a "call" instruction.  If it does this, then in the process,
> it may also to be able to eliminate instructions in B's code that have
> no effect on A.  It's a lot harder to do this if A and B are in
> different sources, which I'm assuming is happening if you are pulling
> code out of a nested package and putting it in a child package.
Adam, I've thought about it at that moment, so I've added some pragma  
Inline for the relevant subprograms in the packages specs. This did not  
change anything.

Do you think there are some reasons to believe pragma Inline is not  
properly applied with inter-package subprograms invocations ?

-- 
There is even better than a pragma Assert: a SPARK --# check.
--# check C and WhoKnowWhat and YouKnowWho;
--# assert Ada;
--  i.e. forget about previous premises which leads to conclusion
--  and start with new conclusion as premise.

Re: Child vs nested package : efficiency matter

[Adam Beneschan]

On Jun 1, 8:34 am, Yannick Duchêne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:
> Le Tue, 01 Jun 2010 17:03:44 +0200, Adam Beneschan <a...@irvine.com> a  
> écrit:> I can't say anything about any particular compiler.  One possibility:
> > if procedure A calls procedure B, and A and B are in the same source,
> > a compiler may be able to put the code of B inline in procedure A's
> > code---i.e. the code for A will include B's code, rather than
> > including a "call" instruction.  If it does this, then in the process,
> > it may also to be able to eliminate instructions in B's code that have
> > no effect on A.  It's a lot harder to do this if A and B are in
> > different sources, which I'm assuming is happening if you are pulling
> > code out of a nested package and putting it in a child package.
>
> Adam, I've thought about it at that moment, so I've added some pragma  
> Inline for the relevant subprograms in the packages specs. This did not  
> change anything.
>
> Do you think there are some reasons to believe pragma Inline is not  
> properly applied with inter-package subprograms invocations ?

I can't say.  Different compilers will handle this differently.  The
language standard says that Inline pragmas don't have to be obeyed---
they are just suggestions.

The only real way to tell what's going on is to disassemble the code.

                                -- Adam

Re: Child vs nested package : efficiency matter

[Adam Beneschan]

On May 29, 5:56 am, Yannick Duchêne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:
> Hillo,
>
> For some reasons, I've turned some nested package -- packages nested in  
> the body of package -- into a set of child packages instead.
>
> I've noticed the application's execution time is now an average of 125% of  
> that of the old implementation.
>
> The implementation did not changed otherwise and is still the same.
>
> What can make invokation of subprograms slower when the subprograms are in  
> a child package rather than in a nested package ?
>
> Note: this is with optimization enabled -- with -O -- and both old and new  
> implementation was compiled with the same options.
>
> I can't explain that and can't imagine a reason why. That's a mystery to  
> me.

Something else that occurred to me: In the process of turning the
nested packages into child packages, were there any global variables
declared in the body of the parent package that you had to move to the
spec (probably the private part) so that they would be visible to the
child packages?

                                -- Adam

Re: Child vs nested package : efficiency matter

[Simon Wright]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> Do you think there are some reasons to believe pragma Inline is not
> properly applied with inter-package subprograms invocations ?

First, you may need to use -gnatn or -gnatN and at least -O2 (have to
look up the manual for this).

You could also try the GNAT special pragma Inline_Always.

I've found (powerpc-wrs-vxworks) that inlining can in fact slow things
down. Cache effects, I suppose.

Re: Child vs nested package : efficiency matter

[Yannick Duchêne (Hibou57)]

Le Tue, 01 Jun 2010 20:35:02 +0200, Adam Beneschan <adam@irvine.com> a  
écrit:
> Something else that occurred to me: In the process of turning the
> nested packages into child packages, were there any global variables
> declared in the body of the parent package that you had to move to the
> spec (probably the private part) so that they would be visible to the
> child packages?
No Adam, there was not. There were global variables, but just globals in  
child packages, not in parent package.

I've just found : pragma Inline is not automatically applied, it requires  
the -gnatn option Brian talked about. I though this was automatically done  
when the -O option is present (I rarely use inline, so I was not aware of  
that).

Anyway, I'm interested in your experience: what did occurred to you with  
global variables ?

-- 
There is even better than a pragma Assert: a SPARK --# check.
--# check C and WhoKnowWhat and YouKnowWho;
--# assert Ada;
--  i.e. forget about previous premises which leads to conclusion
--  and start with new conclusion as premise.

Re: Child vs nested package : efficiency matter

[Yannick Duchêne (Hibou57)]

Le Tue, 01 Jun 2010 21:04:44 +0200, Simon Wright <simon@pushface.org> a  
écrit:
> First, you may need to use -gnatn or -gnatN and at least -O2 (have to
> look up the manual for this).
I've just noticed the same a short moment ago, indeed ;)

-- 
There is even better than a pragma Assert: a SPARK --# check.
--# check C and WhoKnowWhat and YouKnowWho;
--# assert Ada;
--  i.e. forget about previous premises which leads to conclusion
--  and start with new conclusion as premise.

Re: Child vs nested package : efficiency matter

[Adam Beneschan]

On Jun 1, 12:09 pm, Yannick Duchêne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:
> Le Tue, 01 Jun 2010 20:35:02 +0200, Adam Beneschan <a...@irvine.com> a  
> écrit:> Something else that occurred to me: In the process of turning the
> > nested packages into child packages, were there any global variables
> > declared in the body of the parent package that you had to move to the
> > spec (probably the private part) so that they would be visible to the
> > child packages?
>
> No Adam, there was not. There were global variables, but just globals in  
> child packages, not in parent package.
>
> I've just found : pragma Inline is not automatically applied, it requires  
> the -gnatn option Brian talked about. I though this was automatically done  
> when the -O option is present (I rarely use inline, so I was not aware of  
> that).
>
> Anyway, I'm interested in your experience: what did occurred to you with  
> global variables ?

It was just a theory.  My thinking was that if you have a global
variable in a package *body* (and no subunits), a compiler can, in
theory, draw some conclusions about how the variable is used, since
there can be no uses of the variable except by subprograms in the
package body, and perhaps perform some optimizations based on that.
This doesn't work if the variable is in the spec (even in the private
part), since the compiler won't know what child packages might be
added later that have access to the variable.  Anyway, this was just a
theory, not really based on any experience.

                                 -- Adam

Re: Child vs nested package : efficiency matter

[Yannick Duchêne (Hibou57)]

Le Tue, 01 Jun 2010 21:44:46 +0200, Adam Beneschan <adam@irvine.com> a  
écrit:
> It was just a theory.  My thinking was that if you have a global
> variable in a package *body* (and no subunits), a compiler can, in
> theory, draw some conclusions about how the variable is used, since
> there can be no uses of the variable except by subprograms in the
> package body, and perhaps perform some optimizations based on that.
> This doesn't work if the variable is in the spec (even in the private
> part), since the compiler won't know what child packages might be
> added later that have access to the variable.  Anyway, this was just a
> theory, not really based on any experience.
While this could be, theoretically, also possible to do global  
optimization (SmallEiffel and its successor SmartEiffel compiler did  
this), compiling a program as a whole.

I understand what you mean, it's obvious.

-- 
There is even better than a pragma Assert: a SPARK --# check.
--# check C and WhoKnowWhat and YouKnowWho;
--# assert Ada;
--  i.e. forget about previous premises which leads to conclusion
--  and start with new conclusion as premise.

Re: Child vs nested package : efficiency matter

[BrianG]

Yannick Duchï¿œne (Hibou57) wrote:
> I've just found : pragma Inline is not automatically applied, it 
> requires the -gnatn option Brian talked about. I though this was 
> automatically done when the -O option is present (I rarely use inline, 
> so I was not aware of that).
> 

Also note that there's a difference between -gnatn and -gnatN.  The 
latter is more thorough.  It's been a while, but I think -gnatN is 
required for multi-unit inlines.

-gnatN breakage was: Child vs nested package : efficiency matter

[Alex R. Mosteo]

Yannick Duchêne (Hibou57) wrote:

> Le Tue, 01 Jun 2010 21:04:44 +0200, Simon Wright <simon@pushface.org> a
> écrit:
>> First, you may need to use -gnatn or -gnatN and at least -O2 (have to
>> look up the manual for this).
> I've just noticed the same a short moment ago, indeed ;)

I've played with -gnatn and -gnatN in the past, and found that the latter 
tends to bomb the compiler quite a lot. (GPL2008 and 2009 experiences). 
Anyone seeing the same?

Re: -gnatN breakage was: Child vs nested package : efficiency matter

[Vadim Godunko]

On Jun 2, 3:11 pm, "Alex R. Mosteo" <alejan...@mosteo.invalid> wrote:
>
> I've played with -gnatn and -gnatN in the past, and found that the latter
> tends to bomb the compiler quite a lot. (GPL2008 and 2009 experiences).
> Anyone seeing the same?

-gnatN is obsolete, you must use pragma Inline/Inline_Always with -
gnatn instead.

Re: -gnatN breakage was: Child vs nested package : efficiency matter

[Georg Bauhaus]

On 02.06.10 16:39, Vadim Godunko wrote:
> On Jun 2, 3:11 pm, "Alex R. Mosteo" <alejan...@mosteo.invalid> wrote:
>>
>> I've played with -gnatn and -gnatN in the past, and found that the latter
>> tends to bomb the compiler quite a lot. (GPL2008 and 2009 experiences).
>> Anyone seeing the same?
> 
> -gnatN is obsolete, you must use pragma Inline/Inline_Always with -
> gnatn instead.

Does this mean that 3rd party source cannot be
inlined across units unless GNAT specific pragma Inline_Always
is added to these 3rd party sources?

Re: -gnatN breakage was: Child vs nested package : efficiency matter

[Yannick Duchêne (Hibou57)]

Le Wed, 02 Jun 2010 18:45:09 +0200, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:
>> -gnatN is obsolete, you must use pragma Inline/Inline_Always with -
>> gnatn instead.
>
> Does this mean that 3rd party source cannot be
> inlined across units unless GNAT specific pragma Inline_Always
> is added to these 3rd party sources?
The option is supported, it's sure, I've checked it. In the mean time, GPS  
does not provide it in project options (only -gnatn is supplied). May be  
while still supported, this is a bit broken, thus not recommended and not  
made visible.

As the option is supported, there should be no need to modify any third  
party source.


-- 
There is even better than a pragma Assert: a SPARK --# check.
--# check C and WhoKnowWhat and YouKnowWho;
--# assert Ada;
--  i.e. forget about previous premises which leads to conclusion
--  and start with new conclusion as premise.

Re: -gnatN breakage was: Child vs nested package : efficiency matter

[Vadim Godunko]

On Jun 2, 8:45 pm, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
wrote:
> On 02.06.10 16:39, Vadim Godunko wrote:
>
> > -gnatN is obsolete, you must use pragma Inline/Inline_Always with -
> > gnatn instead.
>
> Does this mean that 3rd party source cannot be
> inlined across units unless GNAT specific pragma Inline_Always
> is added to these 3rd party sources?
No. Use of -gnatn and -O is sufficient to enable inlining of
subprograms marked by pragma Inline. But not all subprograms will be
inlined but only definitely simple.

For example:

package P is
   function Simple (X, Y : Integer) return Integer;
   pragma Inline (Simple);
   function Complex (X, Y : Integer) return Integer;
   pragma Inline (Complex);
end P;

package body P is
   function Simple (X, Y : Integer) return Integer is
   begin
      return X + Y + 1;
   end Simple;
   function Complex (X, Y : Integer) return Integer is
   begin
      return X + Y + 1;
   exception
      when others =>
         return 0;
   end Complex;
end P;

with P;
function Test_Simple (X, Y : Integer) return Integer is
begin
   return P.Simple (X, Y);
end Test_Simple;

with P;
function Test_Complex (X, Y : Integer) return Integer is
begin
   return P.Complex (X, Y);
end Test_Complex;

$ gcc -c -S -O -gnatn test_simple.adb
$ gcc -c -S -O -gnatn test_complex.adb

From test_simple.s:

_ada_test_simple:
        leal    1(%rdi,%rsi), %eax
        ret

From test_complex.s:

_ada_test_complex:
        subq    $8, %rsp
        call    p__complex
        addq    $8, %rsp
        ret