4 ms·

Perl6 started long before PyPy (2000 vs ~2007).

by bkeroack 12y ago

scott_karana 12y ago
And yet, work began on MoarVM only in 2012. http://en.wikipedia.org/wiki/MoarVM http://en.wikipedia.org/wiki/MoarVM
- simula67 12y ago
  I think MOAR was designed specifically to run NQP efficiently. NQP is a subset of Perl 6 which the Perl 6 compiler is written in. That compiler takes a program written in Perl 6 and converts it into NQP. That NQP program is then compiled to different targets such as JVM, Parrot etc. This is my understanding, of course.
  - sitkack 12y ago
    Sounds like someone needs to write an NQP JIT in rpython.
    - Solarsail 12y ago
      They would have their work cut out for them, that I can see. They could reuse the .moarvm bytecode and file format, the NQP compiler and Moar backend [0]. I think many of the test cases are even common between the three backends... So all that's left to re-implement is a bytecode interpreter, IO facilities and FFI. That is, if my understanding of MoarVM is accurate. [0] (https://github.com/perl6/nqp/tree/master/src/vm https://github.com/perl6/nqp/tree/master/src/vm)
  - rurban 12y ago
    I don't want to hijack a pypy thread with perl stuff, but this needs to be corrected: > I think MOAR was designed specifically to run NQP efficiently. yes > NQP is a subset of Perl 6 which the Perl 6 compiler is written in. yes > That compiler takes a program written in Perl 6 and converts it into NQP. No. moar is a vm backend for nqp, with a traditional bytecode interpreter, a jit, gc, ffi, and binary format. >That NQP program is then compiled to different targets such as JVM, Parrot etc. This is my understanding, of course. No. Of the current three perl6 backend moar, parrot and jvm is the fastest, but has problems with its traditional threading model. It does not scale linearily up the number of physical cores. It needs locks on all data structures, but this is still better than with perl5 or pypy. parrot does scale linearily, has locks only in the scheduler, but needs compiler support to create writer functions, only owner can write, access through automatically created proxies. The jvm threading model is also faster and well known, but has this huge startup overhead. perl5 has to clone all active data on thread init and creates writer hooks to copy updates back to the owner. this is a huge startup overhead, similar to the jvm. Overall, would you expect any c/perl compiler dev to switch over to rpython to back your perl6 vm? Writing a jit for a good vm was the matter of a summer, and writing the compiler optimizations needs to be done in the high-level language of choice to be more efficient and maintainable. You should better look over to rperl to compare it to rpython. This is the similar approach. A fast restricted optimizable language subset, which compiles do typed C++, with fallbacks on unoptimizable types to the slow perl5 backend. No need for a jit with its compilation and memory overhead. A jit only makes sense for dynamic profile-guided optimizations, as in pypy or v8. Even if the simple static jit's as in p2 or luajit without much compiler optimizations still run circles around those huge battleships in the jvm, clr, v8, pypy or moar. optimized data structures still are leading the game, not optimizing compilers.
    - simula67 12y ago
      rurban, I just want to point out that I was not calling for an rpython target for nqp nor was I claiming nqp is the rpython of the perl world. Not really sure what you are correcting. >No. moar is a vm backend for nqp, with a traditional bytecode interpreter, a jit, gc, ffi, and binary format. But surely NQP is a "language" and Moar is a vm ?
deleted 12y ago
[deleted]
maxerickson 12y ago
For the question, the start date of MoarVM is more interesting than the start date of Perl 6. It's also not quite fair to start Perl 6 at announcement and PyPy at their first release (they were organized enough in 2004 to be applying for EU funds).
- kbenson 12y ago
  No, not really, as it ignores all the specifics of the situation which matter. The current leading implementation of Perl 6 is Rakudo, which is implemented in NQP (itself a subset of Perl 6 that's meant to be easier to implement and optimize), which is comparable in some ways to rpython. At the point you already have an intermediate language, a lot of the benefits of using PyPy and being able to write your language in a higher level language aren't as much of a gain. Additionally, using PyPy would lock the implementation into whatever current limitations PyPy has (threads?). MoarVM is not the back-end, it's one back-end, and one meant to optimize specifically for NQP's needs. I imagine at some point a PyPy targeted Perl 6 will appear. It may or may not be based on the Rakudo implementation as a target for NQP (jnthn was able to get initial JVM support for NQP completed in a summer), or another implementation that targets PyPy through rperl directly. It would be really interesting to see what Perl 6's automatic opportunistic auto-threading of list operations and PyPy's STM work could do together.
  - maxerickson 12y ago
    That's a whole different (perfectly reasonable) line of reasoning that focuses on the needs of Perl 6 as an explanation. The comment I replied to frames it such that PyPy wasn't an option for MoarVM because it didn't exist when things got started.

Perl6 started long before PyPy (2000 vs ~2007).

scott_karana 12y ago

And yet, work began on MoarVM only in 2012. http://en.wikipedia.org/wiki/MoarVM http://en.wikipedia.org/wiki/MoarVM

simula67 12y ago
I think MOAR was designed specifically to run NQP efficiently. NQP is a subset of Perl 6 which the Perl 6 compiler is written in. That compiler takes a program written in Perl 6 and converts it into NQP. That NQP program is then compiled to different targets such as JVM, Parrot etc. This is my understanding, of course.
- sitkack 12y ago
  Sounds like someone needs to write an NQP JIT in rpython.
  - Solarsail 12y ago
    They would have their work cut out for them, that I can see. They could reuse the .moarvm bytecode and file format, the NQP compiler and Moar backend [0]. I think many of the test cases are even common between the three backends... So all that's left to re-implement is a bytecode interpreter, IO facilities and FFI. That is, if my understanding of MoarVM is accurate. [0] (https://github.com/perl6/nqp/tree/master/src/vm https://github.com/perl6/nqp/tree/master/src/vm)
- rurban 12y ago
  I don't want to hijack a pypy thread with perl stuff, but this needs to be corrected: > I think MOAR was designed specifically to run NQP efficiently. yes > NQP is a subset of Perl 6 which the Perl 6 compiler is written in. yes > That compiler takes a program written in Perl 6 and converts it into NQP. No. moar is a vm backend for nqp, with a traditional bytecode interpreter, a jit, gc, ffi, and binary format. >That NQP program is then compiled to different targets such as JVM, Parrot etc. This is my understanding, of course. No. Of the current three perl6 backend moar, parrot and jvm is the fastest, but has problems with its traditional threading model. It does not scale linearily up the number of physical cores. It needs locks on all data structures, but this is still better than with perl5 or pypy. parrot does scale linearily, has locks only in the scheduler, but needs compiler support to create writer functions, only owner can write, access through automatically created proxies. The jvm threading model is also faster and well known, but has this huge startup overhead. perl5 has to clone all active data on thread init and creates writer hooks to copy updates back to the owner. this is a huge startup overhead, similar to the jvm. Overall, would you expect any c/perl compiler dev to switch over to rpython to back your perl6 vm? Writing a jit for a good vm was the matter of a summer, and writing the compiler optimizations needs to be done in the high-level language of choice to be more efficient and maintainable. You should better look over to rperl to compare it to rpython. This is the similar approach. A fast restricted optimizable language subset, which compiles do typed C++, with fallbacks on unoptimizable types to the slow perl5 backend. No need for a jit with its compilation and memory overhead. A jit only makes sense for dynamic profile-guided optimizations, as in pypy or v8. Even if the simple static jit's as in p2 or luajit without much compiler optimizations still run circles around those huge battleships in the jvm, clr, v8, pypy or moar. optimized data structures still are leading the game, not optimizing compilers.
  - simula67 12y ago
    rurban, I just want to point out that I was not calling for an rpython target for nqp nor was I claiming nqp is the rpython of the perl world. Not really sure what you are correcting. >No. moar is a vm backend for nqp, with a traditional bytecode interpreter, a jit, gc, ffi, and binary format. But surely NQP is a "language" and Moar is a vm ?

deleted 12y ago

[deleted]

maxerickson 12y ago

For the question, the start date of MoarVM is more interesting than the start date of Perl 6. It's also not quite fair to start Perl 6 at announcement and PyPy at their first release (they were organized enough in 2004 to be applying for EU funds).

kbenson 12y ago
No, not really, as it ignores all the specifics of the situation which matter. The current leading implementation of Perl 6 is Rakudo, which is implemented in NQP (itself a subset of Perl 6 that's meant to be easier to implement and optimize), which is comparable in some ways to rpython. At the point you already have an intermediate language, a lot of the benefits of using PyPy and being able to write your language in a higher level language aren't as much of a gain. Additionally, using PyPy would lock the implementation into whatever current limitations PyPy has (threads?). MoarVM is not the back-end, it's one back-end, and one meant to optimize specifically for NQP's needs. I imagine at some point a PyPy targeted Perl 6 will appear. It may or may not be based on the Rakudo implementation as a target for NQP (jnthn was able to get initial JVM support for NQP completed in a summer), or another implementation that targets PyPy through rperl directly. It would be really interesting to see what Perl 6's automatic opportunistic auto-threading of list operations and PyPy's STM work could do together.
- maxerickson 12y ago
  That's a whole different (perfectly reasonable) line of reasoning that focuses on the needs of Perl 6 as an explanation. The comment I replied to frames it such that PyPy wasn't an option for MoarVM because it didn't exist when things got started.