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,8e11100f675ea2df
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII-7-bit
X-Received: by 10.66.82.137 with SMTP id i9mr9685639pay.41.1357498038247;
        Sun, 06 Jan 2013 10:47:18 -0800 (PST)
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Newsgroups: comp.lang.ada
Subject: Re: asynchronous task communication
Date: Mon, 31 Dec 2012 23:09:27 +0200
Organization: Tidorum Ltd
Message-ID: <aked87Fpfc1U1@mid.individual.net>
References: <1c2dnd5E6PMDR33NnZ2dnUVZ_sednZ2d@earthlink.com>
 <50e18094$0$6583$9b4e6d93@newsspool3.arcor-online.net>
 <7NednS4s2oukfXzNnZ2dnUVZ_oadnZ2d@earthlink.com>
Mime-Version: 1.0
X-Trace: individual.net
 cecNalM+IVfTVoOBDhQ//AHCIIxy7K71eg54XlOVyjXtSQz++Dauc9h0JYF+xVqkC8
Cancel-Lock: sha1:H0fogFOxTUaRB71yHru3PNU/KQY=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:17.0) Gecko/17.0 Thunderbird/17.0
In-Reply-To: <7NednS4s2oukfXzNnZ2dnUVZ_oadnZ2d@earthlink.com>
Path: 
 s9ni85602pbb.0!nntp.google.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!news.mccarragher.com!news.grnet.gr!goblin2!goblin1!goblin.stu.neva.ru!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
X-Received-Bytes: 2891
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Date: 2012-12-31T23:09:27+02:00
List-Id: <comp.lang.ada>

On 12-12-31 20:52 , Charles Hixson wrote:
> Thank you for your answer.
> 
> The problem with that solution is that I've been advised that I
> shouldn't have many more tasks than available cores,

IMO that advice is useful only if your application logically needs fewer
tasks than you have cores, but you want to increase the number of tasks
in order to have more cores running in parallel. It can then make sense
to replicate some of your tasks (the "pool of worker tasks" idea), so
that several identical tasks work in parallel on the same kind of jobs,
or to split some of your tasks into smaller tasks that work in parallel
on different consecutive steps of a job (the "task pipeline" idea).

As you increase the number of tasks in this way, performance increases
because more tasks can be run in parallel, until you reach one of two
bounds:

1. new tasks have nothing to do, and just wait for input or for some
other task to do something, or

2. all cores are already busy, on average, so new tasks must wait for a
core to become free.

Case (1) means that your application is somehow "I/O bound" or
"communication bound", while case (2) means that your application is
"computation bound". The advice you got applies to case (2).

But if your application logically needs more tasks than there are cores,
because of the way tasks communicate and interact, there is absolutely
no reason to limit the number of tasks to the number of cores, or
anything related to the number of cores. There are applications on
single-core processors with hundreds of tasks.

So if you need an extra task, or ten extra tasks, in order to decouple
the timing of some other tasks from each other, go ahead.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .