* Child vs nested package : efficiency matter @ 2010-05-29 12:56 Yannick Duchêne (Hibou57) 2010-05-30 1:17 ` BrianG ` (2 more replies) 0 siblings, 3 replies; 17+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-05-29 12:56 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Child vs nested package : efficiency matter 2010-05-29 12:56 Child vs nested package : efficiency matter Yannick Duchêne (Hibou57) @ 2010-05-30 1:17 ` BrianG 2010-06-01 15:03 ` Adam Beneschan 2010-06-01 18:35 ` Adam Beneschan 2 siblings, 0 replies; 17+ messages in thread From: BrianG @ 2010-05-30 1:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Child vs nested package : efficiency matter 2010-05-29 12:56 Child vs nested package : efficiency matter Yannick Duchêne (Hibou57) 2010-05-30 1:17 ` BrianG @ 2010-06-01 15:03 ` Adam Beneschan 2010-06-01 15:34 ` Yannick Duchêne (Hibou57) 2010-06-01 18:35 ` Adam Beneschan 2 siblings, 1 reply; 17+ messages in thread From: Adam Beneschan @ 2010-06-01 15:03 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Child vs nested package : efficiency matter 2010-06-01 15:03 ` Adam Beneschan @ 2010-06-01 15:34 ` Yannick Duchêne (Hibou57) 2010-06-01 15:38 ` Adam Beneschan 2010-06-01 19:04 ` Simon Wright 0 siblings, 2 replies; 17+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-06-01 15:34 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Child vs nested package : efficiency matter 2010-06-01 15:34 ` Yannick Duchêne (Hibou57) @ 2010-06-01 15:38 ` Adam Beneschan 2010-06-01 19:04 ` Simon Wright 1 sibling, 0 replies; 17+ messages in thread From: Adam Beneschan @ 2010-06-01 15:38 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Child vs nested package : efficiency matter 2010-06-01 15:34 ` Yannick Duchêne (Hibou57) 2010-06-01 15:38 ` Adam Beneschan @ 2010-06-01 19:04 ` Simon Wright 2010-06-01 19:11 ` Yannick Duchêne (Hibou57) 1 sibling, 1 reply; 17+ messages in thread From: Simon Wright @ 2010-06-01 19:04 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Child vs nested package : efficiency matter 2010-06-01 19:04 ` Simon Wright @ 2010-06-01 19:11 ` Yannick Duchêne (Hibou57) 2010-06-02 11:11 ` -gnatN breakage was: " Alex R. Mosteo 0 siblings, 1 reply; 17+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-06-01 19:11 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* -gnatN breakage was: Child vs nested package : efficiency matter 2010-06-01 19:11 ` Yannick Duchêne (Hibou57) @ 2010-06-02 11:11 ` Alex R. Mosteo 2010-06-02 14:39 ` Vadim Godunko 0 siblings, 1 reply; 17+ messages in thread From: Alex R. Mosteo @ 2010-06-02 11:11 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: -gnatN breakage was: Child vs nested package : efficiency matter 2010-06-02 11:11 ` -gnatN breakage was: " Alex R. Mosteo @ 2010-06-02 14:39 ` Vadim Godunko 2010-06-02 16:45 ` Georg Bauhaus 0 siblings, 1 reply; 17+ messages in thread From: Vadim Godunko @ 2010-06-02 14:39 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: -gnatN breakage was: Child vs nested package : efficiency matter 2010-06-02 14:39 ` Vadim Godunko @ 2010-06-02 16:45 ` Georg Bauhaus 2010-06-02 16:50 ` Yannick Duchêne (Hibou57) 2010-06-02 20:35 ` Vadim Godunko 0 siblings, 2 replies; 17+ messages in thread From: Georg Bauhaus @ 2010-06-02 16:45 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: -gnatN breakage was: Child vs nested package : efficiency matter 2010-06-02 16:45 ` Georg Bauhaus @ 2010-06-02 16:50 ` Yannick Duchêne (Hibou57) 2010-06-02 20:35 ` Vadim Godunko 1 sibling, 0 replies; 17+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-06-02 16:50 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: -gnatN breakage was: Child vs nested package : efficiency matter 2010-06-02 16:45 ` Georg Bauhaus 2010-06-02 16:50 ` Yannick Duchêne (Hibou57) @ 2010-06-02 20:35 ` Vadim Godunko 1 sibling, 0 replies; 17+ messages in thread From: Vadim Godunko @ 2010-06-02 20:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Child vs nested package : efficiency matter 2010-05-29 12:56 Child vs nested package : efficiency matter Yannick Duchêne (Hibou57) 2010-05-30 1:17 ` BrianG 2010-06-01 15:03 ` Adam Beneschan @ 2010-06-01 18:35 ` Adam Beneschan 2010-06-01 19:09 ` Yannick Duchêne (Hibou57) 2 siblings, 1 reply; 17+ messages in thread From: Adam Beneschan @ 2010-06-01 18:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Child vs nested package : efficiency matter 2010-06-01 18:35 ` Adam Beneschan @ 2010-06-01 19:09 ` Yannick Duchêne (Hibou57) 2010-06-01 19:44 ` Adam Beneschan 2010-06-02 1:38 ` BrianG 0 siblings, 2 replies; 17+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-06-01 19:09 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Child vs nested package : efficiency matter 2010-06-01 19:09 ` Yannick Duchêne (Hibou57) @ 2010-06-01 19:44 ` Adam Beneschan 2010-06-01 19:56 ` Yannick Duchêne (Hibou57) 2010-06-02 1:38 ` BrianG 1 sibling, 1 reply; 17+ messages in thread From: Adam Beneschan @ 2010-06-01 19:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Child vs nested package : efficiency matter 2010-06-01 19:44 ` Adam Beneschan @ 2010-06-01 19:56 ` Yannick Duchêne (Hibou57) 0 siblings, 0 replies; 17+ messages in thread From: Yannick Duchêne (Hibou57) @ 2010-06-01 19:56 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Child vs nested package : efficiency matter 2010-06-01 19:09 ` Yannick Duchêne (Hibou57) 2010-06-01 19:44 ` Adam Beneschan @ 2010-06-02 1:38 ` BrianG 1 sibling, 0 replies; 17+ messages in thread From: BrianG @ 2010-06-02 1:38 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2010-06-02 20:35 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-05-29 12:56 Child vs nested package : efficiency matter Yannick Duchêne (Hibou57) 2010-05-30 1:17 ` BrianG 2010-06-01 15:03 ` Adam Beneschan 2010-06-01 15:34 ` Yannick Duchêne (Hibou57) 2010-06-01 15:38 ` Adam Beneschan 2010-06-01 19:04 ` Simon Wright 2010-06-01 19:11 ` Yannick Duchêne (Hibou57) 2010-06-02 11:11 ` -gnatN breakage was: " Alex R. Mosteo 2010-06-02 14:39 ` Vadim Godunko 2010-06-02 16:45 ` Georg Bauhaus 2010-06-02 16:50 ` Yannick Duchêne (Hibou57) 2010-06-02 20:35 ` Vadim Godunko 2010-06-01 18:35 ` Adam Beneschan 2010-06-01 19:09 ` Yannick Duchêne (Hibou57) 2010-06-01 19:44 ` Adam Beneschan 2010-06-01 19:56 ` Yannick Duchêne (Hibou57) 2010-06-02 1:38 ` BrianG
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox