Re^4: A Just In Time VM for Not Quite Perlby raiph (Hermit)
|on Jun 04, 2013 at 08:01 UTC||Need Help??|
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: