6 ms·

IIRC the new VM (MoarVM) is around for quite a short time and it replaced Parrot in a dramatically short time. What are the advantages of MoarVM over Parrot and

by xiaq 12y ago

IIRC the new VM (MoarVM) is around for quite a short time and it replaced Parrot in a dramatically short time. What are the advantages of MoarVM over Parrot and why were we stuck at Parrot for so long before giving it up?

brrt 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      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 12y ago
        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.
perlgeek 12y ago
> What are the advantages of MoarVM over Parrot Mostly that MoarVM developers could learn from all of Parrot's successes and mistakes, while not carrying any of the historical baggage. That means cleaner design, less memory footprint, faster execution. > and why were we stuck at Parrot for so long before giving it up? Rakudo works on Parrot. Why drop support for it? Once you frame the question that way, the answer becomes obvious: because there hasn't been big changes to the code generation yet that would make continued parrot support painful. Once we reach that point, the situation will be reconsidered.
- chromatic 12y ago
  Mostly that MoarVM developers could learn from all of Parrot's successes and mistakes, while not carrying any of the historical baggage. I think you're being uncharitable. It's clear enough in retrospect that plenty of Rakudo developers wanted to get rid of Parrot years ago, but wanted to couch their "Let's burn it all down and start over" in much more careful terms which allowed them to take advantage of Parrot's stability when marketing P6 to the outside world while using Parrot's concomitant lack of development to prove that they'd made the right choice.
  - perlgeek 12y ago
    > I think you're being uncharitable. It's clear enough in retrospect that plenty of Rakudo developers wanted to get rid of Parrot years ago I think you are being uncharitable. It's clear now as it has always been to me that the Rakudo developers wanted a working, fast VM that provides the needed features. Since Parrot couldn't deliver this, it was just naturally to look for alternatives. Also, it makes me sad that you argue a lot about Rakudo's and Parrot's past, but seem to neglect their current state or the future. Could it be that you care more about how Parrot will be remembered, then about how it does today?
  - kbenson 12y ago
    That's... an odd way to start a response in which you are very obviously being uncharitable yourself in assessing the motivations and actions of real people. What's more, you are doing it as a non sequitur. I'm really not sure what you're trying to say here. How is a later project being able to look at what came before and try to determine what decisions were good and bad of the prior project and trying to avoid them being uncharitable, and what does that have to do with whether some people wanted something different long ago?

by xiaq 12y ago

brrt 12y ago

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 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      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.

perlgeek 12y ago

> What are the advantages of MoarVM over Parrot Mostly that MoarVM developers could learn from all of Parrot's successes and mistakes, while not carrying any of the historical baggage. That means cleaner design, less memory footprint, faster execution. > and why were we stuck at Parrot for so long before giving it up? Rakudo works on Parrot. Why drop support for it? Once you frame the question that way, the answer becomes obvious: because there hasn't been big changes to the code generation yet that would make continued parrot support painful. Once we reach that point, the situation will be reconsidered.

chromatic 12y ago
Mostly that MoarVM developers could learn from all of Parrot's successes and mistakes, while not carrying any of the historical baggage. I think you're being uncharitable. It's clear enough in retrospect that plenty of Rakudo developers wanted to get rid of Parrot years ago, but wanted to couch their "Let's burn it all down and start over" in much more careful terms which allowed them to take advantage of Parrot's stability when marketing P6 to the outside world while using Parrot's concomitant lack of development to prove that they'd made the right choice.
- perlgeek 12y ago
  > I think you're being uncharitable. It's clear enough in retrospect that plenty of Rakudo developers wanted to get rid of Parrot years ago I think you are being uncharitable. It's clear now as it has always been to me that the Rakudo developers wanted a working, fast VM that provides the needed features. Since Parrot couldn't deliver this, it was just naturally to look for alternatives. Also, it makes me sad that you argue a lot about Rakudo's and Parrot's past, but seem to neglect their current state or the future. Could it be that you care more about how Parrot will be remembered, then about how it does today?
- kbenson 12y ago
  That's... an odd way to start a response in which you are very obviously being uncharitable yourself in assessing the motivations and actions of real people. What's more, you are doing it as a non sequitur. I'm really not sure what you're trying to say here. How is a later project being able to look at what came before and try to determine what decisions were good and bad of the prior project and trying to avoid them being uncharitable, and what does that have to do with whether some people wanted something different long ago?