April report of the Raku Development Grant of Jonathan Worthington
Wed, 13-May-2020 by
Matthias Bloch
edit post
Jonathan writes:
April was a time for thinking, reflecting, and designing. The starting gun
for this was [fired in a post I wrote at the end of March](https://github.com/Raku/problem-solving/issues/170#issuecomment-606783081),
in which I reflected on the mechanisms that we've grown over the years
to make various constructs decently fast. The trigger for this was an
inability to improve the semantics of deferal (constructs like callsame)
without incurring a significant performance penalty - or at least, not
without having to make changes all the way down to the JIT. Even before
that, the difference between a `callsame` - the good way to defer to a parent class - and hard-coding the name of the parent class to go to was still a factor of around 50. (This number is significantly magnified by
the fact that any benchmark that tries to measure dispatch costs will,
in the case that we can inline the whole call graph, boil down to
benchmarking an empty loop, which is capable of making a loop doing any work
at all look bad!)
By the end of the April, I had a good amount of design work done on a
way forward, taking on a wide range of performance challenges. The
improvements on offer include:
* Unifying multi-dispatch caches, method dispatch, specializer plugins,
and more under a single mechanism. MoarVM likely ends up with less code
under this new design, in a range of areas.
* Modeling continued dispatches (for example, deferring to the parent
method or next most general multi-candidate) in the runtime itself, so
we'll be able to have a shot at inlining them.
* Eliminating the current memory-hungry pre-computed method caches, which
will also reduce the size of bytecode files. This should also fix some
issues around `augment`.
* Representing calls more compactly in the bytecode, and making them faster
to interpret (which would mean better throughput while we reach the point
that we have specialized or JIT-compiled versions available).
* Lifting limitations on optimization when a call is made with arguments
flattened.
* Potentially making closures rather more lightweight in memory.
[This document](https://gist.github.com/jnthn/e81634dec57acdea87fcb2b92c722959),
regularly updated with more details as I work on the implementation
during May - has the details. The hours I've put down here are those I
spent working on writing down the design; quite a few more were spent
pondering it. :-) I did get around to a couple of other things too, which
are listed below.
```
15:02 Work on new dispatch design, as described above.
2:11 Elimiante the Rakudo Scalar container descriptor, by moving the
logic - slightly generalized - into MoarVM. This helps towards
eliminating the Rakudo C extension library (which gets in the
way of various bundling things we want to do), is a bit more
robust, and will make it easier to optimize container access in
guard checking.
0:55 Provide much more useful information when native callbacks have
unhandled exceptions, rather than a rather terse panic message.
0:18 Assorted code review, merging.
Total reported time in this report: 18:26
Remaining approved hours on current grant period: 126:21
```
Comments (0)