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=ham autolearn_force=no version=3.4.4
X-Google-Thread: a07f3367d7,3a6a9f1d654285ba
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII
Path: 
 g2news2.google.com!postnews.google.com!v20g2000yqm.googlegroups.com!not-for-mail
From: jonathan <johnscpg@googlemail.com>
Newsgroups: comp.lang.ada
Subject: Re: Ada Shootout program for K-Nucleotide (patches)
Date: Thu, 20 Aug 2009 12:47:50 -0700 (PDT)
Organization: http://groups.google.com
Message-ID: 
 <5581b105-4c1c-4772-8657-34c5bcfeb6f1@v20g2000yqm.googlegroups.com>
References: <4a743343$0$32674$9b4e6d93@newsspool2.arcor-online.net>
	<4bc4b12d-40f8-4140-8ef6-326d9e6b8adf@k30g2000yqf.googlegroups.com>
	<4a897b61$0$30221$9b4e6d93@newsspool1.arcor-online.net>
 <4d48b846-bb2d-4126-86c2-487b2244c9ad@d4g2000yqa.googlegroups.com>
	<4a8c119d$0$31866$9b4e6d93@newsspool3.arcor-online.net>
 <9b7557ca-df60-4d70-b692-f077b71983eb@g10g2000yqh.googlegroups.com>
	<wccd46r4q7m.fsf@shell01.TheWorld.com>
 <6f1c440c-9941-4aa7-a4cd-bf02a00db49a@g1g2000vbr.googlegroups.com>
	<4a8c8fc8$0$32678$9b4e6d93@newsspool2.arcor-online.net>
NNTP-Posting-Host: 143.117.23.126
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Trace: posting.google.com 1250797670 25860 127.0.0.1 (20 Aug 2009 19:47:50
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Thu, 20 Aug 2009 19:47:50 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: v20g2000yqm.googlegroups.com; posting-host=143.117.23.126;
	posting-account=Jzt5lQoAAAB4PhTgRLOPGuTLd_K1LY-C
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.9.0.12)
	Gecko/2009072220 Iceweasel/3.0.6 (Debian-3.0.6-1),gzip(gfe),gzip(gfe)
Xref: g2news2.google.com comp.lang.ada:7916
Date: 2009-08-20T12:47:50-07:00
List-Id: <comp.lang.ada>

On Aug 20, 12:50=A0am, Georg Bauhaus <rm.tsoh.plus-
bug.bauh...@maps.futureapps.de> wrote:

> Since a fixed buffer size makes the program
> fail when inputs grow, I think the temporary Unbounded_String
> is reasonable.
>
> There are only a few calls to Unbounded.* anyway.
> Get_Line seems to be the dominating subprogram here.


I agree. These timings mean that overhead from unbounded
strings is insignificant.

Unfortunately I got my timings a bit wrong.  Fortunately the
conclusion remains the same.  (I redid everything
carefully.)  IO is consistently ~11% running time on
my machine, so no great source of inefficiency.

I also measured the benefit of the 64 Megabyte buffer
more carefully:

      procedure Read_Section is
         ...
         Local_Buffer : String_Access;
      begin
         Local_Buffer :=3D new String (1 .. 1024 * 1024 * 64);

I would now recommend

         Local_Buffer :=3D new String (1 .. 1024 * 1024 * 16);

Its only .25 sec slower.

Finally, I found one last useful optimization, which
consistently shaves 6% off the running time on my machine.
(I was unpleasantly surprised that it wasn't better.)

The 125 Meg array (Buffer) is read through from beginning
to end numerous times and and each time about 125 million
substrings are written to string Key.Data:

  Key.Data(1 .. Length) :=3D Buffer (I-Length+1 .. I);

The string Key.Data already contains most of the desired
data. Since Buffer may be in slower memory, and Key.Data
in very fast memory, it makes sense to update
Key.Data from itself whenever possible:

 Key.Last            :=3D Length;
 Key.Data(2..Length) :=3D Buffer (1..Length-1);--new essential init.

 for I in Length .. Buffer'Last loop

 -- Key.Data(1 .. Length) :=3D Buffer (I-Length+1 .. I);--Old

    -- New. Use loop not sliding, (and -funroll-all-loops):
    for j in 1 .. Length-1 loop
       Key.Data(j) :=3D Key.Data(j+1);
    end loop;
    Key.Data(Length) :=3D Buffer (I);

    declare
       Element : constant Element_Access :=3D Table.Get (Key);
    ...



Jonathan