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=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC 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!mx02.eternal-september.org!.POSTED!not-for-mail
From: "G.B." <bauhaus@futureapps.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Everything You Know Is Wrong
Date: Tue, 29 Dec 2015 14:50:35 +0100
Organization: A noiseless patient Spider
Message-ID: <n5u2uf$nrc$1@dont-email.me>
References: <n5nbml$v32$1@dont-email.me> <n5r0su$lts$1@dont-email.me>
 <n5r5sb$sgs$1@speranza.aioe.org>
 <alpine.DEB.2.11.1512281721030.14144@Lydia.insomnia247.nl>
 <n5rrjq$gg3$1@speranza.aioe.org>
 <alpine.DEB.2.11.1512281938090.14144@Lydia.insomnia247.nl>
 <n5s6nj$ch8$1@speranza.aioe.org> <n5tre9$t7c$1@dont-email.me>
 <n5tuo8$1cn$1@speranza.aioe.org>
Reply-To: nonlegitur@futureapps.de
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 29 Dec 2015 13:47:59 -0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="b96887e80893c84a90c3007226ca0d1c";
	logging-data="24428"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1+zhRqH3q3npegiFD27Faz8ano2TPI17FM="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0)
 Gecko/20100101 Thunderbird/38.5.0
In-Reply-To: <n5tuo8$1cn$1@speranza.aioe.org>
Cancel-Lock: sha1:okuRdfw0WoHLxH7VRjt6GWIThZg=
Xref: news.eternal-september.org comp.lang.ada:28919
Date: 2015-12-29T14:50:35+01:00
List-Id: <comp.lang.ada>

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.