Re: [Algorithms] General purpose task parallel threading approach

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

On Sat, Apr 4, 2009 at 11:09 AM,  <asy...@gm...> wrote:
> Blocking is only part of a problem (I used it for demonstration purporses
> basically), on top of that you have all sort of IO and task dependencies.

These are all variants on blocking, it's best to eliminate these dependencies.

> You can compare my approach to hyperthreading in hardware world which is
> becoming more and more popular these days (sun's ultrasparc, intel's
> larabee, and gpus are also using that scheme as far as I'm aware of).

I can't speak on ultraspec, but neither larabee or GPUs use
hyperthreading as the main form of threading (or afaik at all) They
are both data parallel architectures primarily. Additionally,
hyperthreading is build to fill bubbles in the pipeline and do such
rather well because they don't have to worry about any sort of context
switch, as the threading is implemented in hardware and multiple
states can actually be active at the same time.

> Hyperthreading switches virtual threads when currently executed thread needs
> to wait on something (lime memory access to finish). Is it needed ? Not if
> you layout your data in a way where you don't have memory access latencies,
> but you usually do have them, because in many cases to eliminate latencies
> is very difficult/time consuming/completely not possible to do.

Keep in mind that there is 0 context switch overhead in
hyperthreading. Additionally, eliminating cache stalls is far more
difficult then blocking IO and the like.

> I'm not saying that one should not plan his code for asynchronous execution
> scenario, but the delays because of all sort of blocking conditions can be
> hidden like it happens in hyperthreading.

Additionally hyperthreading still requires threads to be designed in a
way that is low on data contention. And if you already have worker
tasks that can do such, It's generally best to create OS threads and
just let them run on separate threads or hyperthreaded. But still
ensure that the main thread does no waiting. In a well designed
system, thread switches are a non-issue as they just shouldn't happen
very often (or at all in the case of consoles) So I don't think it's
worthwhile worrying too much about the amount of time it takes to do a
thread switch.

Indy