Re: asynchronous task communication

["Randy Brukardt" <randy@rrsoftware.com>]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:aked87Fpfc1U1@mid.individual.net...
> 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.

Right, I touched on this last week. The issue is the amount of CPU load for 
each task, not the raw numbers of tasks.

Most tasks spend most of their time blocked (the mailbox tasks surely are in 
this category). Such tasks don't contribute much to the CPU usage and surely 
shouldn't be counted as "using up a core". Tasks that are intended to be 
running most of the time do "use up a core", but even then, you may be 
better off structuring your program with more tasks.

Someone else touched on it, but premature optimization is a very common 
evil. And that extends just as much to the use of tasks as it does with 
anything else.

                                        Randy.