Re: [Algorithms] General purpose task parallel threading approach

[Jarkko L. <al...@gm...>]

No, it wouldn't change my view, because that's what I'm already thinking.
What would change my view though, is that if there were hundreds of threads
which would run in significantly lower frequency (e.g. few hundreds of Mhz
instead of 2-3Ghz), in which case you would need to split your work to
smaller pieces. Like I said to Sebastian, only thing you care is that your
job's execution time is relatively small fraction of the entire frame time,
so in the end it's the frame time and thread frequency which determines your
ideal task size. Ideal task size isn't smallest possible unit of work though
because of the overhead of distributing the work. Well, that's what I think
anyway (:


Cheers, Jarkko


-----Original Message-----
From: Jon Watte [mailto:jw...@gm...] 
Sent: Tuesday, April 07, 2009 8:14 PM
To: Game Development Algorithms
Subject: Re: [Algorithms] General purpose task parallel threading approach

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


----------------------------------------------------------------------------
--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list