[Perl 6] A poll about VMs.

poll_perl6_vms

Hey!

This is a poll about VMs for Perl 6. It would be awesome if you fill it,
just write a comment with your answers or fork it and edit.

I need it because I work on a huge summary (including, among the others, statistics, tests)
of VMs and Perl 6 itself.

Thank you very much in advance!
sergot


THE POLL


Your knowledge

1. Which VMs for Perl 6 do you know?

2. What are their defects (e.g. too long execution) and
how hard is it to fix them (how long would it take, how many people can do this etc.)?

3. What is the worst and the best thing about those VMs?


Your choice

4. Which VM do you use most often?

5. Why do you use this VM? (please write all known advantages and disadvantages)

6. Do you know any bugs in this VM?

7. How do you think, which VM would have the greatest future? Which one would be "the chosen one"?


Others

8. You can write some useful information about VMs, links etc.


Do not hesitate to criticize this poll, suggest new questions, correct any mistakes and so on.
Thank you! :)

PS.
If you want to contact me, you can find me on:
#perl (irc.perl.org)
#perl6 (irc.freenode.net)

my nickname is "sergot".

1. in case of rakudo: parrot, jvm, moar and js; for niecza: .Net/mono

2. parrot: a bad garbage collector: only as a last resort it cleans up dead objects...
   jvm: a painful startup time usually about 6s
   moarvm: it is very young and so it is not impossible to crash the vm
   .Net/mono: no idea

3. parrot: bad: almost unmaintained (only a single dev atm); good: it is the most stable vm for rakudo
   jvm: bad: it is a memory hungry monster; good: it runs everywhere, even on coffeemachines
   moarvm: bad: string ops are slower than on parrot; good: it is lightwight and focused for rakudo's needs, and it is usually faster on all topics except strings
   .Net/mono: no idea

4. MoarVM

• it is tiny, and when you search for bugs the code is very transparent
• It is blazingly fast when you rebuild nqp+rakudo are when you run many small scripts like the spectests, this makes for a very short developement turn-around, like when you implement new features in rakudo.
• Everything is under our control, so it gives the thread model rakudo needs, or the string model it will need in future.

6. yes, for example there are issues when you precompile a module and access a lexical (var/sub) from an our-scoped subroutine.

7. definitly MoarVM, it already outpowers Parrot, and it is unlikely that there will be a better VM in the next years.

8. http://moarvm.org :o)

https://github.com/papers-we-love/papers-we-love/tree/master/virtual_machines
http://jnthn.net/articles.shtml

Same as FROGGS, plus:

1. https://github.com/fperrad/tvmjit/tree/master/t/nqp

2. jvm: good: runs long running code fastest

http://irclog.perlgeek.de/perl6/2014-04-04#i_8539775

1. Rakudo's Parrot, JVM, MoarVM and (to a lesser extent) JS backends. Niecza's .Net/Mono backend.
2. Rakudo on Parrot has weird error messages sometimes, and it's slipping behind in some specialized areas such as concurrency. Rakudo on the JVM has a looooong startup time, but runs pretty fast. Rakudo on Moar has the best startup time, but does the occasional nosedive/segmentation fault. (But that's getting better day by day.)
3. Same answer as FROGGS and raiph combined, plus this: I like Niecza because it sometimes produces answers that are different enough to Rakudo. Something that is advertised as "impossible" in Rakudo can sometimes run in Niecza. This produces a nice contrasting perspective, and a starting point for internals discussions.
4. I'm on MoarVM nowadays, but I switched (from Parrot) quite recently, and I haven't done as much development as usual lately. But my blog engine successfully runs on Moar (and faster, too!).
5. I use MoarVM because it's actively maintained, it's fast in the fields I care about, I can see a bright future for both MoarVM and nqp, and even though concurrency primitives are not fully there yet, I know they will be soon. In the senses that MoarVM is still a bit unstable, I use it because I'm an early adopter (and I'd rather I catch and analyze those bugs than later adopters).
6. I checked with RT and it turns out I have reported one bug specific to MoarVM. Not sure how deep this one goes, but something is wrong with number representation on just that VM, for some reason.
7. I think people will keep using Parrot for quite some time, because of its stability. I think people will increasingly use the JVM because of its already-in-place JIT optimizations and its long-running scripts performance characteristics. And I think people will continue to flock around Moar (as both developers and end users) and form a nice, healthy, thriving community that keeps improving the Perl 6-dedicated VM. So if I may, I'd like to invalidate the questions by answering "it depends" on the "greatest feature" question, and "no" (à la pmichaud++) on "the chosen one" question. :) Having said that, I predict that I will mostly be running MoarVM in the next few years.
8. I would like to recommend Dan Sugalski's blog about early-ish Parrot development. It's especially instructive to read what were once the plans for Parrot in the light of what we know today. Much to learn in those archives.

https://gist.github.com/slunski/9970983

http://irclog.perlgeek.de/perl6/2014-04-04#i_8540716

I am limiting my answer to rakudo because I don't know the other implementations
Than I describe the benefit dynamically downloading moar bytecodes bundled in archive (TBD)
which would be more or less like jar files ; I don't think it is specced.

1. -Parrot : Soon, parrot will be history. It was useful when there was no alternative.
   -JVM is nice for interoperability with the Java world but the start up time makes it inappropriate for Perl as
   a scripting language where it can be called from a shell for minute tasks
   -Moar : Except for this interoperability, Moar is the appropriate VM. It may eventually interact
   with Java bytecode as well using some of the machinery of the JVM backend. Knowing that Parrot is
   history, the last remark make the question moot. The only VM would Moar subsuming the JVM one.
   -V8: But the greatest opportunity would be a modified V8 backend that would know about moar bytecode.
   Such a modified V8 in web browsers that would mean the end of javascript as the sole language.
   That would solve the Perl visibility because everything web would be Perl seen as a meta language
   to implement any other for writing client web code.

If I understand correctly, moar bytecode is portable. This mean we can distribute small binary rakudos
that download moar archives when needed from CPAN servers. A moar bytecode is for a compilation
unit. A moar archive, tentatively using .armor as a suffix, would bundle many moar bytecodes possibly
from many CPAN modules. Bytecodes in archives would be ordered from the more used to the less so
that execution can begin before the whole loading.
So a module that is dependant on many others can bundle everything in a single .armor
Usually, to save memory, except when explicitely requested, rakudo-moar will load only the latest version
of a module. So it will not use every bytecodes in an armor because when he locally got a more recent version of a bytecode. But using a wholesale armor could be a failsafe backup solution in case of problem.

1. Parrot, JVM, MoarVM, also .NET (CLR) which niecza is running on.
2. MoarVM is a magical wonderland and has no bad sides :D
   JVM has a slow startup time, which is unbearable in development.
   Parrot is basically inferior to MoarVM in every possible way these days, and I don't ever expect it to get better; Parrot development is almost nonexistent.
3. Best things:
   Parrot: module ecosystem support
   JVM: speed, once JIT kicks in; very nice parallel capabilities
   MoarVM: speed; amazing development progress
   Worst things:
   Parrot: almost a complete lack of non-blocking IO, lack of threading
   JVM: glacially slow startup/compilation times
   MoarVM: um, no idea. As I said, it's a wonderland full of ponies and rainbows
4. MoarVM
5. Rapid startup, compilation and runtime makes Perl6 development very, very pleasant
6. I've encountered some (with macros), maybe they are fixed already. There are no other bugs that I've encountered that don't exist on other VMs too
7. MoarVM ftw