Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Re^4: A Just In Time VM for Not Quite Perl

by raiph (Chaplain)
on Jun 04, 2013 at 08:01 UTC ( #1036915=note: print w/replies, xml ) Need Help??

in reply to Re^3: A Just In Time VM for Not Quite Perl
in thread A Just In Time VM for Not Quite Perl

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 # 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

Replies are listed 'Best First'.
Re^5: A Just In Time VM for Not Quite Perl
by Anonymous Monk on Jun 05, 2013 at 00:01 UTC
    Perl 6 has always been at war with Eastasia, got it!
      Heh. Well, I don't got it!

      Fwiw my rewrite was mostly about replacing some of my opinion with that of Whiteknight (one of the leading Parrot committers in the period since Rakudo Star was first released in 2010).

      Ultimately my goal in posting to the News section of PerlMonks is to inform about new things happening in the Perl world. I hate spin. If you, dear AM, or some other monk PM'd me to explain how I have (or appear to have) inserted spin (beyond the obvious aspect that I updated my comment) I would be very happy. :)

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1036915]
and the monastery is silent...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (6)
As of 2018-05-22 20:15 GMT
Find Nodes?
    Voting Booth?