Some Requests from Rakudo

Andrew Whitworth wknight8111 at
Wed Aug 17 12:23:50 UTC 2011

On Wed, Aug 17, 2011 at 7:01 AM, Christoph Otto <christoph at> wrote:
> 1) Threading ...
> 2) Asynchronous I/O ...

These are going to be done at the same time. We're not going to have
AIO until we have at least basic threading support. What we need is a
good plan/design for a new system going forward. I had put forward
some ideas a few weeks ago, but I got a lot of good feedback and am
not so sure about some of the specifics now. Rakudo could serve as a
major driver in this area. The kind of system and the kinds of designs
we pursue could be significantly influenced by what Rakudo wants.
Also, if they have some hackers who want to get their hands dirty,
that's a big help too. The people doing the work are going to play a
major role in setting the overall direction.

> 3) sub cloning ...

I published a blog post last night addressing some of these issues,
and I've started an exploratory branch locally to try and cut down
some of the cruft of the Sub PMC. I can expand on some of my
short-term plans on IRC or in another blog post. Longer-term, the
specific goals are a lot more fuzzy. Again, guidance from the Rakudo
folks to help direct our efforts would be very welcome.

> 4) PCC ...
> 5) invocation ...

I have several ideas with respect to these items, some of which have
made it into blog posts. I've also done some comparative timings and
found that we can make some improvements to invocation performance by
adding a few new specialty PIR opcodes and avoiding the use of
fill_params and friends. The one area where I don't have a concrete
solution is a replacement for ":named :slurpy" parameters. I know NQP
makes some use of those, so we can't abandon them completely and we
can't have them be slower than the current implementation. We can chat
more about this on IRC, or I can write up more thoughts in a blog

As we've said before, profiling tools will be helpful in this regard,
so we want to give that a nudge in the forward direction.

If people besides myself have ideas for any of these things, please
start making them public. They are all places where Parrot needs to
improve, but the paths we need to take to reach those improvements are
not straight-forward. The more input we have to guide decisions, the

--Andrew Whitworth

More information about the parrot-dev mailing list