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 00:12 tellable6 joined 00:27 dogbert11 joined, dogbert17 left, samcv left 00:28 samcv_ joined 02:09 reportable6 joined 03:09 linkable6 left, evalable6 left 03:10 evalable6 joined 04:10 benchable6 left, notable6 left, coverable6 left, unicodable6 left, bloatable6 left, greppable6 left, releasable6 left, statisfiable6 left, bisectable6 left, committable6 left, squashable6 left, sourceable6 left, shareable6 left, reportable6 left, tellable6 left, evalable6 left, nativecallable6 left, quotable6 left 04:11 notable6 joined, benchable6 joined, shareable6 joined, reportable6 joined, unicodable6 joined, greppable6 joined 04:12 coverable6 joined, tellable6 joined, sourceable6 joined, committable6 joined, bloatable6 joined 05:12 squashable6 joined 05:13 quotable6 joined 06:07 reportable6 left 06:11 releasable6 joined 06:12 linkable6 joined 06:29 squashable6 left 06:30 squashable6 joined
Nicholas got UG 06:42
good UGT, #moarvm
07:07 reportable6 joined 07:11 nativecallable6 joined 07:13 evalable6 joined
MasterDuke nine: thanks, i'll take a look 07:45
jnthnwrthngtn: don't know that there's much new to you here, but it seems possibly relevant developers.redhat.com/articles/202...t-compiler 08:59
09:12 bisectable6 joined
lizmat morning *! 10:21
m: my uint @a; say @a.^array_type.^unsigned
camelia 1
lizmat looks like the "unsigned" method is not getting inlined:
unsigned BB(342, 18 bytes) -> BB(1):
target has a :useshll instruction and HLLs are different - ins: return_i
Nicholas very windy morning here 10:22
lizmat 40km/hour sustained here 10:23
Nicholas I don't have anything accureate to measure it. The neighbours thing is spinning so fast that it's blurred 10:24
I guess there's one higher speed - "it got ripped off"
jnthnwrthngtn Nothing to measure with here, except "furniture and plant pots are still on the terrace" 10:28
Nicholas one of our plant pots did a nose dive off the wall
first nose dive. Previous attempts have been sideways jumps 10:29
wait, previous successes
jnthnwrthngtn lizmat: I suspect the inliner might be able to "try harder" or something in that case 10:31
Given it's just a boxing
lizmat yeah, I was a little surprised as well
we have several places in the setting where we check for ^unsigned 10:32
not terribly hot, but still :-)
MasterDuke m: sub a() is inlinable { say "hi" }     # speaking of inlining, didn't realize this was a thing until just a couple min ago 10:33
camelia ( no output )
jnthnwrthngtn MasterDuke: I don't think it's very official :) 10:37
MasterDuke introduced 11 years ago, but doesn't seem to be used anywhere
jnthnwrthngtn I thought it was used internally in Actions to indicate what it thinks the static optimzier may inline, but maybe the way that works also changed 10:42
MasterDuke yeah, but there's nothing explicitly given the `is inlinable` trait 10:44
i tried adding it to `infix:<+>(Int:D $a, Int:D $b --> Int:D)`, but that didn't change anything 10:45
i.e., if i remove whether analyze_dispatch() cares about definedness constraints, it still can't `.inline_info` in the optimizer so the optimizer won't inline it 10:47
oh, wait, it's probably because $inlinable is supposed to be the QAST to inline 10:49
jnthnwrthngtn Yeah. That's surely not going to last past RakuAST 10:52
MasterDuke hm, i'm thinking i maybe shouldn't take any more time on this until after rakuast 10:53
fwiw, it was this i was trying to optimize, `my Int $a = 0; sub inc-a() { $a = $a + 1 };`, where pretty much the only thing the static optimizer does is turn the 'call' to `&infix:<+>` into a 'callstatic' 10:58
jnthnwrthngtn What were you trying to optimize about it? 10:59
MasterDuke inline the call. if it's `int` instead of `Int` the sub just becomes `decont_i` + `assign_i` + `add_i` 11:00
but the `Int` version is `p6decontrv` + `p6assign` + `callstatic` (and the magic variables aren't removed because of the call) 11:01
jnthnwrthngtn What how is it after spesh? 11:02
My general appraoch for the static optimizer was to try to inline native ops and to do a few other peephole-y things, but anything involving objects is for spesh
s/What how/But how/ 11:03
MasterDuke it's not terrible after spesh, but not as good as `my Int $a = 0; sub inc-a() { $a = nqp::add_I($a, 1, Int) };` 11:04
and there's a noticeable runtime difference
m: use nqp; my Int $a = 0; sub inc-a() { $a = nqp::add_I(nqp::decont($a), 1, Int) }; my int $i = 0; while ++$i < 10_000_000 { inc-a(); }; say now - INIT now; say($a) 11:05
camelia 0.290613108
MasterDuke m: use nqp; my Int $a = 0; sub inc-a() { $a = $a + 1 }; my int $i = 0; while ++$i < 10_000_000 { inc-a(); }; say now - INIT now; say($a)
camelia 0.331514287
MasterDuke m: use nqp; my Int $a = 0; sub inc-a() { ++$a }; my int $i = 0; while ++$i < 10_000_000 { inc-a(); }; say now - INIT now; say($a)
camelia 0.358639535
MasterDuke nqp version ends up 3 BBs, Frame size: 306 bytes, Bytecode size: 1443 byte 11:09
add version ends up 6 BBs, Frame size: 352 bytes, Bytecode size: 1755 byte 11:10
jnthnwrthngtn So what is spesh not eliminating that it could? 11:14
MasterDuke i'm not great at reading these gist.github.com/MasterDuke17/33cc6...dc7ee23681 11:15
but it looks like there are some guards on Int and the inline of `&infix:<+>` 11:17
patrickb MasterDuke: re azure CI parallel request: I got a rejection for all three applications, because they missed the absolute URLs to the repos we'd like to test. I thus resent the requests. That was yesterday. 11:22
MasterDuke whoops, thanks 11:23
.oO( I resent the rejections more than the requests... )
Nicholas patrickb: they don't automate that? 11:32
OK, sure, three might be hard to automate, but if policy is "you need to be asking about at least one repository" and "repositories must be absolute URLs" then any intern can write you a regexp that sits client-side to refuse to even submit an application with zero URLs in it. 11:34
11:35 linkable6 left, evalable6 left
MasterDuke jnthnwrthngtn: do you see any obvious ways to make the spesh of the `+ 1` version better? 11:36
11:37 linkable6 joined
nine MasterDuke: oh, specialization support in MIR is exactly what I've been hoping for :) 11:45
MasterDuke nine: to potentially use in moarvm? 11:46
nine yes
MasterDuke ah, your libgccjit idea?
nine libgccjit isn't a good match (among others license and latency), but Mir looks much better 11:51
MasterDuke oh, they aren't related? somehow i thought mir was just part of libgccjit 11:53
nine No, they really got nothing to do with each other. Except that libgccjit can be/become a backend for Mir to have a 2 stage JIT with quick generation of somewhat optimized code which is later replaced by thoroughly optimized code 11:56
12:08 reportable6 left 12:09 reportable6 joined 12:10 statisfiable6 joined
[Coke] (windy) one of the trees in my back yard looks someone snapped it in half about 6 feet off the ground, and it's just leaning, waiting to fall on the neighbor's house. (Someone coming this morning to deal with that a few others) 12:29
lizmat raku --target=optimize -e 'my int $i; $i % $i' # is it me or is the optimizer doing something weird here, generating two mod_i calls ? 12:34
12:38 evalable6 joined
MasterDuke github.com/rakudo/rakudo/blob/mast...t.pm6#L362 12:48
lizmat MasterDuke++ 12:49
isn't this a weird entry for a spesh log? 14:01
cis BB(18492, 0 bytes) -> BB(1)
can something be 0 bytes?
my idea was that some Complex methods create other Complex objects that are in fact constants 14:02
so I moved the Complex.cis method to the core_epilogue:
my constant c01 = Complex.new(0,1);
method cis(Complex:D:) { self.cos + self.sin * c01 }
and now it is reported as 0 bytes?
jnthnwrthngtn lizmat: What does the code calling cis look like? 14:04
lizmat my $a = 5i; $a.cis for ^200000 14:08
14:34 discord-raku-bot left, discord-raku-bot joined
jnthnwrthngtn lizmat: Given all of cos, sin, +, and * are pure, it's possible that spesh realizes it's all dead code, and deletes the lot 14:41
It can't do that when there's a Complex.new because the EA isn't so advanced yet
Making it a constant may well unblock it being able to see that it's all just throwaway work 14:42
lizmat aha... ok 14:43
jnthnwrthngtn: but you do think it's a worthwhile thing to pursue ? 14:44
jnthnwrthngtn Making it a constant? Sure, just you need a better benchmark :) 14:46
MasterDuke lizmat: is it the same for something like `my $a = (now.Int % 3 + 1)i; my $b; $b = $a.cis for ^200000; say $b`
lizmat still 0 for something like that 14:47
MasterDuke huh
lizmat my $a = (now % 3)i; my $b; $b = $a.cis for ^200000 14:48
I wonder if it has something to do with the fact that cis now lives in an augmented part of the class ?
jnthnwrthngtn I can't imagine that making a difference to how it inlines etc. 15:48
MasterDuke this is interesting. i'm back to the gmp branch rebase. currently on linux, `my int $int_min = -2**63; say $int_min +> 16` gives the correct result, as does making it an `Int`. on windows, the `int` version gives -18446603336221196288, but the `Int` version is correct 16:28
the actual shift is happening in the interpreter, and to no surprise, if you print the values there they are correct 16:29
so i guess somehow it gets converted into a bigint and then something goes wrong 16:36
ok, the problem is at github.com/MoarVM/MoarVM/blob/35b2....c#L85-L96 16:51
the MVMint64 value is correct (-140737488355328), but the resulting mpz_t is not (-18446603336221196288) 16:52
Nicholas: ping 17:05
Nicholas Hi, can't answer today. Sorry 17:07
MasterDuke no worries, may have just found something 17:11
18:08 reportable6 left 18:09 reportable6 joined
[Coke] regarding rakudo#4525 - with new-disp merged, is this ticket still relevant? If there are specific performance issues, seems like we should open those and close this generic one. 18:54
18:55 linkable6 left
lizmat [Coke] left a ping to melezhik 18:56
18:58 linkable6 joined 19:19 [Coke] left 19:24 [Coke] joined
MasterDuke huh. apparently i got better at googling and found this stackoverflow.com/questions/659826...pir-number which looked like the answer 19:31
but i get the exact same behavior 19:32
19:32 squashable6 left 19:33 squashable6 joined 19:36 Nicholas left
nine Certainly explains the platform difference 19:56
MasterDuke i think i have it fixed, slowly compiling in my windows vm now 19:57
that's fixed 19:58
nine So, we're getting closer to gmp? 20:15
MasterDuke closer, yes. still need to re-run a spectest 20:17
but even if that's clean, there are two open issues
src/math/bigintops.c:77:16: warning: variable ‘i’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Wclobbered]
   77 |         mpz_t *i = tc->temp_bigints[idx];
