Hacker News new | comments | ask | show | jobs | submit login
Brief History of JIT in MoarVM for Perl 6 (brrt-to-the-future.blogspot.com)
83 points by Ultimatt 6 months ago | hide | past | web | favorite | 19 comments

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 :)).

> 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.

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.

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)

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

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 Essentially a lot happens within the Perl 6 project at a pace that's kind of surprising if you keep an eye on it.

Thanks for the summary!

Many years ago, it was. Parrot is a separate team, and was designed to be the "mother of all VMs" with Perl 6 as its sort of halo language implementation. It split off as the Perl 6 project matured and needed to own the vm/compiler.

What was it that Parrot couldn't do that Perl 6 needed?

We often have efforts to make one VM that can support everything and they have usually failed in the past. I wonder why it failed this time?

The history in short from my perspective:

* Parrot was intended as the runtime for Perl 6.

* Perl 6 was not ready to indicate what it needed when development started on Parrot

* Scope/Goal of Parrot was extended to other scripting languages

* Parrot started to become more and more unsuitable as the VM for Perl 6 once Perl 6 figured out what it needed

* Parrot failed to attract other clients for its VM

* The Great List Refactor in Perl 6 the year before its official release, forced a decision on whether to also refactor for the Parrot backend or not (on top of the refactoring needed for the JVM and MoarVM backend)

* The decision was no: but really, the GLR was the straw that broke the camel's back, so to say. Particularly, NFG support and async/event driven support were deemed to be impossible to implement with the state Parrot was in at the time.

* With no more clients for its VM, developers left the Parrot project

So is “nomen” now “omen?” Is the Parrot dead? (1) (2)

I can’t figure that out. On


It seems it maybe still moves?

1) https://en.wikipedia.org/wiki/Dead_Parrot_sketch

2) The name's origin is really the sketch see: https://web.archive.org/web/20040203055250/http://www.oreill... and https://en.wikipedia.org/wiki/Parrot_virtual_machine#cite_re... "The name Parrot came from an April Fool's joke which announced a hypothetical language, named Parrot, that would unify Python and Perl.[4][5]"

It used to have monthly releases.

The last release was from more than two years ago.

If it isn't dead yet, it certainly is feeling its age.

If someone were willing, they are more than welcome to start a fresh Parrot port of Rakudo.

I appreciate the time taken to fill in the history!

Is Perl 6 fast now?

Since H. Merijn Brandt started working on the Perl 6 version of Text::CSV, he has kept a log of how long a specific test (referred to as test-t) too to run.


Since then, Rakudo Perl 6 has become more than 100x as fast, at least for this test. And more than 250x as fast using a concurrent version of the test (which was as simple as putting a `.race` in the code).

This makes it still slower than the Perl 5 version, which uses XS (all parsing logic written in C). But the gap is closing with another round of optimizations to be merged later this week after an extensive refactor that took about 2 months. Of which you will most certainly see a report on https://6guts.wordpress.com , the blog of Jonathan Worthington.

Quoting the blog post this HN article is supposed to be about[1]:

PS: You might read this and be reasonably surprised that Rakudo Perl 6 is not, after all this, very fast yet. I have a - not entirely serious - explanation for that:

All problems in computer science can be solved with a layer of indirection. Many layers of indirection make programs slow. Perl 6 solves many computer science problems for you ;-)

In the future, we'll continue to solve those problems, just faster.

[1] http://brrt-to-the-future.blogspot.com/2018/07/perl-6-on-moa...

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.

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.

MoarVM has recently gotten the ability to write optimization plugins in higher level code. This should make it easier to create certain optimizations as they will have access to the syntax tree.

So it may be that the rate at which it gets faster has gotten faster.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact