4 ms·

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

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 ?

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 ?