and then how to handle the abort() when exponentiation overflows 20:18
since i think github.com/MoarVM/MoarVM/pull/1402...7b6965e99e might not be perfectly threadsafe 20:19
oh, and need to fix the mingw build 20:30
not required, but good to have, is passing our allocation functions to gmp so it can use mimalloc 20:31
20:36 evalable6 left, linkable6 left
MasterDuke oh, looks like that was really simple to do (use our allocations functions in gmp) 21:01
21:12 discord-raku-bot left 21:13 discord-raku-bot joined 21:17 discord-raku-bot left, discord-raku-bot joined 21:33 tbrowder left, leont left, leont joined, tbrowder joined
[Coke] github.com/rakudo/rakudo/issues/4062 - is this closable now that new-disp is fully done? 21:47
21:54 Nicholas joined
MasterDuke hm, i get a ton of spectest fails, but lots of them seem to be not gmp related. e.g., t\spec\S32-io\file-tests.t failed to create a symlink 22:12
[Coke]: you run spectests on windows, right? 22:14
[Coke] not usually, but happy to do so. 22:15
I'm at 6a21196cdc - is there ok, or should I pull? 22:16
kicked one off 22:18
will gist it when done
MasterDuke anywhere nearish to HEAD is fine 22:19
[Coke] this is from some point today, I think, cool 22:20
already have one failure, but mostly ok
22:36 evalable6 joined
[Coke] looks like maybe it's hung. 22:42
failed 2/47 on S17-procasync\basic.rakudo.moar then no updates for a bit. 22:43
if it was going to hang somewhere, near proc-async wouldn't surprise me.
MasterDuke m: say 123123123123123123123123123123 gcd 123123123123123123123123123      # for some reason this is chewing up the cpu for a couple minutes on windows 22:47
camelia 123
MasterDuke [Coke]:  you try just that example on the command line?
[Coke] immediately returns 123 22:52
MasterDuke huh
looks like i still have some sort of problem, because not only does it seem to run forever in rakudo, doing nqp::gcd_I of those values in nqp gives 6188572990942219341 (but at least quickly) 22:57
ok, doing it correctly nqp hangs also 23:14
[Coke] (tried another spectest run, hung in the same place) 23:15
MasterDuke it does seems like the bigints are correct, it's just spinning inside mp_gcd() 23:55