[brrt]

I'm the developer of the MoarVM JIT (but not the developer of the MoarVM bytecode specialisation framework, which is typically seen as part of the JIT).

The weakness of Parrot VM was it's ambition - to be an efficient VM for all dynamic languages. This may have seemed possible in the past but recent work (i.e. v8, luajit2, etc) has invalidated that; it's much better (and much easier) to build a VM for a specific target than for all possible targets, as there are simply fewer points where you need abstraction. (For instance, NaN is false in javascript boolean context, but not in Perl6). More importantly, MoarVM has been designed and developed by a small set of developers applying all the lessons learned from parrot, while parrot was in many ways an experiment by committee.

[chromatic]

You say potato, I say "Parrot was designed to implement the semantics of both Perl 5 and Rakudo in the same process."

You say "It's better to build a specialized VM", I say "Emscripten, Clojure, Niecza, Truffle, and Jakudo."

[brrt]

Well, that's a good point, really. The JVM and the CLR do run many (dynamic) languages quite efficiently. On the other hand, that is in no small part due to the man-centuries spent trying to optimise both the JVM JIT and the language-to-JVM compiler.

And as a counter-example, luajit2 was built by one man (mostly) over the course of a few years, and runs very efficiently indeed, in no small part due to the lua-specific choices that have been made.

So what I'm trying to say is that there is a second tradeoff, somewhere between programmer efficiency, runtime efficiency, and running time, and that MoarVM is making a better tradeoff for perl6 than parrot is.

[themgt]

Thanks, I think this basic "you go to code with the developer resources you have, not the developer resources you might want or wish to have at a later time" is desperately under-appreciated in software architecture

[chromatic]

you go to code with the developer resources you have, not the developer resources you might want or wish to have at a later time

Ha! My experience with Rakudo was "you go to the developer resources you have, tell them not to change anything, then tell them you're going to throw away their work in favor of something you haven't written yet" and then complain when they leave.