• NQP (Not Quite Perl) is a Perl 6 subset, much smaller than Perl 5 or Perl 6. The first version of NQP was started and finished around 2007. NQP is designed to be ideal for writing compilers. The NQP compiler is (mostly) written in NQP. The Rakudo Perl 6 compiler is also (partly) written in NQP (most of the rest is Perl 6).

• The Parrot VM is a backend target for NQP. Unfortunately Parrot has fallen far behind the evolution of NQP (and related pieces, especially 6model) with all sorts of negative consequences.

• MoarVM, quietly written by a small team over the last 14 months or so, is a new backend target for NQP. It is specifically designed for NQP/6model.

• Today MoarVM reached the point where it is cross-compiling itself and Jonathan Worthington considered it worth revealing to the Perl 6 community, especially given that the YAPC::NA hackathon starts tomorrow. (I, in turn, thought it was worth specifically mentioning at the Monastery, in case some monk(s) wish to check it out and maybe get involved in the hackathon virtually.)

I recommend interested monks pay close attention to the news coming out of YAPC::NA 2013 that starts tonight in Austin, TX and/or join #moarvm on freenode (log).

Hth.

Hang on..

You still don't give us the complete details. If the JVM effort was underway doesn't it make sense to finish it and then start on something else?

We still don't have a feature complete stable release on one VM. What is the whole point in producing half complete implementations on so many VM's. While efforts could have rather spent on producing one feature complete stable implementation on one VM.

As of now it really looks like there are too many abandoned projects, too many re writes and too many sub project time sinks preventing anything worthwhile to come out of this whole exercise

If anything adding MoarVM to picture now. The entire Perl 6 production release got delayed by another 2 years. Porting Rakudo to MoarVM looks like a 6-8 month exercise and after all that you wouldn't have added a single user facing enhancement to the whole product.

If the JVM effort was underway doesn't it make sense to finish it and then start on something else?

Maybe, but it was the other way around -- MoarVM was started about 8 months before the JVM port was started. The question should properly be, why did they start a JVM port?

We still don't have a feature complete stable release on one VM.

Right, but the issue is the "one VM". The Rakudo team have made Rakudo relatively complete, stable, and generating code that ought to be fast. But the "one VM" that Rakudo has been running on, Parrot, is too slow, buggy, and complicated.

Rewrote next two paragraphs:

Some history, aiui. After the launch of Rakudo Star in 2010 the Rakudo team increasingly impressed upon the Parrot team that Parrot was a long way from what Rakudo needed, especially speed-wise, and was too heavily burdened with extraneous baggage. By mid 2011 the smoke had cleared and there was a written commitment to Rakudo as the #1 "customer", a strong desire to switch to 6model, and talk of rewriting much of Parrot. However, many contributors bailed in 2011 and by early 2012 the Rakudo team decided they needed to have a backup plan. They still needed a custom VM to realize several central Perl 6 features (not least its potential for unrestricted efficient execution of features like NFG) so existing VMs like the JVM would not cut it. In early 2012 a small group started MoarVM.

So the remaining questions are things like why wasn't the JVM good enough; conversely, given that they had started MoarVM, why did they chose to start a port to the JVM; why didn't they wait until MoarVM was ready, then port to that, and ignore the JVM until MoarVM was done; why didn't they use an existing lightweight VM or VM kit to build MoarVM? Well, they've given their reasons in blog posts and I find them compelling. YMMV.

Porting Rakudo to MoarVM looks like a 6-8 month exercise and after all that you wouldn't have added a single user facing enhancement to the whole product.

The universal user complaint is that Rakudo is far too slow. If they do nothing but radically speed Rakudo up they'll have fixed what Larry Wall has said he thinks is the #1 blocker in the way of mass adoption.

Update: Fwiw I just visited #moarvm and saw the following fibonacci benchmark comparison:

$ parrot fib.pir         # Parrot
fib(28) = 317811
start      : 1370329827.014
end        : 1370329829.229
end - start: 2.21500015258789
 
$ perl fib.pl           # Perl 5
fib(28) = 317811
start      : 1370329768.826
end        : 1370329769.45
end - start: 0.624000072479248
 
$ nqp bench/fib.t       # MoarVM
fib(28) = 317811
start      : 1370329844.736027
end        : 1370329845.001228
end - start: 0.265201
[download]

is Parrot finally abandoned?

Rakudo is the #1 "customer" for Parrot. In the slides for a talk at this year's YAPCNA this week the Rakudo pumpking says the Rakudo project is "Not abandoning Rakudo-on-Parrot" and "Not designating a primary VM platform for Rakudo".

Update (Nov, 2015): Rakudo project leader Patrick Michaud suspended Rakudo support for Parrot in Feb 2015. It looks near certain that the only officially supported Rakudo backend for the 6.c release due this christmas will be MoarVM.

The project remains active. (Commits to the parrot repo.) There were discussion and commits on #parrot today. These were mostly about an idea timotimo (a #perl6er) had that he thought could significantly improve Parrot startup performance. The code changes that would be necessary turned out to be too hard and inappropriate. Benabik committed some changes that didn't really do what timotimo was suggesting and sadly noted that "My list of "how would I change parrot given my current knowledge" ends up looking extremely similar to MoarVM. :-/".

I'm pretty sure there's at least one GSOC student set to work on some Parrot tech this summer.