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!news2.google.com!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!nx01.iad01.newshosting.com!newshosting.com!216.196.98.140.MISMATCH!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!news.belwue.de!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Fri, 04 Sep 2009 20:12:38 +0200
From: Georg Bauhaus <rm.dash-bauhaus@futureapps.de>
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>
 <eb26f060-c3b3-4540-8cf1-08873c013532@38g2000yqr.googlegroups.com>
 	<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>
 <4aa1553f$0$32670$9b4e6d93@newsspool2.arcor-online.net>
In-Reply-To: <4aa1553f$0$32670$9b4e6d93@newsspool2.arcor-online.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID: <4aa15897$0$32678$9b4e6d93@newsspool2.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 04 Sep 2009 20:12:39 CEST
NNTP-Posting-Host: 448cea73.newsspool2.arcor-online.net
X-Trace: 
 DXC=akUlJfn=QClIkjb;<8iR=aA9EHlD;3Ycb4Fo<]lROoRa^YC2XCjHcbi0DWemF[Lill;9OJDO8_SKfNSZ1n^B98ijj[PYhQiLIic
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news2.google.com comp.lang.ada:8164
Date: 2009-09-04T20:12:39+02:00
List-Id: <comp.lang.ada>

Georg Bauhaus schrieb:

> 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..

Maybe there is another reasonably simple solution to
the "optimal" task:cpu allocation problem. Add priorities
reflecting:

- required printing order (minor issue - printing not much work)

- time needed per task (loads of computation)

We could estimate the latter, more or less I think,
by separating out single tasks that have been assigned
a particular piece of work and then measure how long
they run on average.