From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00, PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Community Input for the Maintenance and Revision of the Ada Programming Language Date: Fri, 8 Sep 2017 18:07:36 -0500 Organization: JSA Research & Innovation Message-ID: References: <4dc188de-802b-41ad-9cdd-b8246eb9a1c7@googlegroups.com> <47cc6474-8b75-4644-92d0-bd1f694c20e7@googlegroups.com> <338b355a-dee4-4c73-b00e-09d9a8430fb1@googlegroups.com> <21692daf-5a52-43f0-a72a-d79e6a7dcc9f@googlegroups.com> Injection-Date: Fri, 8 Sep 2017 23:07:36 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="19819"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: news.eternal-september.org comp.lang.ada:47988 Date: 2017-09-08T18:07:36-05:00 List-Id: "Johan Söderlind Åström" wrote in message news:21692daf-5a52-43f0-a72a-d79e6a7dcc9f@googlegroups.com... >> >What do you mean with cheaper? Faster execution?, Less memory footprint? >> >> Both. The address clause adds an extra level of indirection that the type >> conversion doesn't necessarily add. (In Janus/Ada, the conversion would >> remove or replace the bounds descriptor, making the access cost >> identically >> to the original array accesses; an address clause always adds a level of >> indirection.) But I forgot about the cost to copy the array (usually >> insignificant, but not always). > > Copy the entirety of an array is not insignificant, it is doubling the > memory footprint which is not less. The memory footprint of most arrays is insignificant. I usually do this kind of thing with Strings, and the typical string is only a few dozen bytes. Obviously, if a single array is using most of the memory on the computer, then you don't want to copy it. (But you're not going to pass those as a parameter in the first place.) >> Moral2: Premature optimization is the root of much evil. Only worry about >> the performance of code that is demonstrably too slow. Otherwise, >> readability and maintainability are the most important goals after >> correctness. YMMV. > > It is not about optimization, it is about simplicity. > > A (I) + B (I) is more simpler than A (A'First + I) + B (B'First + I) to > read. > No copy is more simpler than a copy. The use of an address clause is a red flag to any (experienced) reader that something weird is going on. Attempting to figure out if that is safe and what it means and whether it really means what is intended is going kill any savings in reading of the actual expressions. ... >> with the first part calculated by the compiler and generated as a single >> item. The only runtime operations are the + and second *, just as in the >> zero-based form. > > That is a good optimization and I hope it is not considered a premature > optimization because that is optimizing core functionality of the language > which will affect near 100% of all Ada code. Luckily you showed me > that I do not have to do it manually. "premature optimization" is referring to the programmer trying to make the code fast before he even finds out how it performs. That doesn't refer to compiler optimization, which doesn't harm the understandability of the code (since it occurs automatically). Compilers can and do a lot of optimizations that aren't practical to do by hand. But if you really need to speed up some piece of code, you have to change the algorithm. Robert Dewar (RIP) used to say that "most optimizations are disappointing"; by that he meant that all of the optimizations in the world (both automatic or hand-generated) will only change the performance of code by a small percentage - in almost all cases, less than 20%. And most code that is too slow needs a lot more improvement than that. Thus programmers tend to focus on the wrong thing much of the time (something to which I am not immune!). For instance, if searching through a large array is too slow, perhaps introducing a hash table as an index will speed up the operation enough. > I would really like to write, for a example: > (A (I) + B (I)) * C (I) / (D (I) ** E (I)); > instead of: > (A (A'First + I) + B (B'First + I)) * C (C'First + I) / (D (D'First + I) > ** E (E'First + I)); > ... you know for obvious reason. In a case like this, I'd expect that all of the arrays are constrained with the same range and thus there is no need to bias any of the indexes. You do know that you can declare constrained subtypes such that the array parameters of a routine have known bounds, right? Most of my routines use constrained arrays and thus don't need this sort of adjustment. That is, if you know that all of these arrays have the same bounds (and they most likely do, they surely need the same length in a formula like this), then for I in A'Range loop F(I) := (A (I) + B (I)) * C (I) / (D (I) ** E (I)); end loop; will do the trick without adjusting any bounds. You could declare the arrays like: MAX_LEN : constant := 10; type Integer_Array is array (Positive range <>) of Float; subtype My_IA is Integer_Array (0 .. MAX_LEN); A, B, C : My_IA; procedure Mult (A, B : in My_IA; C : out My_IA) is begin for I in My_IA'Range loop C(I) := A(I) * B(I); end loop; end Mult; You can also use (in Ada 2012) a precondition or predicate to have a similar effect (even to force all arrays to start at 0 if that is your preference). Ada 2012 also has loops over the elements of an array, so there is no need to write indexes at all in some cases. Randy.