Some Requests from Rakudo

Andrew Whitworth wknight8111 at
Fri Aug 19 23:28:48 UTC 2011

On Fri, Aug 19, 2011 at 7:38 AM, Patrick R. Michaud <pmichaud at> wrote:
> FWIW, I think a useful place to start playing with threading in
> Rakudo would be the hyperoperators.  In src/core/ there's
> a multi sub hyper(\$op, \$obj) that performs an operation ($op) on
> all of the elements of the list in $obj.  This ought to be a very
> good candidate for parallelization.

Hyperoperators are the example we've heard about most often, but are
also a particular case. Hyperoperators, from my understanding of them,
would seem to benefit more from light-weight green threads (greenlets,
stackless threads, whatever you want to call them) than heavier-weight
OS-level threads. Actually, I think they would benefit well using a
hybrid approach, you do need multiple channels to dispatch the
greenlets to.

If we had an API available in Parrot that would use continuations to
simulate green threads, with the promise that eventually they would be
backed by an OS-thread dispatcher, I think that would be a good first
step. We would get to start playing around with the primitives and
APIs necessary, and be able to implement the details later.

> For the last several months I've been advocating that Rakudo simply
> implement (and explore) async I/O in the Rakudo repository for a while,
> so that Rakudo can figure out what primitives we'd like to have.  Then
> when we've identified those primitives, we can look at how to provide
> them in Parrot.
> The basic idea is that it's simpler to do rapid experimentation and
> exploration within just one repository (i.e., Rakudo) than to try to
> coordinate between two of them.  When things are stabilized, then
> we can see if it makes sense to move an implementation into Parrot
> for use by other HLLs.  (This is similar to the approach we've taken
> with 6model.)

As a tangential note, migrating 6model into Parrot and integrating it
into the VM fully could potentially be as much work or more than
implementing it in NQP as originally. It's not the same kind of
effort, and it might not all have been avoided had 6model been
developed directly in the Parrot repo, but it is something to think

Like with 6model, if NQP/Rakudo come up with a compelling system while
we're still unable to finalize a design for ourselves, it's very
likely that we would try to *borrow* it in Parrot core directly.
What's standing in our way right now is the need to support multiple
different languages. We want to provide something, but if we provide
too much it's going to create problems with different HLLs, etc. If
Rakudo can prototype some of the bare-minimum primitives they need, it
might become a good platform for us to build up from.

--Andrew Whitworth

More information about the parrot-dev mailing list