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!b15g2000yqd.googlegroups.com!not-for-mail From: jonathan Newsgroups: comp.lang.ada Subject: Re: Ada Shootout program for K-Nucleotide (patches) Date: Sun, 23 Aug 2009 15:21:53 -0700 (PDT) Organization: http://groups.google.com Message-ID: <5103f5a7-8643-4d15-9989-b07fe773e0f3@b15g2000yqd.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> <6f1c440c-9941-4aa7-a4cd-bf02a00db49a@g1g2000vbr.googlegroups.com> <4a8c8fc8$0$32678$9b4e6d93@newsspool2.arcor-online.net> <5581b105-4c1c-4772-8657-34c5bcfeb6f1@v20g2000yqm.googlegroups.com> <4a8dcb11$0$31873$9b4e6d93@newsspool3.arcor-online.net> <4a9072a7$0$32669$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 1251066113 22135 127.0.0.1 (23 Aug 2009 22:21:53 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sun, 23 Aug 2009 22:21:53 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: b15g2000yqd.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:7966 Date: 2009-08-23T15:21:53-07:00 List-Id: On Aug 22, 11:35=A0pm, Georg Bauhaus wrote: > jonathan wrote: > >> Or if we are at it, we might experiment with slice renamings > >> or pointer artihmetic; requires a rewrite, I'd think. > >> If the rules permit this at all ;-) > > > I did make another attempt here. =A0[...] > > This essentially removed all the overhead in sliding > > array Data. > > With the help of generics I have been able to further > reduce string processing load. =A0Instances will adapt String > to fragments, as needed. > The result is another 20% speed-up. =A0A pleasant surprise, > and fairly easy. =A0This allows using simple renames for > key data. :-) > The program now runs in a splendid 23 sec on my machine. For those who have not been paying attention, we started some time ago with a program that ran in > 72 sec. Its now (I should think) quite a bit faster than all but one at the benchmarking site. The string renaming turned out to be such a neat trick, I'll write it out: Key(1 .. Length) :=3D Buffer(I .. I + Length - 1); (in its various forms) was replaced by Key : String renames Buffer(I .. I + Length - 1); This combined with the smaller strings did the trick. On my machine execution fell from ~32 sec to ~23 sec from these 2 steps alone. One useful feature of the new design is we can explicitly "grow the hash table" as the rules seem to specify, (although they accepted the static sized table last time). We now have the option of changing Table_Size with each instantiation: --Table_Size : constant Integer :=3D 2 ** 17; Table_Size : constant Integer :=3D 2 ** Integer'Min (Fragment'Last*4, 17); subtype Hash_Type is Integer range 0 .. Table_Size-1; This is the form used by many other entries. The new table size does not change the speed in the slightest. I prefer the static 2 ** 17 myself. > I'd like to further merge the programs, following the > comments so far. In particular, there doesn't seem to be > a real loss when using tasks on a single core machine, > IIUC. I'll try to confirm this some more. > We could then submit just one program, if you agree. > To fuse single-core and multitasking version I tried the following: if Multitasking_Desired then Work_On_2.Writer.Set (Nucleotide_Length =3D> 2); Work_On_18.Writer.Set (Fragment_18'Length, Fragment_18); Work_On_1.Writer.Set (Nucleotide_Length =3D> 1); Work_On_12.Writer.Set (Fragment_12'Length, Fragment_12); Work_On_6.Writer.Set (Fragment_6'Length, Fragment_6); Work_On_4.Writer.Set (Fragment_4'Length, Fragment_4); Work_On_3.Writer.Set (Fragment_3'Length, Fragment_3); else Work_On_1.Write (Nucleotide_Length =3D> 1); Work_On_2.Write (Nucleotide_Length =3D> 2); Work_On_3.Write (Fragment_3'Length, Fragment_3); Work_On_4.Write (Fragment_4'Length, Fragment_4); Work_On_6.Write (Fragment_6'Length, Fragment_6); Work_On_12.Write (Fragment_12'Length, Fragment_12); Work_On_18.Write (Fragment_18'Length, Fragment_18); end if; With Multitasking_Desired set to False, a typical (good) timing might look like: real 0m23.552s user 0m23.141s sys 0m0.404s With Multitasking_Desired set to True, a typical (good) timing might look like: real 0m10.373s user 0m23.625s sys 0m0.432s Fluctuations are not tiny; maybe .7 sec. And remember, Linux in probably putting the 7 Work tasks on 7 cores of the 8 available on my machine. And there's a problem I can't solve. One out of 5 to 20 runs gives this result: real 0m15.691s user 0m34.150s sys 0m0.396s Always the same ~16 seconds. I can't tell if its a Linux hiccup, the phase of the moon, or what, but I can't get rid of it. That's one reason I am not sure it is a good idea just yet to fuse the single-core version and the tasking version. I'ld rather see the cleaner single-core version polished up and submitted quick. To make a task-free version I just directly removed all the tasking from your latest. Works well .. my versions are obsolete .. just an option to consider. Jonathan