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