On Sun, Oct 17, 2010 at 01:18:09AM +0200, Carl Mäsak wrote:
> Damian (>>), Matt (>):
> >> Perhaps we need to think more Perlishly and reframe the entire question.
> >> Not: "What threading model do we need?", but: "What kinds of non-sequential
> >> programming tasks do we want to make easy...and how would we like to be
> >> able to specify those tasks?"
> >
> > I watched a presentation by Guy Steele at the Strange Loop conference on
> > Thursday where he talked about non-sequential programming.  One of the
> > interesting things that he mentioned was to use the algebraic properties of 
> > an
> > operation to know when a large grouping of operations can be done 
> > non-sequentially.
> > For example, we know that the meta reduction operator could take very large 
> >lists
> > and split them into smaller lists across all available cores when 
> > performing certain
> > operations, like addition and multiplication.  If we could mark new 
> > operators that
> > we create with this knowledge we could do this for custom operators too.  
> > This isn't
> > a new idea, but it seems like it would be a helpful tool in simplifying 
> > non-sequential
> > programming and I didn't see it mentioned in this thread yet.
> This idea seems to be in the air somehow. (Even though all copies of
> the meme might have its roots in that Guy you mention.)
>  <http://irclog.perlgeek.de/perl6/2010-10-15#i_2914961>
> Perl 6 has all the prerequisites for making this happen. It's mostly a
> question of marking things up with some trait or other.
>     our multi sub infix:<+>($a, $b) will optimize<associativity> {
>         ...
>     }
> (User-defined ops can be markes in exactly the same way.)
> All that's needed after that is a &reduce sub that's sensitive to such
> traits. Oh, and threads.

Minimizing the overhead of such a mechanism would be crucial to making
it beneficial for use on non-massive data sets.

For this kind of thing to work well we'd need to have multiple threads
able to work in a single "interpreter".


Reply via email to