4 Mar 2023
MasterDuke virtualbox and kernel update, time to reboot and hope my windows vm works again. should be back in a couple min 01:09
ugh, windows vm still won't start 01:37
hm, i see a couple `reprop (decont|getattr|bindattr)_u unsupported in P6Opaque (Int|MoarVM::StringHeap)` in the uint spesh log, but none in the int spesh log 02:12
i've never seen that message before
well, got rid of those messages, but still no faster... 02:21
gist updated with those repr changes 05:00
nine MoarVM oops in spesh thread: Unknown handler in inline cache entry 12:19
MasterDuke i don't see it in that log, but was it the one in t/09-moar/01-profilers.t ? 15:09
nine zes 15:52
ugexe MasterDuke: not exactly libuv related per-se, but gist.github.com/ugexe/5bb5683a90f4...6d96bac4cc shows that manually prefixing the path with \\?\ for the nqp::stat call allows it to see the file exists 21:39
your PR works if I prefix the paths as well 23:29
5 Mar 2023
MasterDuke oh nice, i'll try just adding that to the pr 01:37
huh. `MoarVM panic: Can't JIT opcode <sp_fastbox_u_ic>` when run normally, but completes just fine (though not any faster) in gdb 02:01
nevermind, that was an easy fix 02:02
still not faster though... 02:03
6 Mar 2023
Geth MoarVM: MasterDuke17++ created pull request #1746:
Add a bunch of `*_u` stuff
MasterDuke hm. i wonder if we need e.g., add_u? 02:27
timo1: any idea how i could also get the checkarity and param* ops optimized away here gist.github.com/MasterDuke17/731d4...sh-log-L67 like they are in the `int` version? 02:35
[Coke] is there a JIT if we're running in arm64? 02:36
or just x86_64 (on mac)
MasterDuke no jit on arm 02:42
timo1: oh, i think it's back to that arg_type business. so what is my pr missing? 02:46
nine: interestingly, that t/09-moar/01-profilers.t used to be trivially reproable for me, but now it's been running 750+ times without a fail (with spectests running in the background) 03:52
timo1 we need the param_rp_u op to be able to handle a native int (not uint) flag in the callsite (and probably the rp_i to support a native uint flag) 08:50
it's possible that we are actually supposed to have a uint flag in the callsite there, not sure if that's true. that woul mean a change in rakudo probably. perhaps in the piece that optimizes a for loop over a range? 09:40
lizmat yeah, afaik that only looks at the primspec of native ints ? 10:22
timo1 so --target=optimize for the example code with int and with uint could be insightful 10:52
beyond just looking at the generated moar instructions
we might need both the moar changes MD already put in the PR and an additional change in rakudo's optimizer 10:53
maybe also a bit more inside spesh 10:54
upon a quick glance it looks like the for-over-range optimization activates, but it probably generates an int register where it could know that the pointy block takes a uint 10:59
slightly confounding issue: for this optimization we start the counter register at -1
if we want to continue using this, we will have to make sure that whatever we do we properly overflow from whatever -1 turns into back to 0 or we get very funky results from very benign looking code 11:00
possible further point of research: what happens if we put an at-the-integer-limit value as the start or end of the range we for over, since we have the -1 at the start value, the -1 at the end value, and checks and whatnot 11:01
do we ever accidentally make a 0 steps for loop when the start and end value are fine before the optimization but become funky after? 11:02
lizmat timo1 assigning -1 to a uint and then incrementing yields 0, so there no issue there afaik 11:05
m: my uint $a = -1; say $a; $a++; say $a
camelia 18446744073709551615
timo1 this amuses me: the symbol for NL puts an nl at the top and an L at the bottom, so NL followed by 0 followed by another NL reads like NON LOL 11:25
lizmat ␤a␤u␤a␤u 12:14
timo1 very good 12:17
7 Mar 2023
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2023/03/07/2023-10-toronto/
9 Mar 2023
MasterDuke timo1, nine, et al.: think something like github.com/ruby/ruby/pull/5944/files might be applicable/useful for us? 02:29
Woodi MasterDuke: they implementing "on-demand executable memory" so they replaced PROT_READ | PROT_EXEC with PROT_NONE ? :) maybe just before filling it but patch do not mention protection elsewhere... 05:44
timo1 we allocate every frame as we jit it, so i think this particular optimization idea does not apply 10:04
14 Mar 2023
lizmat and yet another Rakudo Weekly News hit the Net: rakudoweekly.blog/2023/03/13/2023-11-ainions/ (yesterday already :-) 14:10
15 Mar 2023
raiph Please note comments by @Charles below accepted SO answer stackoverflow.com/a/75724718/1077672 22:07
17 Mar 2023
MasterDuke .tell raiph re "Please note comments by @Charles below accepted SO answer stackoverflow.com/a/75724718/1077672", maybe it would make more sense to bring this up with the libtommath team? in fact, there is currently activity around their prime number functions, so this is probably a fortuitous time to ask 02:11
20 Mar 2023
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2023/03/20/2023-12-priced-2/ 11:44
27 Mar 2023
and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2023/03/27/2023-13-finitely/ 13:58