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
	autolearn=unavailable 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: Georg Bauhaus <bauhaus@futureapps.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Size of linked program increasing with new version of GNAT.
Date: Thu, 1 Jan 2015 12:28:34 +0000 (UTC)
Organization: A noiseless patient Spider
Message-ID: <m83ehi$lus$2@dont-email.me>
References: <m7spnq$1lc$1@loke.gir.dk>
 <e2493e16-17b3-4228-8e82-b664783ec207@googlegroups.com>
 <lndbstazz46d$.82hq0dieuouh$.dlg@40tude.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 1 Jan 2015 12:28:34 +0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="476081a394a6977aa9a16fe8c1d89e25";
	logging-data="22492"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX19g5fY2Ukn8/VJKhm+Hi+188o+pegx/Qm0="
User-Agent: NewsTap/4.0.1 (iPhone/iPod Touch)
Cancel-Lock: sha1:DP2zVe8FdyGUBmOVPLGkTe+QNho=
Xref: news.eternal-september.org comp.lang.ada:24309
Date: 2015-01-01T12:28:34+00:00
List-Id: <comp.lang.ada>

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
> On Wed, 31 Dec 2014 04:08:13 -0800 (PST), Jean François Martinez wrote:

>> The executable is parasited by
>> things like runtime, libraries, dynamic linker (or first stage of dynamic
>> linker) and so on.
> 
> The code size can be approximated by a linear function A + B*x, where x is
> the program "complexity". Arguments that A might be irrelevant is true only
> if B is correspondingly small compared to the alternatives so that with
> growing x you could compensate your losses on A.

Executables' size also reflects technical needs: compressing an
executable program such as gnatmake shows ratios of
over one half on Intel. Chances are, then, that there is redundant
executable code in gnatmake. But there are reasons that there is,
I guess, because the optimizers make the processor perform better,
reflecting its sets of instructions and its architecture (parallel
pipelines etc.). When TIME is more important than SPACE
in order to meet timing requirements, greater code size might
seem paradoxical, but might be necessary.

Has anyone tried deduplication with executables?