Re: Community Input for the Maintenance and Revision of the Ada Programming Language

["Randy Brukardt" <randy@rrsoftware.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4863 bytes --]

"Johan Söderlind Åström" <johaa1993@gmail.com> 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.