[00:02] *** reportable6 left [00:25] *** Kaipi joined [00:25] *** Kaiepi left [02:06] *** frost joined [04:02] *** notable6 left [04:02] *** releasable6 left [04:02] *** bisectable6 left [04:02] *** sourceable6 left [04:02] *** evalable6 left [04:02] *** linkable6 left [04:02] *** shareable6 left [04:02] *** quotable6 left [04:02] *** benchable6 left [04:02] *** committable6 left [04:02] *** unicodable6 left [04:02] *** greppable6 left [04:02] *** tellable6 left [04:02] *** coverable6 left [04:02] *** nativecallable6 left [04:02] *** bloatable6 left [04:03] *** statisfiable6 left [04:03] *** releasable6 joined [04:03] *** bloatable6 joined [04:03] *** committable6 joined [04:04] *** statisfiable6 joined [04:04] *** notable6 joined [04:04] *** shareable6 joined [04:04] *** greppable6 joined [04:04] *** coverable6 joined [04:05] *** sourceable6 joined [04:05] *** benchable6 joined [04:05] *** evalable6 joined [04:06] *** nativecallable6 joined [04:39] *** squashable6 joined [05:10] *** lizmat left [05:10] *** Voldenet left [05:11] *** Voldenet joined [05:11] *** lizmat joined [05:13] *** camelia left [05:13] *** nine left [05:13] *** nine joined [05:25] *** bisectable6 joined [06:05] *** reportable6 joined [06:12] *** linkable6 joined [06:12] *** unicodable6 joined [07:10] *** tellable6 joined [07:25] good *able6, #moarvm [07:51] i spun up my win10 vm last night to track down the (hopefully final) windows bug in my gmp branch. but then i realized it was late on a sunday and i didn't really want to do debugging on windows. so i killed virtual mechanical dinosaurs instead [07:54] *** lizmat left [07:54] *** lizmat joined [07:57] *** patrickb joined [07:59] MasterDuke++ # being reasonable by keeping things -Ofun [08:25] MasterDuke: virtual mechanical dinosaurs? Ha! Same here :) [08:34] nine: also playing horizon zero dawn? or has the next one been released already? [08:36] *** brrt joined [08:37] \o [08:37] o/ [08:39] brrt: while you're here. is there a way to invert the result of a function call in the lego jit? it's easy in the template jit, but i don't know how to do it in src/jit/graph.c [08:41] MasterDuke: Yes, currently in my first New Game+ [08:42] ah, nice. this is my first time playing it (i've gotten years behind in my games) [08:44] Just noticed that http://moarvm.org/roadmap.html and http://moarvm.org/features.html are largely out of date. [08:46] http://moarvm.org/contributing.html still has freenode on it [08:47] MasterDuke: I thought there was a way but I don't recall [08:48] k. it's easy enough to add an argument to just flip the return value [08:48] there isn't, yet. [08:48] but, there is `MVMJitRvMode` which will allow you to add stuff [08:49] patrickb: I think it's possible to make PRs against https://github.com/MoarVM/moarvm.org/ [08:53] i meant it's easy in this case to add an argument to the function i'd be calling. but interesting, i hadn't thought about a new MVMJitRVMode... [08:53] Nicholas: I thought about creating a PR, but figured, that especially for the roadmap and features pages I don't have a broad and deep enough insight into the current state of things and where potential for improvement is / what the plans are to make a decent update. [08:54] makes sense. [08:54] that's what we use MVMJitRvMode for, also for dereference and stuff [08:54] I should add that I have no idea how things get from that repository to deployment and publication [10:07] *** brrt left [10:18] *** frost left [10:25] Any commits to the master branch will be automatically deployed in 10-15 minutes [10:25] (for moarvm.org, that is) [10:34] *** quotable6 joined [10:38] ¦ MoarVM: 2f5c21fb65 | (Nicholas Clark)++ | src/core/str_hash_table.c [10:38] ¦ MoarVM: Fix another bug in MVM_str_hash_fsck(). [10:38] ¦ MoarVM: [10:38] ¦ MoarVM: Calling `MVM_str_hash_entries` when just the control structure was allocated [10:38] ¦ MoarVM: (the empty hash optimisation) would trigger an assertion failure. [10:38] ¦ MoarVM: [10:38] ¦ MoarVM: We need to check `control->cur_items` and `control->max_items` explicitly. [10:38] ¦ MoarVM: It also makes sense to check for `control` being NULL and handling that case [10:38] ¦ MoarVM: (instead of segfaulting). [10:38] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2f5c21fb65 [10:58] *** brrt joined [11:32] *** brrt left [12:03] *** reportable6 left [12:04] *** reportable6 joined [13:10] *** Kaipi left [13:10] *** Kaiepi joined [13:27] and yet another Rakudo Weekly News hits the Net: https://rakudoweekly.blog/2021/07/26/2021-30-third-sat-in-summer/ [13:37] lizmat++ [13:37] lizmat: I guess "branche" is a typo [13:40] lizmat: dogbert17++ has helped a lot with new-disp as well by finding reproducible ways to provoke the segfaults I then fixed [13:41] jnthnwrthngtn: indeed, fixed :-) [13:42] added dogbert17++ [13:42] lizmat++ [13:44] Turns out that I left the commit where I was going to debug the SSA version splitting thing at home. No matter; support for `callwith`/`nextwith` also needs doing :) [13:52] jnthnwrthngtn, gods bless you. [14:01] hooray, I'm a celebrity :) [14:20] sometimes I get spurious test fails with the message 'No subtests run'. When I rerun the test everything is ok. [14:21] but this time I got a coredump [14:25] nine, timo: is it possible to extract anything of interest from this: https://gist.github.com/dogbert17/0825eaf6b8b4feb58b27650f8604eb65 [14:26] dogbert17: That'd imply spesh_cand is somehow bogus; no idea how [14:26] oh [14:26] It could be unlucky timing [14:27] it *feels* timing related [14:27] Hm, my first idea doesn't quite make sense [14:27] darn [14:28] I wondered if it was because we didn't initilize ->spesh_cand to NULL before doing the logging, so it'd be a bogus pointer when we walk the callstack [14:28] that's on new-disp? [14:28] But no, I can see the nulling right above it [14:28] MasterDuke: Must be, since MVM_frame_dispatch is in the stacktrace and that doesn't exist on master :) [14:29] heh. hard to argue with that logic [14:36] I guess I'll have to run with --no-optimize for a while hoping that the problem returns [14:43] m: say 1325 / 1349 [14:44] jnthnwrthngtn, rakudo-moar 74d7ff771: OUTPUT: «0.982209␤» [14:44] passing tests? [14:45] Yeah, +4 higher than the best number I've seen so far, but we're gradually losing more due to missing fixes from `master`, so I think the work I just did for `callwith` on methods got us 6 new fully passing test files [14:46] that's really cool. Are you considering a rebase? [14:47] Sometime later this week. [14:47] They're a little inconvenient for everyone working on the new-disp branches [14:47] so how many tests are left if we ignore master [14:50] Don't know exactly, but I think less than 20 [14:51] * jnthnwrthngtn gets more tea and then has a go at making callwith work with the wrap dispatcher [15:05] *** patrickb left [15:24] *** patrickb joined [16:04] Hurrah, now all but 1 of the wrap tests passes [16:05] The failing one being thanks to the wrong exception type when there's no resumable dispatch in scope. [16:09] jnthnwrthngtn: are is(true|false)_s going to become dispatchers? [16:11] No [16:11] There's nothing to dispatch [16:11] They work on a str register [16:12] And always do the same thing [16:12] <[Coke]> moarvm.org - don't think the source for this is in a repo... [16:12] <[Coke]> ... dammit, didn't review! :) [16:12] oh. right. timo mentioned that earlier. everyone forget i asked that question (again)... [16:13] [Coke]: has the tide in your coffee cup gone out? [16:13] <[Coke]> Nicholas: well, I didn't try to add the gatorade powder to the coffee today, so I guess I'm doing better. [16:14] :-) [16:14] * [Coke] afks to do some errands. [16:14] Quite a lot of new passing tests with wrap callwith fixed up, alas no new entirely passing test files to add to the tally. [16:22] [Coke], what's wrong with moarvm.org? [16:23] Altai-man: It was mentioned in backlog that it still mentions freednode [16:23] jnthnwrthngtn, ah, on the contributing page, alright. I thought I screwed something up with a release. [16:23] No :) [16:24] btw, no https is apparently a point of annoyance for it as well. :( [16:32] https://moarvm.org/ # works fine? [16:33] ah, you're right [16:42] ¦ MoarVM/new-disp: df38d6b7fa | (Jonathan Worthington)++ | 3 files [16:42] ¦ MoarVM/new-disp: Allow configurable "no resumption in scope" error [16:42] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/df38d6b7fa [17:23] m: say 1328 / 1349 [17:23] jnthnwrthngtn, rakudo-moar 74d7ff771: OUTPUT: «0.984433␤» [17:24] Home time o/ [17:27] maybe it's time for a blin run [17:31] *** brrt joined [17:38] this is backwards progress. i jitted is(true|false)_s and got my test runtime to increase from 0.37s to 0.43s [17:50] oops.... [17:53] anyone see anything terribly wrong about https://gist.github.com/MasterDuke17/8704274029932ab82023c2659d8d216f ? [17:54] my test case is `my int $a := 0; my $b; my int $s := nqp::time; my str $si := ~$s; while $a < 100_000_000 { if $si eq "" { $b := 3 } else { $b := 5 }; ++$a }; say(nqp::time - $s); say($b)` in nqp [17:58] nqp: my int $a := 0; my $b; my int $s := nqp::time; my str $si := ~$s; while $a < 10_000_000 { if $si eq "" { $b := 3 } else { $b := 5 }; ++$a }; say(nqp::time - $s); say($b) [17:58] oh, camelia is down [17:58] nine: ^^^ [18:00] but wow. that version above take ~0.37s locally. if the loop body is instead `$b := $s eq "" ?? 3 !! 5;` it takes ~5.8s [18:02] *** reportable6 left [18:05] *** reportable6 joined [18:05] each version only has 14 frames. but the if does no garbage collections and the ternary version does 1144 gcs. 100% of the extra time is spent in gc [18:18] So what's the ternary version allocating? [18:18] VMString [18:19] 100000004 of them vs 6 [18:23] Wait a minuge. In one it's $si eq "" in the other it's $s eq "" [18:23] they have different --target=optimize, but each version is essentially the same as their body. if, condition, bind, value, bind, value vs bind, if, condition value, value [18:24] doh [18:25] now ternary is only ~0.04s slower [18:26] ha [18:27] profiles look identical, except ternary is slower, but no obvious reason why [18:27] what's the margin of error? [18:28] don't know exactly. results are relatively consistent [18:29] fastest ternary was 0.410s, slowest if was 0.379 [18:29] over ~10 runs of each [18:32] same with MVM_SPESH_BLOCKING=1 [18:35] seems like the difference is probably still there with spesh disabled [18:43] *** camelia joined [18:43] m: say "glad to be back" [18:43] rakudo-moar 74d7ff771: OUTPUT: «glad to be back␤» [18:45] nqp: my int $a := 0; my $b; my int $s := nqp::time; my str $si := ~$s; while $a < 100_000_000 { $b := $si eq "" ?? 3 !! 5; ++$a }; say(nqp::time - $s); say($b) [18:45] nqp-moarvm: OUTPUT: «382541405␤5␤» [18:45] nqp: my int $a := 0; my $b; my int $s := nqp::time; my str $si := ~$s; while $a < 100_000_000 { if $si eq "" { $b := 3 } else { $b := 5 }; ++$a }; say(nqp::time - $s); say($b) [18:45] nqp-moarvm: OUTPUT: «346955696␤5␤» [18:58] nqp: my int $a := 0; my $b; my int $s := nqp::time; my str $si := ~$s; my $three := 3; my $five := 5; while $a < 10_000_000 { $b := $si eq "" ?? $three !! $five; ++$a }; say(nqp::time - $s); say($b) [18:58] nqp-moarvm: OUTPUT: «31529592␤5␤» [18:59] nqp: my int $a := 0; my int $b; my int $s := nqp::time; my str $si := ~$s; while $a < 10_000_000 { $b := $si eq "" ?? 3 !! 5; ++$a }; say(nqp::time - $s); say($b) [18:59] nqp-moarvm: OUTPUT: «36367617␤5␤» [18:59] nqp: my int $a := 0; my int $b; my int $s := nqp::time; my str $si := ~$s; while $a < 10_000_000 { $b := $si eq "" ?? 3 !! 5; ++$a }; say(nqp::time - $s); say($b) [18:59] nqp-moarvm: OUTPUT: «39076562␤5␤» [19:00] both are a little bit faster with the $three/$five, but the difference between the two remains (locally) [19:07] *** brrt left [19:09] perf shows ~%22 spent in MVM_coerce_istrue_s in the fastest version, but yeah, my jitting makes it worse (i assume it's not the jits fault, but the added branch in MVM_coerce_istrue_s [19:09] Well it comes down to a single set instruction that makes the difference. The ternary version actually writes the result into a temporary register in the branches and at the end writes from the temporary to the target register. The if/else version writes to the target directly. [19:10] nice find. is the temp reg use in the ternary version necessary? [19:10] Not even spesh can eliminate this additional set, because we cross a PHI boundary [19:11] huh. i've always thought of ternary as same-to-faster than if/else [19:11] Well...obviously no, because there's an equivalent version that gets by without it. But, writing a code generator that pulls this off might be a bit tricky [19:14] It looks easy in a case like $a := $cond ?? $b !! $c; But ternaries are not just used in assignments. For something like foo($cond ?? $a !! $b) you very much need that register for the result. [19:17] nqp: my int $a := 0; my int $b; my int $s := nqp::time; my str $si := ~$s; while $a < 10_000_000 { $si eq "" ?? ($b := 3) !! ($b := 5); ++$a }; say(nqp::time - $s); say($b) [19:17] nqp-moarvm: OUTPUT: «35218600␤5␤» [19:17] This compiles to exactly the same as the if/else version [19:20] well, i guess if it's any consolation, both nqp and rakudo have only a couple lines that match `git grep -P '^\s*\$\w+ := .*\?\?'` [19:21] which actually kind of surprises me [19:22] oh, a few more if you use \S+ instead of \w+ [19:24] and a lot of other are broken up over multiple lines and won't match that regex [19:25] <[Coke]> Didn't lizmat do a bunch of work to replace unoptimized raku/nqp code with more optimized nqp calls? wouldn't surprise me if that's why [19:25] <[Coke]> ... also I wonder if once new-disp hits if we can consider unrolling some of that. [19:27] `git grep -P -P '^\s*[$@%]\S+\s+:= .*\?\?'` finds some more [19:33] i also find it crazy that literal numbers in nqp are slower than binding a variable to the number and then using the variable. how difficult would that be to optimize? [19:42] Well the $foo := $cond ?? $a !! $b pattern does lend itself well to static optimization. [19:43] The issue with the literal numbers is that they will get boxed for every loop iteration, while my version with $three and $five pulls that boxing out of the loop. [19:44] The my int $b; version of course doesn't have the boxing overhead in the first place [19:46] hm, right [19:55] so: $foo := $cond ?? a !! b is bad ?? [19:59] it's a tiny bit slower than $cond ?? ($foo := a) !! ($foo := b) [20:03] i wouldn't go about mass re-writing any of nqp/rakudo yet [20:05] It's really very tiny bit slower [20:05] but isn't that more bytecode, and thus less likely to inline? [20:06] by about one instruction in the loop [20:13] i'm thinking since the exprjit currently doesn't cross bb boundaries, we're leaving a little on the table in terms of performance when emitting the actual assembly code [20:13] <[Coke]> (rewrite) no, not without a clear advantage, agreed. [20:14] nine: when you say that one set tthat we can't eliminate crosses a phi boundary, can we perhaps change what writes to that register to write to the register that set writes to? [20:16] Well it's certainly possible, since there is the equivalent version that gets by without the temp register. Getting it right may just be tricky. [20:21] *** linkable6 left [20:21] *** evalable6 left [20:24] here's an idea, put the ++$a in front, before the ??!! [20:25] don't think it'll actually do a lot [20:25] but it'd put the add operation into the first block's exprjit tree [20:26] oh wow, that is a bunch faster [20:27] nqp: my int $a := 0; my int $b := 0; my int $s := nqp::time; while $a < 1_000_000_000 { $b := $a < 100 ?? 3 !! 4; ++$a; }; say(nqp::time - $s); say($b) [20:27] nqp-moarvm: OUTPUT: «1639696338␤4␤» [20:27] nqp: my int $a := 0; my int $b := 0; my int $s := nqp::time; while $a < 1_000_000_000 { ++$a; $b := $a < 100 ?? 3 !! 4; }; say(nqp::time - $s); say($b) [20:27] nqp-moarvm: OUTPUT: «1421361707␤4␤» [20:28] i get about the same results locally with MVM_SPESH_BLOCKING=1 [20:29] nqp: my int $a := 0; my int $b := 0; my int $s := nqp::time; while $a < 1_000_000_000 { ++$a; $a < 100 ?? ($b := 3) !! ($b := 4); }; say(nqp::time - $s); say($b) [20:29] nqp-moarvm: OUTPUT: «1651706311␤4␤» [20:29] now that version is slower [20:29] so just noise? [20:30] yes. no. dunno [20:30] maybe we'd need to look at more realistic code to see the difference [20:31] optimizing/benchmarking is hard, i'm going to go kill some more virtual mechanical dinosaurs [20:35] *** patrickb left [20:37] good choice [21:23] *** linkable6 joined [22:23] *** evalable6 joined [22:29] m: say 1330 / 1349 [22:29] rakudo-moar 74d7ff771: OUTPUT: «0.985915␤» [22:29] 3 more from callwith/nextwith support for multi dispatch [22:30] ah, sorry, 2 more