Re: [Algorithms] General purpose task parallel threading approach

[Mat N. <mat...@bu...>]

> Which is what I've been trying to say all this time. If the scheduler can't handle dynamic code, then it's not really a general system.

That's like saying if you can't handle dynamic allocations your game isn't truly dynamic. Well, maybe not, but what Jon said does not necessarily lead to what you said. It simply means that any dynamic behavior changes what happens between frames, not within a frame. That does not necessarily restrict "dynamic" code from ever working, just the mechanisms through which it can work.

In other words, it moves the dynamic behavior to specific spots rather than allowing it anywhere. Which is a good thing in general(tm).

MSN
From: Sebastian Sylvan [mailto:seb...@gm...]
Sent: Monday, April 13, 2009 3:16 AM
To: Game Development Algorithms
Subject: Re: [Algorithms] General purpose task parallel threading approach


On Mon, Apr 13, 2009 at 4:17 AM, Jon Watte <jw...@gm...<mailto:jw...@gm...>> wrote:


Up front at the start of a frame, not up front at the start of the program.

Of course. Never thought you meant anything else.

>
> If you read more carefully I've given you two examples of how tasks
> using polymorphism can not be scheduled ahead of time either. Any kind
> of dynamic control flow needs an on-line scheduler.
Sure it can! You just have to say that polymorphism isn't allowed to
cause new tasks to get spawned synchronously.

Which is what I've been trying to say all this time. If the scheduler can't handle dynamic code, then it's not really a general system.

I've given you several examples of very mundane and common uses of dynamic control flow that wouldn't be possible for this reason, so I believe I've made my point pretty clear on why this is unlikely to be acceptable for me at least (especially since the benefits are requiring these restrictions are highly dubious, IMO).


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