Re: Everything You Know Is Wrong

["G.B." <bauhaus@futureapps.invalid>]

On 29.12.15 13:36, Dmitry A. Kazakov wrote:
> On 2015-12-29 12:42, G.B. wrote:
>
>> The hardware people do a lot to reduce energy needs.  The software
>> people could add to that.
>
> I don't think so. Software is too costly and too volatile. Any potential
> win is negligible and will be overtaken by new hardware in just one year.

The managers of the billion $ computer companies have been
addressing battery related running times for years already. Suppose
that a compiler optimizes a program for energy consumption. So, no
big batteries are needed. If the sales people can therefore make the
designers design a thinner device or a device that runs longer
before recharging is needed, then that makes optimizing for energy
consumption a sales argument that will affect production.

>> For example, if two subprograms are independent
>> and their execution can be postponed until a third one needs their
>> results,
>
> Firstly, you cannot know that.

Independence of subprograms can follow from an abstract design
and from a solution, both of which the programmers know. A compiler
may not know it generally if there is no language for it.
(No "with" of one by the other, and no dependence on anything
with "Address" in it, or "Import", or I/O, ....)

SPARK will allow full formalization, I think.


> Secondly, this is a classic abstraction
> inversion example. Subprograms are result of software decomposition,
> which is driven by the problem.

If problem driven decomposition happens to give independent
subprograms, why not have optimization make good use of the
opportunity? As "optimization" indicates, the corresponding
compiler switch would not normally drive designs.