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.
00:08 reportable6 left 00:10 reportable6 joined 00:33 linkable6 left 00:35 linkable6 joined 01:28 Merfont left 03:55 unicodable6 left, squashable6 left, nativecallable6 left, committable6 left, statisfiable6 left, releasable6 left, coverable6 left, linkable6 left, evalable6 left, benchable6 left, notable6 left, reportable6 left, quotable6 left, greppable6 left, sourceable6 left, bloatable6 left, shareable6 left, tellable6 left, bisectable6 left 03:56 quotable6 joined, releasable6 joined, squashable6 joined, unicodable6 joined, linkable6 joined, statisfiable6 joined 03:57 sourceable6 joined, benchable6 joined, committable6 joined 03:58 shareable6 joined, tellable6 joined, bisectable6 joined 04:56 greppable6 joined, coverable6 joined, notable6 joined 05:56 linkable6 left 05:57 evalable6 joined, nativecallable6 joined 05:58 linkable6 joined
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
07:11 reportable6 joined
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.
08:57 bloatable6 joined
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
10:43 Merfont joined 11:24 Altai-man joined 12:08 TheAthlete joined, reportable6 left
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
13:58 discord-raku-bot left, discord-raku-bot joined
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
16:39 TheAthlete left 16:49 sena_kun_ joined, Altai-man left 17:09 reportable6 joined 17:36 sena_kun_ left 18:07 reportable6 left 19:10 reportable6 joined 19:34 squashable6 left 19:36 squashable6 joined 19:56 discord-raku-bot left, discord-raku-bot joined 20:10 MasterDuke left
vrurg jnthnwrthngtn: BTW, what would be the best way to find out if a recursive delegation took place? 20:12
20:39 MasterDuke joined
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++
21:59 discord-raku-bot left, discord-raku-bot joined