The new MoarVM dispatch mechanism is here!

Thank you for the extensive comment. :)

The post is not very clear about what's the new mechanism here (it generalizes several runtime-dispatch mechanisms in the MoarVM bytecode; but how?).

Right. The article I posted is about the immediate impact of landing the new mechanism in the production version of the Rakudo compiler. In particular, immediate speedups. As an example, regarding this factorial code benchmark:

multi fac($n where $n <= 1) { 1 }
multi fac($n) { $n * fac($n - 1) }
for ^1_000_000 { fac(5) }

jnthn writes:

So there’s more to be had here also; in the meantime, I’m afraid you’ll just have to settle for a factor of ten speedup.

(The "So there's more to be had" refers to future optimization opportunities he discusses in the article, but the "factor of ten speedup" is one of the immediate impacts.)

The linked slides say more, but are written with MoarVM-specialists in mind.

Perhaps watching the video will help? I'd say I know relatively little about bytecodes in general and MoarVM in particular, but I found the video very illuminating. The early part of the presentation covers the motivation and challenges. The new mechanism is discussed after that preamble.

I'd say the slides are a mix of high level stuff and nitty gritty details that perhaps only make sense in the context of the spoken presentation. In the slide deck, the part of the presentation that focuses on the new mechanism starts at pages 47/48.

Here is what I understood, as someone unfamiliar with MoarVM:

Thanks!

the propose feature

To be clear it was proposed a couple years ago. What's just happened is that the initial work has recently been completed; it passes the 200K unit tests for the compiler; all the unit tests of all publicly shared modules are passing save for a handful that it's been agreed should not block the merge; and some performance regressions have been addressed (it's not all roses); and so it has now landed in the main branch of the Rakudo compiler that is due for a production release in a few weeks.

generalizes the idea of "inline cache" (in a bytecode instruction stream) from storing data (typically: the address of the method to call) to storing code in a small DSL (domain-specific language; not general opcodes).

From the presentation (see, for example, pages 47/48 of the slide deck), I understood it to be, quote, "just":

One* new instruction dispatch ... Exposed like other ops nqp::dispatch(...)

I interpreted that to mean it was "just" a judiciously designed single new bytecode op/instruction. So I'm surprised at your description of it as a DSL.

the small DSL contains the operations that are typically found in various forms of dispatch-y language features: fetching the type of an operand, guarding on that, adding or removing arguments from the call, etc.

Like I said, I didn't interpret it as a DSL. Things like fetching the type of an operand is just another, already existing, opcode. And I was thinking that the adding/removing arguments aspects were also already existing opcodes. But maybe I'm wrong about that and/or about the DSL notion. Perhaps someone more knowledgeable will read this comment and reply to clarify.

the VM is in charge of maintaining such "dispatch programs" in the inline caches: the cache starts empty, then the first run will put a dispatch program there, the VM may store several programs for polymorphic callsites, etc.

That's my understanding.

the dispatch programs can also be optimized by the JIT, just like usual opcodes

Right. Because the dispatch opcode is really just another opcode.

This is what I understood. It looks like a nice idea! It's a generalization of known mechanisms that can cover more language features, while simplifying the overall implementation.

Right. That's my understanding too.

I couldn't find a description of the dispatch DSL, what "dispatch commands" are available and what they do; linking to that would be useful

I think there are four "commands" built in:

• boot-value and boot-constant (overview at pages 50-53 in the slide deck)

• boot-code and boot-syscall (overview at pages 74-75 in slide deck)

Again, just reading the slides may not be of much use; consider watching the video corresponding to those slides.

In addition there are "Userspace dispatchers", (discussion starts at slide 77). These are perhaps the most important, though they ultimately always delegate to the four boot-* commands.

The way the interpreter-author is supposed to write those dispatch programs is not very nice to a non-expert, you are supposed to call nqp::dispatch with many strings argument that basically correspond to dispatch-language keywords, but may do wildly different things. I would rather see something that looks more closely like a shallow DSL.

That makes sense.

(That said, I doubt that'll happen unless someone other than jnthn decided to build such a DSL. He's just spent a couple years on this work, knows nqp well, knows there are a dozen others who are comfortable writing nqp code, and has a lot of other fish to fry.)

Anyhow, thanks again for reading the article and commenting, and I hope my reply has been helpful.