Afaict, Rakudo is doing compile time resolution of the dispatch target for almost all calls to multisubs found in existing code. Aiui, if the leading candidates for a dispatch only use static nominal typing (specifying types like int, Int, Str, a class, role, etc. for their parameters) then resolution of which to finally pick is done at compile-time.
(Operators are multisubs so it's a good job that their dispatch target is being resolved at compile time or current Rakudo would be even slower!)
The code I wrote led to run-time resolution because A) Rakudo is currently converting a literal as a parameter (eg the 1 in `multi sub c (1) {}`) in to a 'where' constraint (`multi sub c ($ where 1) {}`) and B) there's no static analysis in place to reduce this simple 'where' constraint to a finite set of values (which is what would enable compile-time resolution despite use of a `where` constraint).
If Rakudo treated a literal parameter as a singleton value (i.e.not doing the shortcut A), or did basic analysis of simple `where` constraints to extract finite sets of values when possible (i.e. fixing B), then use of literals in a leading multisub candidate would no longer disable compile-time resolution.
Here's a hack workaround just to demonstrate that this can actually work in principle:
my $t; sub a { }; sub b { }; enum A <0>; enum B <1>; multi sub c (A) { }; multi sub c (B) { }; for ^7 { my $iterations = 10 ** $_; say $iterations ~ " calls"; $t = now; for ^$iterations { $_ %% 2 ?? a() !! b() }; say "regular: {now - $t}"; $t = now; for ^$iterations { c($_ %% 2 ?? A !! B) }; say "multi: {now - $t}"; }
This yields:
1 calls regular: 0.00633665 multi: 0.0044097 .... 1000000 calls regular: 5.3146894 multi: 5.2373117
So, using this enum trick, the times for these multisubs have basically caught up with the times for the plain subs. Resolution is compile-time with enums because Rakudo treats them as a finite set of values (as it should, because that's exactly what they are) and that theoretically enables (and in this case Rakudo actually implements) compile-time resolution.
Some relevant excerpts from the relevant design doc include:
The set of constraints for a parameter creates a subset type that implies some set of allowed values for the parameter. The set of allowed values may or may not be determinable at compile time. When the set of allowed values is determinable at compile time, we call it a static subtype.
... Note that all values such as 0 or "foo" are considered singleton static subtypes. ...
As a first approximation for 6.0.0, subsets of enums are static, and other subsets are dynamic. We may refine this in subsequent versions of Perl.
Of course, this still leaves the gulf (an order of magnitude? two?) between the basic sub call performance of Rakudo and of perl.
Aiui there are tons of bog standard optimization techniques (speed and RAM usage) that still haven't yet been applied to Rakudo, NQP, and MoarVM. Aiui more of these optimizations are supposed to arrive this year but most will come in later years.
I plan to update this thread if I find out any useful info about whether or not Rakudo sub calls might reasonably be expected to one day (year) eventually catch up with (maybe even overtake?) perl's performance.
»ö« . o O ( "the celebrity tell-all of the Perl-6 cult?" )
In reply to Re^7: rough approximation to pattern matching using local (Multi Subs)
by raiph
in thread rough approximation to pattern matching using local
by gregory-nisbet
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |