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.84.161 with SMTP id a1mr9451978paz.47.1357498039054; Sun, 06 Jan 2013 10:47:19 -0800 (PST) MIME-Version: 1.0 From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: asynchronous task communication Date: Mon, 31 Dec 2012 16:15:49 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <1c2dnd5E6PMDR33NnZ2dnUVZ_sednZ2d@earthlink.com> <50e18094$0$6583$9b4e6d93@newsspool3.arcor-online.net> <7NednS4s2oukfXzNnZ2dnUVZ_oadnZ2d@earthlink.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1356992154 9692 69.95.181.76 (31 Dec 2012 22:15:54 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Mon, 31 Dec 2012 22:15:54 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Path: 6ni88791pbd.1!nntp.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!news.mccarragher.com!news.grnet.gr!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!gegeweb.org!news.ecp.fr!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail Date: 2012-12-31T16:15:49-06:00 List-Id: "Niklas Holsti" 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.