Re: [Algorithms] General purpose task parallel threading approach

[Sebastian S. <seb...@gm...>]

On Fri, Apr 10, 2009 at 12:49 AM, Nicholas "Indy" Ray <ar...@gm...>wrote:

> On Thu, Apr 9, 2009 at 4:25 PM, Sebastian Sylvan
> <seb...@gm...> wrote:
> > And of course, general code doesn't have a static call graph, so it's
> even
> > impossible to do this analysis unless your code happens to be simple
> enough
> > (see: the halting problem).
>
> I've found the barrier for "simple enough" to actually be rather high,
> especially when writing special case analysis (dehydra has been used
> in mozilla to build simple call graphs
> https://developer.mozilla.org/en/Dehydra). But often it turns out that
> building a call graph for optimization during a profile like stage is
> very effective, It's easy to get real call data, and you don't have to
> worry about the halting problem.
>

Yes, profile guided optimization is definitely promising.It would seem to me
that the most gainful use would be not to reorder task execution, but to
determine which tasks would be more efficient to execute inline. In other
words, the programmer would call "spawn" *everywhere* with no regard to the
overhead, and the profiler would figure out which one of those to ignore.
I seem to remember some research out of MSR doing this to Haskell programs
and getting good speedups (but of course Haskell programs don't need manual
markup of potential parallelism since they're purely functional - the
profiler would insert the parallism "sparks" for you in the correct places).

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