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:10 reportable6 joined 01:55 evalable6 left, linkable6 left 02:20 vrurg joined, frost joined 02:57 linkable6 joined 03:06 frost left 03:48 vrurg left 03:49 vrurg joined 04:49 quotable6 left, squashable6 left, benchable6 left, nativecallable6 left, releasable6 left, tellable6 left, linkable6 left, notable6 left, bloatable6 left, coverable6 left, shareable6 left, bisectable6 left, committable6 left, greppable6 left, statisfiable6 left, unicodable6 left, sourceable6 left, reportable6 left, quotable6 joined, unicodable6 joined 04:50 committable6 joined, notable6 joined, releasable6 joined 04:52 bisectable6 joined, bloatable6 joined 04:56 frost joined 04:57 evalable6 joined 05:51 coverable6 joined 06:10 squashable6 joined 06:49 nativecallable6 joined 06:51 vrurg_ joined, sourceable6 joined, greppable6 joined 06:52 benchable6 joined 06:54 vrurg left
Nicholas good *, * 06:56
07:09 squashable6 left 07:10 reportable6 joined 07:11 squashable6 joined 07:19 frost left 07:50 linkable6 joined 07:52 tellable6 joined 08:48 frost joined 08:51 statisfiable6 joined 09:08 frost left
lizmat Nicholas o/ 09:13
Nicholas \o 09:20
09:51 shareable6 joined
Geth MoarVM: MasterDuke17++ created pull request #1672:
Bump mimalloc to v2.0.5
10:08 squashable6 left
nine 3 10:25
So the connection wansn't stuck enough to prevent my shortcuts in wrong keyboard layout from getting through... 10:26
MasterDuke huh, i thought the azure `[error]No hosted parallelism has been purchased or granted.` had been fixed a day or two ago. maybe just for rakudo? 10:38
Nicholas I really can't answer that. But "maybe just for" sounds like a plausible answer. MoarVM and rakido are different GH organsiations, IIRC 10:43
MasterDuke patrickb: have you heard anything back from azure? 10:44
lizmat hmmm interesting: I was still wondering why ++$i still seemed slightly slower in some cases than $i = nqp::add_i($i,1) 10:52
and I think I found it:
sub a(){ ++$i } is a sub with 48 bytes according to the spesh inline log
sub a(){ $i = nqp::add_i($i,1) } is a sub with 40 bytes according to the spesh inline log 10:53
where $i is a native int
and I'm at a loss to understand why that is
m: use nqp; my $l := nqp::list; nqp::setelems($l,-1); say nqp::elems($l) # MasterDuke 10:56
camelia Unable to allocate an array of 18446744073709551615 elements
in block <unit> at <tmp> line 1
10:57 linkable6 left
MasterDuke lizmat: the inc vs add must be something going on in rakudo. when i run `my int $a := 0; sub inc-a() { ++$a }; my int $b := 0; sub add-b() { $b := nqp::add_i($b, 1) }; my int $i := 0; while ++$i < 1_000_000 { inc-a(); add-b() }; say($a); say($b)` in nqp and make a spesh log the before and after of both subs is identical (and they have the same 11:03
lizmat maybe it's the optimizer doing something stupid? 11:04
MasterDuke do you get the same thing with --optimize=off? 11:05
lizmat eh, indeed, so not the optimizer 11:08
raku --optimize=off -MSIL -e 'my int $i; sub a(){ use nqp; $i = nqp::add_i($i,1) }; a for ^100000 11:09
MasterDuke ah, but the spesh log of running that example in rakudo shows they aren't identical
lizmat raku --optimize=off -MSIL -e 'my int $i; sub a(){ ++$i }; a for ^100000'
MasterDuke the add version ends with `set               r1(3),   r1(2)`, but the inc version ends with `sp_fastbox_bi_ic   r3(2), liti16(40), sslot(0), liti16(32),   r1(2), liti16(1)  # [002] box_i into a Int 11:11
`return_o          r3(2)`
lizmat ah, so the ++ version is boxing when it shouldn't? 11:12
MasterDuke inc: Bytecode size: 362 byte    vs     add: Bytecode size: 204 byte
BB0 of the 'before' of inc version ends with `dispatch_o        r3(2), lits(raku-rv-decont), callsite(0x7fce530a1de0, 1 arg, 1 pos, nonflattening, interned),   r2(3)` and then BB2 is just `return_o          r3(2)` 11:14
but BB0 of the 'before' of the add version
ends with `decont_i          r1(3),   r2(3)` and then BB2 is just `return_i          r1(3)` 11:15
the inc version also has a one deopt all and three deopt one annotations, but the add vesion only has one deopt one annotation 11:17
11:18 CaCode joined
lizmat hmmm... my int $i; sub a(){ $i = $i + 1 }; a for ^100000 gives the same byte size as using nqp::add_i 11:22
MasterDuke wow, with --optimize=off the before and after of the inc version are both bad
some interesting differences in the ast vs opt versions of both the inc and add subs 12:02
12:02 CaCode left
MasterDuke in the --target=optimize versions, inc has `QAST::Var(lexical $¢ :decl(contvar))` (and $! and $/), but those are all `QAST::Op(null)` for the add sub 12:05
12:05 reportable6 left
MasterDuke both turn $_ into a null 12:06
12:10 squashable6 joined
MasterDuke ah, it's the `&prefix:<++>` call. same thing happens to the add version if i make it `$b = $b + 1` instead of `$b = nqp::add_i($b, 1)` because then there's a call to `&infix:<+>` 12:10
the optimizer re-writes both to get rid of the calls, but i guess that happens after delete_unused_magicals() 12:14
oh interesting. the calls are removed first, but $!calls isn't decremented when that happens, so delete_unused_magicals() thinks they're still there 12:38
nine a bug then!
lizmat a long standing one then :-) 12:45
13:07 reportable6 joined 13:59 linkable6 joined
MasterDuke ok, now both versions have all the magicals removed 14:01
14:03 discord-raku-bot left 14:04 discord-raku-bot joined
MasterDuke didn't change anything about the before or after in the spesh log though 14:06
lizmat :-( 14:07
14:08 vrurg joined 14:10 vrurg_ left
MasterDuke does pass a spectest though, guess i'll pr it 14:15
man, $!calls seems like it really might not be very accurate at all. it really should be incremented every time a *new* `call*` is created 14:21
15:10 linkable6 left, evalable6 left 15:12 evalable6 joined 15:13 linkable6 joined
lizmat ok, confirmed: no difference 16:07
oops, wrong channel :-)
16:21 rypervenche left
MasterDuke github.com/rakudo/rakudo/blob/mast...2835-L2871 optimizes a p6decontrv in some cases. but `sub a(){ ++$i }` can't be now because its $last_stmt is a QAST::Want. is there anything we could do? 16:56
the branches of the want are actually `QAST::Op(assign_i)` 16:57
well i just duplicated github.com/rakudo/rakudo/blob/mast...2835-L2854 in the case that $last_stmt is a QAST::Want and its branch is a QAST::Op and the spesh log now shows a much more similar 'after' for the inc version and the add version 17:10
but i'm less than 100% sure it's a safe/correct optimization. it does pass a spectest, but will PR it later so people can see 17:13
18:06 reportable6 left
dogbert11 Any specific reason why we can't merge github.com/MoarVM/MoarVM/pull/1636 ? 18:09
19:02 dogbert11 left 19:06 squashable6 left 19:11 dogbert17 joined
Geth MoarVM: cc54203eed | (Jan-Olof Hendig)++ | 2 files
Update libuv to version 1.43.0 take 3

Spectest clean under Linux Mint (Ulyana)
MoarVM: 420b68f06b | MasterDuke17++ (committed using GitHub Web editor) | 2 files
Merge pull request #1636 from dogbert17/update-libuv-2-v1.43.0
19:56 mst_ is now known as mst 20:08 reportable6 joined
dogbert17 MasterDuke17++ 20:48
21:07 squashable6 joined 21:11 discord-raku-bot left 21:12 discord-raku-bot joined 22:19 dogbert17 left 22:47 linkable6 left 22:50 linkable6 joined 23:21 linkable6 left, squashable6 left, reportable6 left, evalable6 left, shareable6 left, statisfiable6 left, tellable6 left, benchable6 left, greppable6 left, sourceable6 left, nativecallable6 left, coverable6 left, bloatable6 left, bisectable6 left, releasable6 left, committable6 left, notable6 left, unicodable6 left, quotable6 left, [Coke] left 23:23 linkable6 joined, squashable6 joined, reportable6 joined, evalable6 joined, shareable6 joined, statisfiable6 joined, tellable6 joined, benchable6 joined, greppable6 joined, sourceable6 joined, nativecallable6 joined, coverable6 joined, bloatable6 joined, bisectable6 joined, releasable6 joined, notable6 joined, committable6 joined, unicodable6 joined, quotable6 joined, [Coke] joined
MasterDuke huh. we can't decide on a multi at compile time if it has any definedness constraints? we can't ever know at compile time if the arguments are defined or not? 23:30
so for `my Int $a = 0; sub inc-a() { $a = $a + 1 };`, the call to `&infix:<+>` is not inlined because in `analyze_dispatch()` even though a type match is possible, `$type_flags +& $DEFCON_MASK` is true 23:37
anyway, off to sleep 23:39