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=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-7-bit Path: g2news2.google.com!news1.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!newsfeed.freenet.de!news.teledata-fn.de!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Fri, 04 Sep 2009 19:58:22 +0200 From: Georg Bauhaus User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Ada Shootout program for K-Nucleotide (patches) References: <4a743343$0$32674$9b4e6d93@newsspool2.arcor-online.net> <3f9f9e21-e088-4fbe-baac-dd43fdf6b911@r38g2000yqn.googlegroups.com> <4a757b0d$0$31328$9b4e6d93@newsspool4.arcor-online.net> <4a9fc85a$0$2850$ba620e4c@news.skynet.be> <1a5e1270-6a0a-4fff-a9b4-965abe610b69@o9g2000yqj.googlegroups.com> <4a9fdd46$0$2853$ba620e4c@news.skynet.be> <4aa0afbf$0$2864$ba620e4c@news.skynet.be> <3df8815d-b65a-4f73-9015-65375dcff113@x38g2000yqb.googlegroups.com> <4aa0e963$0$2868$ba620e4c@news.skynet.be> <0709cb9b-6144-4b14-a555-97262b1fa7b7@x37g2000yqj.googlegroups.com> <4aa13eaf$0$32666$9b4e6d93@newsspool2.arcor-online.net> <4aa1407d$0$32666$9b4e6d93@newsspool2.arcor-online.net> <335214cf-c7cb-459f-bb5b-89f589da7111@e11g2000yqo.googlegroups.com> In-Reply-To: <335214cf-c7cb-459f-bb5b-89f589da7111@e11g2000yqo.googlegroups.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <4aa1553f$0$32670$9b4e6d93@newsspool2.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 04 Sep 2009 19:58:23 CEST NNTP-Posting-Host: f8476cd2.newsspool2.arcor-online.net X-Trace: DXC=6RN@:d>glolf1oJaJ0@dmgA9EHlD;3Ycb4Fo<]lROoRa^YC2XCjHcbieRhPW`=oTZm;9OJDO8_SKfNSZ1n^B98ijU^[i]EE^eO` X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:8163 Date: 2009-09-04T19:58:23+02:00 List-Id: Ludovic Brenta schrieb: > So I gather that Olivier was profiling an old version of the program. > Correct? Yes. It likely is the one that has the home made Bounded_String. But this one does not have the plain String generic yet. (And a few other improvements.) I haven't finished merging the new multitasking edition and all of the new patches yet. A final draft should be ready this evening. (Just drop the file name from the link then to see a scratch paper style "manifest" if you like.) Another possible improvement (maybe for regexdna, too) that I have been thinking about is this: Currently, the working tasks will themselves print their results, after having finished all their work. They do so in the required order with the help of a protected Printer. The printer features an entry family (effectively one member per task). Guarding is such that tasks can print only one after the other, in the required order. (Printing is the last small thing that the tasks perform before they can be terminated.) The option I have been thinking of is, in the regexdna case in particular, to allow some "future" work to be done while the shared variable is collecting results: There might be free CPU capacity because, say on a 4-core, one task hasn't finished, leaving two out of four cores idling until the next rush of tasks starts working on the second part of the program, e.g.. Miscellanea: Does the size of the entry family (18, some not used) matter much? (Most of the work is done by the tasks undisturbed.) Should we requeue instead? For K-Nucleotide all this didn't seem to matter much, at least on the machines to which we have access: Dropping the requirement of orderly printing is not a big win. But who knows.