Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
nine Now that vrurg++ put it this way: what if we have a callsite where we call an unwrapped routine, dispatch accordingly but between this first and the next call at this callsite the routine actually gets wrapped? How do we detect that? 06:10
The answer is: the only way a routine object can get a WRAPPERS method is by getting mixed into. But mixing into an object changes the object's type and we have a guard on the callee's type. So that's how we end up back in the dispatcher which now deals with the wrappers. 06:12
Nicholas *, * good 07:20
Geth MoarVM: 4a3b98d546 | (Stefan Seifert)++ | src/spesh/optimize.c
Teach optimize_decont about UINT64 box type
 07:27
MoarVM: ed3cdd382f | (Stefan Seifert)++ | src/spesh/facts.c
Fix spesh turning decont of a UIntLexRef into a decont_i

We wrongly assumed int_lex_ref as the type of the result of a getlex_u* op when gathering facts. This led us to making optimization decisions based on the wrong type.
lizmat oooh..., that looks like an interesting fix performance wise! 09:18
nine I think there are still several optimizations that need to cover uint now 09:41
Geth MoarVM: scovit++ created pull request #1666:
Make rakudo available on the GNU Hurd		 09:47
lizmat m: sub a(int $a, int $b) { }; a 42, 666 for ^10000000; say now - ENTER now # something I just noticed now 10:06
camelia 0.584606328
lizmat m: sub a(Int:D $a, int $b) { }; a 42, 666 for ^10000000; say now - ENTER now # Int:D int *much* faster
camelia 0.069507487
lizmat a factor of 8 ?
timo www.ui.perfetto.dev/ may be interesting at some point 10:14
lizmat: i'm willing to bet it's about boxing that we're not noticing is unnecessary 10:18
lizmat actually, the int int case does not inline: 10:22
a BB(1, 18 bytes) -> BB(2):
target has a :noinline instruction - ins: paramnamesused
timo huh, paramnamesused, that suggests we're not arg-speshing it 10:23
lizmat is just reporting :-) 10:24
m: 'sub a(int @a, int $b) { }; a (my int @ = 42), 666 for ^100000 # also does not inline 10:25
camelia ===SORRY!=== Error while compiling <tmp>
Unable to parse expression in single quotes; couldn't find final "'" (corresponding starter was at line 1)
at <tmp>:1
------> 3666 for ^100000 # also does not inline⏏<EOL>
expecting…
lizmat m: sub a(int @a, int $b) { }; a (my int @ = 42), 666 for ^100000 # also does not inline
camelia ( no output )
lizmat a BB(1, 46 bytes) -> BB(2):
target has a :noinline instruction - ins: sp_assertparamcheck
is that something that should be handled with new-disp dispatching ? 10:26
timo hm, good question 10:35
jnthnwrthngtn No, that's pretty orthogonal to dispatching, it's about optimization of signature checking. If that op is still around, it means we didn't prove that, in the given specialization, the signature will always bind 12:43
timo and failing the bind at that point isn't a point where we could do a resumption into an error handler or something? 12:46
i wonder if we can perhaps have an sp_sp_assertparamcheck that takes info about the original callable and signature and all the arguments as parameters or something
so that inlining would be safe since all necessary info is kept available
so that inlining would be safe since all necessary info is kept available 12:47
sp_assertsp_aramcheck
nine I'm surprised about int int not param speshing. E.g. I've tested int Int and that speshes (while int Int:D doesn't) 14:18
vrurg nine: Then something didn't work as expected. I have managed to get wrapped `proto` working by the proposed method: added the attribute to Routine then added a guarding on it in raku-meth-deferral resumption. Right after the guard on $track_method type. 14:19
And there is one more thing. Unless I'm misinterpreted the dumped programs, but it looks like unwrapping results in returning to the default multi-method dispatching path. 14:20
nine Oh, but I've tested something like sub foo(int $a, Int $b) { }; my int $a = 1; foo($a, 1) for ^2000000
sub foo(int $a, int $b) { my $x = $a; }; foo(2, 1) for ^20000000; speshes just fine? 14:23
vrurg nine: BTW, with regard to LibXML, there is missing 'unsigned' in error message of native_ref_store_u. And there is no difference in store and fetch messages, making it harder to track down. I can make a PR, but not sure when will have time for it.
nine As does 'sub foo(int $a, Int $b). It's really 'sub foo(int $a, Int:D $b) which tanks performance
vrurg: feel free :) 14:24
vrurg Unfudged S06-advanced/dispatching.t currently fails with 'Already set resume init args for this dispatcher'. This is a case where a multi-dispatch candidate gets wrapped with another multi-dispatch. Looks like delegating back to a dispatcher which is already was called/delegated to is not possible. Do I understand it correctly that because delegations do not recurse this wrapping will never work? 14:48
jnthnwrthngtn vrurg: Correct, we don't support the same resumable dispatcher occurring recursively 15:57
vrurg jnthnwrthngtn: any plans for this? I mean, we're not prohibiting that behaviour of wrapping. 16:01
jnthnwrthngtn We could explicitly prohibit it with a decent error 16:04
We could also have a multi-wrapper dispatcher that forces us to run the proto and do a resumption to actually going to the multi candidate, to "split" the dispatch at that point 16:05
e.g. "you can do this but you'll not get the optimization that avoids running the proto"
vrurg The latter is ok, I think. It's a rare and extremely specific case. 16:20
jnthnwrthngtn Yeah, I don't feel much like making the dispatch mechanism more complex for this, if we have an acceptable "user-space" solution 16:32
vrurg jnthnwrthngtn: BTW, what would be the best way to find out if a recursive delegation took place? 20:12
Geth MoarVM/master: 6 commits pushed by (Daniel Green)++, MasterDuke17++ 21:09
MoarVM: d968da8927 | (Daniel Green)++ | src/jit/compile.c
Use correct sizes in format string
MoarVM: 58d0d7567c | (Daniel Green)++ | src/strings/gb18030_codeindex.h
Remove impossible logic
MoarVM: 0b2bda31fc | MasterDuke17++ (committed using GitHub Web editor) | 2 files
Merge pull request #1664 from MasterDuke17/fix_more_things_found_by_lgtm.com
vrurg MasterDuke: would you, pls, merge github.com/MoarVM/MoarVM/pull/1665? It holds me back from updating moar. 21:27
Geth MoarVM: 72b313b2f2 | (Vadim Belman)++ | src/disp/program.c
Make it possible turn dispatcher debugger with compiler options

Sometimes it is better than editing the source.
MoarVM: 74bbbccabf | MasterDuke17++ (committed using GitHub Web editor) | src/disp/program.c
Merge pull request #1665 from vrurg/disp-debug-trigger
vrurg MasterDuke++

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!