gsoc_threads branch feedback
Patrick R. Michaud
pmichaud at pobox.com
Fri Aug 27 11:00:37 UTC 2010
On Thu, Aug 26, 2010 at 01:57:08PM -0400, Nat Tuck wrote:
> - Does the Task API I've implemented[1] make sense?
> - Is there anything important missing?
> - What blocking operations should I be handling aside from file input?
I can't knowledgably answer these questions yet, but I can relay
that one of Rakudo's explicit goals for the upcoming year is to implement
"threaded versions" of Perl 6's hyper (meta) operators. In other words,
we'd like things like
my @c = @a >>+<< @b;
to actually perform the array addition in "parallel" instead of
sequentially as we do now, even if "parallel" just means it's
emulated somehow for now and isn't really multithreaded underneath.
(If it is actually multithreaded underneath, that's a huge bonus.)
So, perhaps some enterprising person could look at this a bit
further and say "Here's how you can achieve the above using
the Task API" or "The Task API doesn't quite handle this yet, what we also
need is ...".
If it helps at all, the code that Rakudo currently uses for
the hyper operators currently looks something like (golfed from
original in src/core/metaops.pm):
our multi sub hyper(&op, @lhs, @rhs) {
my @result;
for @lhs Z @rhs -> $l, $r {
@result.push( &op($l, $r) );
}
@result;
}
Of course, this does the operation sequentially; we'd like
to see it perform the operations in parallel. Note that Perl 6
hyper operators explicitly assume that &op($l,$r) is side-effect
free, so there's no need to preserve any sequential semantics.
Even just having some suggested PIR for achieving something like
the above using the Task API would be a huge aid to Rakudo devs.
Pm
More information about the parrot-dev
mailing list