The Parrot is dead. Long live the Parrot?

[Andrew Whitworth]

On Tue, Feb 12, 2013 at 9:23 PM, Allison Randal <allison at parrot.org> wrote:
> Well, yes. You're pretty much walking through exactly the same things we
> all walked through on IRC over the weekend.

I'm sorry I missed that. I haven't been avoiding IRC on purpose.

> Parrot will never outdo the JVM or .Net on their own playing fields. But
> it might beat them *for Perl 6*, by being lighter, faster, more tightly
> adapted to the needs of Perl 6 as a language, and just flat-out more
> Perlish. That's something JVM and .Net will never do.

Like Parrot, Perl6 is built on a strong foundation of "I really hope
this goes as well as we've planned". There's no saying that "Perlish"
in the Perl6 sense is going to turn out to be a benefit in the end.
Some of the coolest features of Perl6 from a usability standpoint are,
I suspect, going to be revealed to be some of the worst and most
limiting in terms of performance. Sometimes you do have roll the dice
and hope things turn out in your favor.

How many people complain about JavaScript, but still use it
exclusively because it's become blindingly fast? But then again,
JavaScript is blindingly fast because it runs on a dedicated VM which
has been tuned and optimized from top to bottom to account for the
idiosyncrasies of that language. If Perl6 wants the same relationship
with a VM (and maybe somebody should ask them whether they even want
Parrot to try), that may be the only hope they have of getting up to a
similar level of performance (and that's debatable, considering
Parrot's poor track record in the realm of performance).

I'll agree there are some interesting bits. But Parrot's performance
failings do not stem from our neglect of micro-optimizations, or from
a small number of untuned variables.

Almost every single part of Parrot is not thread-safe. The threading
system we merged goes through a lot of effort to work around those
problems, but if you ever want threads to be useful and speedy you're
going to need to do a hell of a lot of work.

The impedance between NQP and Parrot is the biggest area of concern.
If you completely rip out all of the PMCs, the entire PMC system, the
entire object model and the entire namespace system you should be able
to integrate 6model much more closely into Parrot core and speed up
basic object operations by a factor of 2 or more. Of course, you'd
have to rewrite much of 6model to not rely on the existence of PMCs,
and you'd have to perform initialization of it in the interp creation
routines instead of through an opcode at runtime. This is non-trivial
work but if it could be done there would be a fighting chance.

You absolutely must complete the work we started of trying to have
Rakudo generate bytecode natively instead of using PIR as an
intermediary. The effects on compilation (and script interpretation)
performance is debilitating. IMCC needs to be taken away and burned in
a fire. NQP needs to be updated to output Parrot bytecode directly.

You'd have to rip out CallContext and the entire PCC system, and
replace it all with NQP's dispatcher and argument binder (which,
again, would need to be rewritten to account for this missing
infrastructure). If you can do this, you'll see a nice performance
bump in every single method invocation, which will make for much
speedier programs and much snappier compilation times of the Perl6
core.

Our current memory system and GC are very nice, but they are tailored
for PMCs and aren't thread-safe. Unfortunately, if we really want to
push Parrot to be the bleeding edge for Perl6 speed, these are going
to need to be rewritten too. I recommend an explicitly concurrent
algorithm like VCGC, with some tweaks. I suspect we also want a system
like what V8 uses for keeping native types unboxed, although Perl6
might not need it as much as JS does.

Do yourself a favor and delete all the PDDs and most of the existing
documentation. If you're refocusing Parrot to be the Perl6 engine, our
existing designs are all worthless. Some of them have always been
worthless, but now the rest of them are too.

In .NET and JVM, things like the object model code and method dispatch
code are all going to be exposed to JIT and a good tracing JIT will be
able to speed them up faster than any C code we write in Parrot for
tight loops. If Parrot wants a similar benefit, it's going to need to
do the same. This means not writing those bits in C, but instead using
Lorito (or something even more exotic, like LLVM or PyPy).

As much as I'd love to help with all this (and it is all very
interesting stuff) I'm suffering from a severe case of burnout and
need some time away. I'm always happy to talk and offer suggestions
and help with planning, but the work of coding is going to be left to
somebody stronger, more capable and more motivated than I am.

--Andrew Whitworth