|
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 |
09:52 | |
|
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 | |
| size) | |||
| 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 | ||
| vs | |||
| 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) |
19:44 | |
| 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 | ||