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.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,a32653cf595422e6
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII
Received: by 10.68.202.37 with SMTP id kf5mr11786206pbc.7.1335129871891;
        Sun, 22 Apr 2012 14:24:31 -0700 (PDT)
Path: 
 r9ni86836pbh.0!nntp.google.com!news2.google.com!goblin2!goblin.stu.neva.ru!news.internetdienste.de!news.tu-darmstadt.de!news.belwue.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Sun, 22 Apr 2012 23:24:30 +0200
From: Georg Bauhaus <rm.dash-bauhaus@futureapps.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: GNAT and register allocation
References: <4f9138c2$0$6628$9b4e6d93@newsspool2.arcor-online.net>
 <4f9145b5$0$6557$9b4e6d93@newsspool4.arcor-online.net>
 <jmrpej$cao$1@speranza.aioe.org>
 <4f918218$0$6557$9b4e6d93@newsspool4.arcor-online.net>
 <87ipgtgkho.fsf@mid.deneb.enyo.de>
 <4f94379b$0$6639$9b4e6d93@newsspool2.arcor-online.net>
 <25429130.1239.1335127991071.JavaMail.geo-discussion-forums@ynlp2>
In-Reply-To: 
 <25429130.1239.1335127991071.JavaMail.geo-discussion-forums@ynlp2>
Message-ID: <4f94770e$0$7615$9b4e6d93@newsspool1.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 22 Apr 2012 23:24:30 CEST
NNTP-Posting-Host: a3b52d90.newsspool1.arcor-online.net
X-Trace: 
 DXC=PICKZ3L@aEP@>[RYkFXOIPic==]BZ:af^4Fo<]lROoRQ<`=YMgDjhgRnDOROYlK6_Pnc\616M64>ZLh>_cHTX3j]05C_0i3a8]V
X-Complaints-To: usenet-abuse@arcor.de
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Date: 2012-04-22T23:24:30+02:00
List-Id: <comp.lang.ada>

On 22.04.12 22:53, gautier_niouzes@hotmail.com wrote:
> Le dimanche 22 avril 2012 18:53:46 UTC+2, Georg Bauhaus a �crit :
>
>> Still, a pragma controlling inline expansion (not just the enabling
>> pramga that Ada has) seems a more pragma-tic way of specifying what
>> I'd like, in the shape of a clearly visible request. (The compiler
>> may still ignore it).
>> Controlling inline expansion by playing with sizes of subprograms
>> seems possible, but a little adventurous.
>>
>> Currently, I see only one way, writing a forest of
>> options for translating units of re-structured programs...
>
> Did you consider the -gnatn option (rather: not using it...) ?

Yes, and many other things: there is also the trade-off between -gnatN
(deprecated in newer GNATs that rely on more recently added GCC powers)
and -gnatn, and nothing, and -O3 and -O2, and ... and compiler versions,
and a number of different CPUs, all offering different capabilities
(pipelines, buffers, versions of SSE, ...) and OS versions (both 32 bits
and 64 bits) ... that all affect the running time of programs.

Massively in this case.

Sometimes the effects of any combination of the above are rather striking,
yielding speedups or slowdowns in the range 0 .. 300 percent, for the
exact same program. The goal is to find ways to control the compilers
so that they produce predictably good result at least when the programs
are run on a subset of CPUs known in advance.