|
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 | |
| oops | |||
| 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 9999999 |
||
| 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 9999999 |
||
| 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 9999999 |
||
| 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 | |
| jnthnwrthngtn | .oO( I resent the rejections more than the requests... ) |
11:31 | |
| 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 | |