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". Tim.
