Re: [Algorithms] General purpose task parallel threading approach

[Jon W. <jw...@gm...>]

Jarkko Lempiainen wrote:
>
> I don’t really see any benefit of aiming for very high task 
> granularity unless if you try to fill in those aforementioned task 
> starvation bubbles. Unfortunately I haven’t had chance to test my 
> shared job queue past 2 cores so I can’t really tell how well it 
> scales in practice, but since it’s utilizing basic lock-free 
> algorithms, I presume it scales reasonably well.
>

If you had 64 hardware threads, would your view change? We'll be getting 
there in just a few years. Code you write today may very well be 
expected to scale to that level, or it will be considered obsolete and 
have to be replaced.

There is the job queue implementation question (which is what we're 
mostly talking about here), that contains all kinds of 
micro-optimization opportunities (as shown by the asynclib approach), 
that may or may not apply in a particular game situation.

Then there's the question of how to granularize your game so that it can 
actually smear the workload across 64 hardware threads (or some other, 
equally "large" number). That's, in the end, a much more interesting 
question.

Whether your job system uses 100, 1000 or 10,000 cycles to switch jobs 
can easily be measured, but doesn't really affect the scalability of 
your system. Whether you can actually break the work of a single frame 
into 500 individual tasks with as few serial dependencies as possible, 
is much more important in the big scheme of things.

Sincerely,

jw