gsoc_threads branch feedback

[Nat Tuck]

Patrick -

Attached is an example of logically concurrent hyperoperators with
Tasks in PIR. With the current implementation this would only really
make any sense if the operator being parallelized was file input,
otherwise it'll just run slower than the loop you've got.

Even once Tasks really run in parallel, this isn't the implementation
you'd want for simple ops like addition. This is the old granularity
of parallelism problem, and the hyper sub you've got there - where you
don't know how expensive &op is - is sort of a nightmare.

-- Nat

On Fri, Aug 27, 2010 at 7:00 AM, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> 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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hyperadd.pir
Type: application/octet-stream
Size: 1568 bytes
Desc: not available
URL: <http://lists.parrot.org/pipermail/parrot-dev/attachments/20100827/f4e96d39/attachment.obj>