|
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
|
|||