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:07 reportable6 left
timo we have caller-side decont, so that combined with inlining could fill that role, right? 00:34
of course the caller-side decont doesn't always apply 00:35
jnthnwrthngtn vrurg: Can you be more specific? Generally the approach to decont is to guard on the type and then, if it's a container, to read the value out of it 00:48
If it's a Proxy it's trickier, but there's already a solution for that used in both multi dispatch and native calls
vrurg jnthnwrthngtn: say, dispatcher-guard-type on a tracked argument considers Scalar, not container's value type. 00:49
I'm close to finishing smartmatch dispatcher. And has realized today that most of it worked rather by accident. 00:50
So, to get things fixed I had to extend nqp::dispatch call from using, roughly, ($lhs, $rhs) to (nqp::decont($lhs), $lhs, nqp::decont($rhs), $rhs). 00:51
timo: BTW, for Code it is specced that topic is not deconted. 00:54
timo i don't exactly remember the details of when we do it 01:00
it might have to do with logging some things in the caller instead of the current frame 01:01
vrurg timo: aren't you currently talking about passing arguments to nqp ops from Raku code? Because otherwise we always deal with objects as they are. 01:07
timo i'm refering to run time optimization with speculation and such 01:08
01:09 reportable6 joined
vrurg Ah, sorry. That side I'm not familiar with. And my case is a QAST-generated call to dispatch where its arguments could be containerized and that's exactly how they land in dispatcher's code. 01:11
02:15 unicodable6 left, benchable6 left, committable6 left, releasable6 left, greppable6 left, reportable6 left, sourceable6 left, coverable6 left, evalable6 left, nativecallable6 left, bloatable6 left, bisectable6 left, quotable6 left, tellable6 left, statisfiable6 left, notable6 left, squashable6 left, shareable6 left 02:16 tellable6 joined, unicodable6 joined, benchable6 joined 02:17 reportable6 joined 02:18 squashable6 joined, statisfiable6 joined, bisectable6 joined, releasable6 joined 03:16 sourceable6 joined 03:17 greppable6 joined, bloatable6 joined 03:18 notable6 joined 04:15 evalable6 joined 04:16 shareable6 joined 04:18 coverable6 joined 05:16 nativecallable6 joined 06:08 reportable6 left 06:11 reportable6 joined 06:18 committable6 joined 06:35 linkable6 joined 07:06 squashable6 left 07:09 squashable6 joined 07:16 quotable6 joined 08:17 squashable6 left 08:19 squashable6 joined 08:20 squashable6 left
Geth MoarVM/fix_unsigned_for_merge: 7 commits pushed by (Stefan Seifert)++ 08:37
MoarVM: niner++ created pull request #1647:
Fix unsigned for merge		 08:40
09:31 squashable6 joined 12:07 reportable6 left 14:08 reportable6 joined 14:39 nebuchad` left
dogbert17 there's a bug lurking about, it shows up when running spectest 15:01
it's a SEGV an it looks like this: gist.github.com/dogbert17/6b316ea9...a08197e87f 15:03
have seen it several times
unfortunately the stack trace, which always looks the same, is a bit vague on details 15:09
nine You sure that's from a spectest? 15:22
#2 0x00007f752a451513 in dcCall_x64_sysv () from //home/dogbert/repos/rakudo/nqp/MoarVM/../../install/lib/libmoar.so 15:23
That's NativeCall. Which makes me think, that's just the one test that actually intentionally triggers a segv
jnthnwrthngtn vrurg: Passing in pre-decont'd things is a typical strategy, as is doing decont of Scalar containers using the attribute reading things in the dispatcher, and also the resume trick for dealing with Proxy. It depends on the situation. 15:31
vrurg: It's very deliberate that there's no "decont" knowledge directly in the dispatcher; it's too complex (can result in calls, etc.)
Also it's possible some day the `decont` op and the whole container spec stuff disappears from MoarVM and is done via dispatch also. 15:32
dogbert17 /spec/S32-hash/keys_values.t ..................................... ok 15:42
t/spec/S32-io/lock.t .............................................. Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 12/30 subtests
t/spec/S32-hash/kv.t .............................................. ok
nine: ^^^
I was running 'MVM_JIT_DISABLE=1 make spectest' 15:43
nine dogbert17: then you got the wrong core dump 15:49
dogbert17 the time match, so what could it be from then? 15:53
I'll give it another shot and git rid of t/spec/S29-os/system.rakudo.moar which only causes trouble 15:55
moon-child git: 'rid' is not a git command. See 'git --help'. 15:57
dogbert17 :) should have been 'get rid of' 15:58
17:46 Kaiepi left 18:01 Kaiepi joined 18:07 reportable6 left 19:07 evalable6 left, linkable6 left 19:09 evalable6 joined 19:10 linkable6 joined 19:15 discord-raku-bot left, discord-raku-bot joined 19:20 discord-raku-bot left, discord-raku-bot joined 19:21 Kaiepi left 19:22 Kaiepi joined 19:52 discord-raku-bot left, discord-raku-bot joined 19:56 discord-raku-bot left 19:57 discord-raku-bot joined 20:18 discord-raku-bot left, discord-raku-bot joined 20:22 gfldex left, gfldex joined 20:23 discord-raku-bot left, discord-raku-bot joined
japhb gist.github.com/japhb/efb7da856b06...2b57f10864 # Weird ll-exception "unreachable unbox 1" trying to build Cairo module on Rakudo HEAD 20:23
lizmat opined that it might actually be happening down at the MoarVM layer 20:24
lizmat feels like a dispatch issue 20:25
MasterDuke github.com/MoarVM/MoarVM/blob/mast...rgs.c#L380 20:26
nine uint issue 20:39
Would be interesting to know whether its still there on rakudo's fix_unsigned_for_merge branch 20:40
Err...not just rakudo's. Needs similar named branches on nqp and MoarVM 20:42
japhb nine: My build script isn't currently able to do that, meaning independently forcing branches at all layers. (It can easily handle forcing a commit, tag, or branch of *Rakudo*, but then it trusts that NQP and MoarVM will have matching revisions.) 20:45
MasterDuke can't you do `--gen-nqp=branch --gen-moar=branch`? 20:46
japhb MasterDuke: I'll look at plumbing that through the scripts, I just haven't needed it in the past. :-) 20:48
japhb continues multitasking
21:10 reportable6 joined
vrurg If somebody could possibly have a look at github.com/rakudo/rakudo/pull/4721 and possibly tell me what causes the slow down, compared to 2021.10. I suspect broken inlining, but ensuring this would require me diving into moar statistics, which I was never doing before. 21:13
I would do it myself, but need to prioritize FOSDEM talk for now. :( 21:14
MasterDuke you mean compared to 2021.12? 21:15
vrurg I haven't build it on the test server. So, 2021.10 it was. 21:16
*built
But 2021.12 would have the same outcome. Most likely, the master too because the example I provided is not statically optimizable case. 21:17
21:19 discord-raku-bot left, discord-raku-bot joined 21:22 gfldex left, gfldex joined
MasterDuke for me, master takes ~0.57s for 1m iterations, your branch takes ~0.25s. if you switch the example around so it's `t() ~~ v()` instead of `v() ~~ t()`, then master is ~0.13s and your branch is ~0.25s 21:26
vrurg MasterDuke: do you do time on the script? Because I measure the loop with `my $s = now; <loop>; my $total = now - $s;` 21:27
MasterDuke m: sub t { Stringy }; sub v { "AAAA" }; my $a; $a = t() ~~ v() for ^1_000_000; say now - INIT now; say $a;
camelia 0.041747204
False
vrurg MasterDuke: then it's inlining for sure. Because my loop is `for ^COUNT { $a = v() ~~ t() }` 21:30
BTW, I don't even use the assignment. The loop body consists of ~~ only. 21:31
MasterDuke our optimizer isn't usually smart enough to remove unused loop bodies, but i do that to defeat it if it were to try and do that 21:33
vrurg Hm, this is confusing. The exact version you used is still .2 for the new-disp version vs. 0.03 for 2021.10 21:34
I'd try to rebase on the latest master and see if there is any change.
MasterDuke there were a lot of changes between .10 and .12 21:36
vrurg Nah, rebasing changes little. 0.18 on the branch. 21:39
Same consistent 6x slow down. No idea how it happens to be faster on your side. 21:40
21:41 Kaiepi left 21:42 Kaiepi joined 21:46 sena_kun left, sena_kun joined
vrurg I've spotted a mistake in the bytecode causing RHS to be called twice. That's certainly a problem. 21:48
MasterDuke in your changes, or something generically wrong that can be improved? 21:49
vrurg I'm looking into it. It must not happen (we always say it! :) 21:53
Don't know what I saw, but everything is ok, single call per SM. 21:58
japhb Updating Configure --gen-* lines: Trivial. Realizing that the branch refs don't exist because you cloned from a non-bare repo: Priceless.
MasterDuke well, you'd also have to add vrurg's repo as a remote 21:59
vrurg Ok, I see where the problem is. It is faster, but faster comparing to the master. It is compensating for the cost of correct handling of Junctions on smartmatch LHS. 22:09
japhb nine, MasterDuke: Added errors from a build from the branches to gist.github.com/japhb/efb7da856b06...2b57f10864 -- it still fails on that test file, but now with different errors.
lizmat: ^^
22:13 discord-raku-bot left, discord-raku-bot joined 22:17 discord-raku-bot left 22:18 discord-raku-bot joined
vrurg MasterDuke: BTW, the idea of running spectests on CI has a big weak point. If a PR is accompanied with roast PR, it may fail testing. 22:22
ugexe many times you set up the ci system to use the same branch name in other repositories (using main/master if it doesnt exist) 22:34
vrurg That's what I always do. 22:38

Powered by Cro and the Raku® Programming Language.

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

Thank you!