Re: [Algorithms] General purpose task parallel threading approach

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

I think you really need to target for both task and data level parallelism
to make your game engine truly scalable for many-core architectures. I don't
see why you would need to consider the cost of context switching in relation
to const of a task execution though since if you got a job queue, each
worker thread just pulls tasks from the queue without switching context.


Cheers, Jarkko


-----Original Message-----
From: Jon Watte [mailto:jw...@gm...] 
Sent: Sunday, April 05, 2009 2:11 AM
To: Game Development Algorithms
Subject: Re: [Algorithms] General purpose task parallel threading approach

I think the idea of a thread per subsystem (particles, skinning, 
collision, simulation, audio, scene graph issue, etc) will only scale so 
far. Once you have 64-way CPUs (like the latest Sparcs) and even more 
with Larrabee (if you include the hyper-threads), making your game (or 
any software) go fast will mean a task-oriented workload, rather than a 
subsystem-oriented workload. As long as your tasks are significantly 
heavier than context switching, you're doing fine. That's what the 
fibers-within-threads tries to optimize. There probably exists a 
real-world workload where the efficiency of fibers leads to measurable 
throughput, even though the overhead of fibers or threading is not 
dramatically large compared to the workload, but I think that slice is 
pretty thin. It all comes down to Amdahl's Law in the end.

Sincerely,

jw


----------------------------------------------------------------------------
--
_______________________________________________
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