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,FREEMAIL_FROM
	autolearn=unavailable autolearn_force=no version=3.4.4
X-Received: by 10.66.220.163 with SMTP id px3mr10540883pac.38.1384358834333;
        Wed, 13 Nov 2013 08:07:14 -0800 (PST)
X-Received: by 10.182.236.232 with SMTP id ux8mr192736obc.12.1384358834254;
 Wed, 13 Nov 2013 08:07:14 -0800 (PST)
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!y3no7865469pbx.0!news-out.google.com!9ni26651qaf.0!nntp.google.com!i2no23898500qav.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Wed, 13 Nov 2013 08:07:14 -0800 (PST)
In-Reply-To: <20131113163923.32140110@PC-8N-L>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=129.59.203.130;
 posting-account=7Oy7OQoAAABhVYFOo553Cn1-AaU-bSfl
NNTP-Posting-Host: 129.59.203.130
References: <1o29hesl8k6yk$.1kqputng2vdks$.dlg@40tude.net>
 <87habgiufi.fsf@ludovic-brenta.org>
 <1ogylkzganxtj.1fuy036v94ui4$.dlg@40tude.net>
 <52835cab$0$9515$9b4e6d93@newsspool1.arcor-online.net>
 <1gyri4u994iza.15tpx0vnp77zr.dlg@40tude.net>
 <20131113163923.32140110@PC-8N-L>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <ff6d91f4-fd4c-4566-934e-fae6a83007c4@googlegroups.com>
Subject: Re: Increasing GNAT's heap
From: Eryndlia Mavourneen <eryndlia@gmail.com>
Injection-Date: Wed, 13 Nov 2013 16:07:14 +0000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Xref: news.eternal-september.org comp.lang.ada:17655
Date: 2013-11-13T08:07:14-08:00
List-Id: <comp.lang.ada>

On Wednesday, November 13, 2013 9:39:23 AM UTC-6, Oliver Kleinke wrote:
> > I don't believe it has anything to do with GCC. It looks clearly like
> > GNAT issue which, BTW, also leads to extremely sluggish compilation.
> > After all, if you allocate 2+ GB of memory you have to fill it with
> > some junk and that takes time, much time.
>=20
> I suppose this has to do with swapping/paging, so the sluggishness might
> not be GNAT's fault.

I was thinking along these lines.  It is important to remember that the pro=
gram being run dictates much of what occurs with paging.  Data references a=
side, the locality of execution has a great deal to do with the amount of p=
aging and swapping that occurs.  A program that constantly jumps around to =
widely disparate parts of the address space will experience considerably mo=
re paging than a program which is as sequential as possible.  I would think=
 that it is possible to have the linker combine frequently used subprograms=
 together with the main code in a single program section or sections that a=
re loaded together to minimize the paging.

Alternatively, there are tools which help to identify which parts of the co=
de are being heavily executed.  It then is possible to lock as many of thes=
e pages into memory as circumstances allow.  This will provide a huge incre=
ase in speed with relatively little work.

Not having had to worry too much about these issues in a while, I am not up=
 on the latest tools for these things, but I am certain that others in this=
 group are.

-- Eryndlia Mavourneen (KK1T)