Re: [Algorithms] General purpose task parallel threading approach

[Nicholas \Indy\ R. <ar...@gm...>]

On Sat, Apr 4, 2009 at 2:07 PM,  <asy...@gm...> wrote:
> Well, maybe hyperthreading was not a good comparison, but I think you got my
> point on how I'd like to hide the stalls

My point wasn't to show how the comparison itself was bad, but how the
approach is fundamentally flawed in it's own.

> Generally speaking of course all sort of dependencies should be eliminated,
> the question is whether it is reasonable to do so given a way to hide
> latencies those dependencies generate. But eliminating them only makes even
> situation better, that's for sure.

In game development in particular all of those dependencies should
already be eliminated, there should be no waits in existing well coded
game loops.

> The role of efficient job systems currently increases together with the
> number of cores you have in the system.

You're system is hardly a proper job system, a better job system
doesn't need to store a stack or other thread state, and should never
context switch until the work is done, That is the job of a threading
system, which should remain separate.

> The only solution to that problem I know of is to fragment your amount of
> work. And the more cores you have, the more fragmentation you need to
> achieve to keep all your 1024 cores busy, which in the end makes the
> efficiency of a job system more important, don't you agree ?

I agree, but again I think an entire cooperative thread system layered
atop the OS thread system is not the proper proper way to distribute
jobs. Jobs should be designed in a way that context switching during
any particular job would give no benefit, and the existing
hyperthreading implementations should be used to fill in the bubbles
in the pipeline.

> You are right that this benchmark is far away from a real life scenario, but
> there should be a way to estimate the speed. How about comparing the worst
> case scenario for cooperative task approach with the best case one for
> winthreads?

The problem here is that benchmarking anything in regards to context
switch time between fibers and OS threads will be in favor of fibers
because they have less overhead, but they also provide less, such as
the ability to run on multiple CPUs, in an ideal case of a game
(ignoring the OS and other apps on the computer) there should be zero
thread switches. and in that case, it doesn't matter how long a task
switch takes, as it should just never happen. That's like spending
you're time optimizing the MP3 Decoder when you are only using Ogg
anyways.

Indy