It has some native typed features that mean one can speed up numeric or raw byte/bit operations to be faster, sometimes a lot faster than, say, Perl 5, but it's generally a whole lot slower, 10x and even 100x slower wasn't uncommon a few months ago. Some users claim it's worth trying it to see how it works out for the sort of code a given user writes.
This release is about nailing down the language with a compiler that passes a test suite. Next comes a focus on improving what they have -- nailing bugs, speeding it up and expanding the test suite while making sure it continues to pass the test suite and keeps users' code running.
I'd expect some benchmarks to be published on #perl6 in the next few weeks.
Interesting, does poor performance hold true using JVM? I'd expect MoarVM to have some performance issues since its new.
Is the multi-vm approach anything more than a novelty or is this expected to be a feature, i.e. a common spec and intermediate layer with support for different backend VMs?
First of all, no one can yet run 6.c code on the JVM. Maybe the JVM backend will get there by Christmas 2016.
The JVM's JIT is pretty awesome once it gets well warmed up. MoarVM's JITing is much less impressive so far but it's early days.
The JVM will almost certainly always underperform relative to MoarVM in these two ways:
* Much poorer startup time (unless an evalserver "cheat" is used)
* Using much more RAM (I recall a report of something like 5x or so for typical code running on recent versions of the JVM backend compared with the MoarVM backend)
My understanding is that the multi VM approach is strategic for Perl 6, for the Rakudo Perl 6 compiler, and for the underlying NQP compiler toolchain.
