Re: Everything You Know Is Wrong

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:n5ugbf$fqr$1@speranza.aioe.org...
> On 2015-12-29 17:57, G.B. wrote:
>
>> The point is that, since order does not matter among these parallel
>> computations, and since parallel loops are not just fantasy,
>> the possibility of postponement follows from parallel loops.
>
> Ada does not have parallel loops. The job is done!

But Ada 202x most likely will.

>> Consider F1 and F2 from a Pure package, X a variable of type T
>> and T without progenitors:
>>
>>     declare
>>        A : T := F1 (1,2,3);
>>        B : T := F2 (X);
>>     begin
>>        G (A, B);
>>     end;
>>
>> Is it impossible for a compiler to see that the initializing parts of
>> the declarations of A and B are independent?
>
> No, because initialization of T may have side effects. Ada mandates B 
> initialized after A. Again, the "optimization" you wanted is done.

Irrelevant - the compiler knows if any side-effects are possible (T is known 
to the compiler). That is going to be a conservative determination, but it 
will be true for many types (there is no side-effect for elementary types, 
for instance). Similarly, the compiler could know that other side-effects 
aren't possible, either by inspecting the code or by a declaration (many 
compilers have mechanisms for this, and Ada 202x is likely to get one as 
well).

In any case, optimization is a very important part of compilation. Pretty 
much all Ada compilers make decisions like the one shown here every time you 
compile anything - the results would be terrible if they did not. For 
Janus/Ada, it makes a difference of up to 25% in time and space (compared to 
the unoptimized code). And of course one can optimize for many different 
things, including power usage -- I'm pretty sure the compilers used for 
mobile platforms do such optimizations as a matter of course. And that's for 
C -- Ada provides many more optimization possibilities because it has far 
more information about the program and the programmers intentions.

                                          Randy.





> BTW, why do you believe that the same amount of computation performed 
> consecutively should require less energy or (not quite same) less battery 
> drain? It is no obvious. In any case it might depend on the specifics of 
> the battery, the board, the memory controller, the number of cores etc. 
> You cannot optimize for these, it would lead a combinatoric explosion of 
> targets. All that mess to save 0.1% drain?
>
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de