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.
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
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
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
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
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
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
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
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: ^^
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!