| 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 | |
| build.opensuse.org/public/build/ho...akudo/_log | |||
| 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 | |
| yes | |||
| 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 |
02:07 | |
| 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 0 |
||
| 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 | auau | 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 | ||