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.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.107.7.228 with SMTP id g97mr2493424ioi.35.1504904669916; Fri, 08 Sep 2017 14:04:29 -0700 (PDT) X-Received: by 10.36.228.193 with SMTP id o184mr200443ith.9.1504904669888; Fri, 08 Sep 2017 14:04:29 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.swapon.de!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!127no898951itw.0!news-out.google.com!c139ni1294itb.0!nntp.google.com!o200no901666itg.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 8 Sep 2017 14:04:29 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=83.255.112.230; posting-account=NT38RwoAAAB4_OO_uw8yHtNaa9Hkjukk NNTP-Posting-Host: 83.255.112.230 References: <4dc188de-802b-41ad-9cdd-b8246eb9a1c7@googlegroups.com> <47cc6474-8b75-4644-92d0-bd1f694c20e7@googlegroups.com> <338b355a-dee4-4c73-b00e-09d9a8430fb1@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <21692daf-5a52-43f0-a72a-d79e6a7dcc9f@googlegroups.com> Subject: Re: Community Input for the Maintenance and Revision of the Ada Programming Language From: =?UTF-8?B?Sm9oYW4gU8O2ZGVybGluZCDDhXN0csO2bQ==?= Injection-Date: Fri, 08 Sep 2017 21:04:29 +0000 Content-Type: text/plain; charset="UTF-8" Xref: news.eternal-september.org comp.lang.ada:47985 Date: 2017-09-08T14:04:29-07:00 List-Id: > >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. > 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. > Moral: Compilers can eliminate most of the supposedly extra costs; it pays > only to worry about those that are known (via experiment) to be significant > in the runtime of a program. (The 90-10 rule says that the performance of > 90% of the code has no effect on the result.) Near 100% of code is using core functionality of the language like accessing array element. > In most cases, that is not an issue. Whenever Item'First is static (that is > known to the compiler), the compiler will fold it into the base address so > the cost is the same. (And there is a cost to rebasing the array, no matter > how you do it.) > > Specifically, the general form: > > (base_address + (index - first)*element_size) > is the same as: > (base_address - (first*element_size) + (index*element_size)) > > In the usual case, when both first and element_size are known to the > compiler, the code generation will be > > ((base_address - (first*element_size)) + (index*element_size)) > > 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. So the simplest way to access a element in Ada is to write: A : Integer_Array (-5 .. 5); A (A'First + I); Which has the same complexity as in C: int A[11]; A [I]; Where I starts from zero. 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. I appreciate you bringing up the issues with an explanation. I hope you understand my issues as well :)