
Brief History of JIT in MoarVM for Perl 6 - Ultimatt
http://brrt-to-the-future.blogspot.com/2018/07/perl-6-on-moarvm-has-had-jit-for-few.html
======
3rdAccount
I'm always impressed with the size of the problem that the Perl6 core team is
trying to solve relative to the number of volunteers and funding.

It is a really nice language based off of all the tutorials and presentations
I've watched. It just needs some better performance before I'll really start
using it and I think there are many in the community that are in the same
boat. It's a pity, because it's a chicken or the egg kind of problem. I would
try to help, but when it comes to computer science I am a consumer and not a
producer (I have my own large projects in my domain :)).

~~~
tyil
> It is a really nice language based off of all the tutorials and
> presentations I've watched. It just needs some better performance before
> I'll really start using it

I'm also very impressed in how the language is turning out. It's a pleasure to
write and read. I know most people really don't like Unicode operators, but I
find them to be very useful. They're short and concise, and allow those
writing mathematical equations to stick to their regular symbols. And for
those that don't know how to do Unicode on their OS/editor, there's ASCII
equivalents.

Performance-wise, it seems to be fast enough for all my personal projects, and
it's getting faster every release. Is there a certain piece of code that you
want to have running within a certain amount of time? That would allow you
(and Perl 6 devs) to have a goal to look at, and work towards.

~~~
3rdAccount
Running grammars past very large datasets. You hear enough people talk about
the performance and you decide to stay away a bit until things improve. I also
have some numeric code and that is generally probably not a great P6 fit (more
of a Python + Numpy thing).

As a general scripting language, P6 looks nice as a lot of features such as
concurrency that are aren't super straightforward (Ex: python) seem to be dead
simple in P6.

~~~
b2gills
Perl 6 was designed in part to allow PDL (Perl Data Language) type features to
be added easily.

In fact some things that you would do in PDL have already been added, they
just currently aren't as fast as they could be.

    
    
        (1,2,3; 4,5,6; 7,8,9) »**» 2
        (1,4,9; 16,25,36; 49,64,81)
    

The above is specifically allowed to do all of the operations in parallel, but
doesn't currently. (Perhaps even on a GPU)

------
aidenn0
Why did I think the Perl 6 VM was called parrot?

~~~
Ultimatt
There is an intermediate language the Rakudo compiler is implemented in called
NQP. That split from the Parrot project to support several VMs as the stuff
emitted as the "compiled" code. For a while Parrot and JVM were supported
simultaneously. With the addition of MoarVM the project moved away from
supporting Parrot. There are other targets in development including JavaScript
and most recently Truffle/GraalVM
[https://github.com/perl6/nqp/commits/truffle](https://github.com/perl6/nqp/commits/truffle)
Essentially a _lot_ happens within the Perl 6 project at a pace that's kind of
surprising if you keep an eye on it.

~~~
aidenn0
Thanks for the summary!

------
totalperspectiv
I appreciate the time taken to fill in the history!

------
sunseb
Is Perl 6 fast now?

~~~
jdoege
It really depends. The question really should be, "Is Perl 6 fast enough?" For
my purposes, the answer is almost always yes. I can imagine some applications
where the answer would be no, but then I would probably be looking at C/C++
for a solution, anyway. Language bench-racing has really begun to look
counter-productive to me.

~~~
b2gills
Someone once posted code that they had written in both Perl 6 and C/C++. The
Perl 6 code was shorter, arguably easier to understand, and they said it was
also faster for their data.

My guess would be that the strings had to be copied more often in the C/C++
code.

