Re: [Algorithms] General purpose task parallel threading approach

[<asy...@gm...>]

Well, maybe hyperthreading was not a good comparison, but I think you got my
point on how I'd like to hide the stalls

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.

The role of efficient job systems currently increases together with the
number of cores you have in the system. The problem of speed given that many
cores you have available now goes into the direction of "how to deliver the
work I need to do to all execution units you have available (so that they
are all busy)" instead of how to make it run faster on one execution unit.
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 ?


Alexander.

2009/4/4 Nicholas "Indy" Ray <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
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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
>



-- 
Regards,
Alexander Karnakov