From: Hibou57 (Yannick Duchêne) on 7 Oct 2009 16:59 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 7 Oct 2009 18:38 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 7 Oct 2009 19:30 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 7 Oct 2009 20:30 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 7 Oct 2009 20:48 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).
|
Next
|
Last
Pages: 1 2 3 Prev: Barrier re-evaluation issue with GNAT 4.3.2 Next: GTKADA Installation Questions |