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:00
reportable6 left
00:02
reportable6 joined
01:36
evalable6 left,
linkable6 left
01:37
linkable6 joined
01:39
evalable6 joined
|
|||
MasterDuke | jnthn: still around? | 01:43 | |
huh. moarvm/nqp have an `indexn?at` op, but they appear to be almost unused. only in nqp's `QAST::MASTRegexCompiler.enumcharlist()`. i wonder if they could be removed, or if instead maybe there are more places they'd make sense | 02:06 | ||
02:22
frost joined
03:21
coleman left,
coleman joined
06:00
reportable6 left
06:03
reportable6 joined
07:19
frost left
07:45
sena_kun joined
08:08
frost joined
08:24
frost left
10:30
sena_kun left
|
|||
jnthn | I was sure I had used CONTROL with CX::Warn somewhere in the past, but couldn't remember where to point to an example. This morning in the shower (why is it always this way...) I did remember a case: github.com/oposs/agrammon/blob/57e...ula.t#L951 | 10:57 | |
There's actually a second one in that repo that probably isn't my doing. | |||
11:06
sena_kun joined
12:00
reportable6 left
12:02
reportable6 joined
|
|||
[Coke] | jnthn: as long as the URL didn't come to you full formed. | 12:33 | |
MasterDuke | jnthn: the question i had in mind earlier was about string encoding/iterating/etc. those functions show up decently near the top of random perf profiles, and looking at them, a bunch have a switch over the storage type in the tight loop | 12:55 | |
i once created something like an MVM_string_encode_utf8_from_grapheme32 which just assumed the storage type, and not surprisingly it was a bunch faster | 12:57 | ||
however, it might be a slog to create specific versions for all the storage types and find all the places we can be sure of the type and then use the right one | 12:58 | ||
but i haven't thought of anything better | |||
is this something you've thought about, and/or do you have any suggestions? | |||
jnthn | I kinda hoped modern compilers would be able to do the switch extraction, but apparently not | 13:56 | |
(e.g. transform the code from switch inside loop to loops inside switch) | |||
Also that branch prediction would come out relatively well over a longer string... | 13:58 | ||
en.wikipedia.org/wiki/Loop_unswitching fwiw | 14:00 | ||
MasterDuke | yeah, i just recently had a very similar situation at work and also would have hoped the compiler could figure it out. just had to resort to a macro to create a bunch of specific function | 14:19 | |
and yeah, i'm sure it predicts nicely, but the change in runtime was noticeable | 14:20 | ||
lizmat | and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2023/02/20/2023-...herkining/ | 15:10 | |
japhb | MasterDuke: Which compiler(s) did you do the comparison on? | 17:03 | |
Also I guess the storage type needs to be reassessed at each strand boundary | 17:05 | ||
(But of course we can do a tight type-specific loop *within* each strand) | |||
18:00
reportable6 left
18:03
reportable6 joined
18:11
sena_kun left
|
|||
MasterDuke | japhb: i default to gcc, but good point, i should see what a profile looks like when compiled with clang | 18:20 | |
19:02
sena_kun joined
|
|||
MasterDuke | oh interesting. clang on master is just slightly slower than gcc at `MVM_SPESH_BLOCKING=1 raku -e 'my $a = "tolstoy.txt".IO.slurp; my $b; my $s = now; $b = $a.encode for ^100; say now - $s; say $b.bytes'` | 19:25 | |
where `wc tolstoy.txt` reports ''66055 566309 3359550 tolstoy.txt' | 19:26 | ||
on my add_fast_path_when_utf8_encoding branch, clang is slightly faster, ~0.81s master vs ~0.76s branch | 19:27 | ||
gcc on master is ~0.73s vs ~0.38 branch | 19:28 | ||
one difference is that it looks like gcc inlines utf8_encode() and clang doesn't | 19:36 | ||
if anyone is curious, this github.com/MoarVM/MoarVM/compare/m...8_encoding is all i've done so far | 19:43 | ||
replacement and translate_newlines are probably also false and true most of the time, i could create an even more stripped down version | 20:15 | ||
oops, false and false | 20:22 | ||
[Coke] | should new moarvm tickets get announced here? | 22:03 | |
(added one asking for a few dirops to be converted to libuv to avoid a windows issue0 | |||
github.com/MoarVM/MoarVM/issues/1743 | |||
22:08
evalable6 left,
linkable6 left,
evalable6 joined
22:11
linkable6 joined
22:44
sena_kun left
|
|||
lizmat | issues are not reported by Geth afaik | 23:21 |