Prev: SPARK and modular types
Next: Dynamically tagged expression not allowed. Why?
From: Yannick Duchêne (Hibou57) on 29 May 2010 08:56
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.
From: BrianG on 29 May 2010 21:17
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
From: Adam Beneschan on 1 Jun 2010 11:03
On May 29, 5:56 am, Yannick Duchêne (Hibou57)
<yannick_duch...(a)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
From: Yannick Duchêne (Hibou57) on 1 Jun 2010 11:34
Le Tue, 01 Jun 2010 17:03:44 +0200, Adam Beneschan <adam(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 ?

--
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.
From: Adam Beneschan on 1 Jun 2010 11:38
On Jun 1, 8:34 am, Yannick Duchêne (Hibou57)
<yannick_duch...(a)yahoo.fr> wrote:
> Le Tue, 01 Jun 2010 17:03:44 +0200, Adam Beneschan <a...(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
 |  Next  |  Last
Pages: 1 2 3
Prev: SPARK and modular types
Next: Dynamically tagged expression not allowed. Why?