Prev: SPARK and modular types
Next: Dynamically tagged expression not allowed. Why?
From: Adam Beneschan on 1 Jun 2010 14:35
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.

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
From: Simon Wright on 1 Jun 2010 15:04
"Yannick Duchêne (Hibou57)" <yannick_duchene(a)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.
From: Yannick Duchêne (Hibou57) on 1 Jun 2010 15:09
Le Tue, 01 Jun 2010 20:35:02 +0200, Adam Beneschan <adam(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 ?

--
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: Yannick Duchêne (Hibou57) on 1 Jun 2010 15:11
Le Tue, 01 Jun 2010 21:04:44 +0200, Simon Wright <simon(a)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.
From: Adam Beneschan on 1 Jun 2010 15:44
On Jun 1, 12:09 pm, Yannick Duchêne (Hibou57)
<yannick_duch...(a)yahoo.fr> wrote:
> Le Tue, 01 Jun 2010 20:35:02 +0200, Adam Beneschan <a...(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
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: SPARK and modular types
Next: Dynamically tagged expression not allowed. Why?