Re: [Algorithms] General purpose task parallel threading approach

[Sebastian S. <seb...@gm...>]

On Sun, Apr 12, 2009 at 9:39 AM, Jarkko Lempiainen <al...@gm...>wrote:

>  Well, I see the good task prioritization as a dominating factor in task
> scheduling, e.g. if you save even 1ms shared across /all/ the threads due to
> better scheduling, you have already gained the overhead of executing ~5000
> tasks in a frame. But you seem to disagree that task prioritization gains
> you anything, am I right?
>
Sort of, Jon Watte demonstrated an example where vanilla work stealing could
lead to sub-optimal scheduling, so I agree in principle that it could
happen. But as I said later you'd have to be in a very specific circumstance
for that to actually lead to an issue in reality - you'd need to have all
your threads saturated when you start scheduling, and then you need to have
a bunch of thread idle right after the "high priority task" is scheduled
last. This seems unlikely, and benchmarks seem to show empirically that it's
uncommon enough to not be an issue.

So I agree that it could lead to an issue in principle, but I'm not sure it
actually happens in reality to the extent where it's worth spending cycles
up front to combat it. Benchmarks would convince me though!


> And then there are of course issues with the cache coherency and programmer
> productivity, so individual task overhead seems to pale in comparison when
> speaking of such a small differences (in cycles) and not something really
> worth optimizing further.
>
Yes, I would guess that scheduling based on cache coherency is probably
worthwhile, and I believe intel is doing this for their TBB.


-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862