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.
timo stumbled upon an incomplete optimization i made 6 years ago 01:21
very minor effect, though. still nice to have.
MasterDuke one that's already been merged? 01:39
timo yes 01:54
MasterDuke nice. can it be completed? 01:55
timo: should in-situ strings even be added to the GC worklist? 02:30
timo yes
the pointer that points at them still needs to be kept up to date if it moves, and it has to be kept alive in the view of the mark phase 02:31
MasterDuke ah, right
hm. during a rakudo build, 294154 strings of type MVM_STRING_GRAPHEME_32 and only one graph were garbage collected 02:41
and 20k of 2 chars 02:42
i wonder how/where they were created
any easy way to find that out> 02:47
timo not really an easy way to find it out i don't think. many breakpoints? 02:58
MasterDuke hm. almost the exact same number are seen in copy_to 03:01
maybe it's worth a check there to turn the destination into an in-situ 03:02
hm, how can i micro-benchmark copy_to? 03:28
doh, looked at the wrong log file. strings aren't copied at all 03:48
it looks like copy_to in MVMString.c is never called when building rakudo? that seems surprising 03:51
05:05 jjatria left, Techcable left, leont left, gfldex left, camelia left 05:06 jjatria joined, Techcable joined, leont joined, gfldex joined, camelia joined, Techcable left, nine left, coleman left, JRaspass left, nine joined, coleman joined, JRaspass joined 05:09 Techcable joined
nine Since strings are immutable, there's little point in copying them, is there? 07:23
07:49 sena_kun joined 08:41 sena_kun left 11:13 MasterDuke left
timo right, i assume it would only happen if you manually nqp::clone a string, or something like that? 14:29
14:31 [Coke] left 14:33 [Coke] joined 21:02 harrow left 21:26 sena_kun joined 21:30 harrow joined 21:45 sena_kun left
timo i finally wrote a tool that takes a speshlog for "before" and a speshlog for "after" and tries with a bit of effort to pair up matching specializations 22:32
so you can actually properly diff specializations after you make some kind of change
storage.aperture-labs.org/s/sZMSfDj2XNFHHEF 22:46
since spesh is nondeterministic, there's still going to be some diffs that put code that is very different against each other 22:56
23:13 MasterDuke joined
MasterDuke nine: huh? i would have thought immutable strings would mean more copying 23:13
timo: i tried nqp::clone with a string last night, but it still didn't trigger copy_to 23:14
timo: also, very cool. i've wanted a spesh log differ forever and never got around to doing anything about it myself
timo immutable strings involve more creation of string objects because every string operation needs to make a new one, though with strands we don't have to be copying the string contants all the time 23:15
MasterDuke yeah, make a new one and then copy the old one into the new and modify the new 23:16
Geth MoarVM/turn_guard_into_just_if_possible: abab265d06 | (Timo Paulssen)++ | src/spesh/optimize.c
When guarding conc or type and type is known, guard just conc/type

The difference in moar bytecode is very small, but in JITted code it's a bit bigger since the non-"just" variant also jits a spesh slot access first.
23:18
MoarVM: timo++ created pull request #1826:
When guarding conc or type and type is known, guard just conc/type
MoarVM/better_empty_strings: b33806e583 | (Timo Paulssen)++ | 2 files
latin1.c and ascii.c can return str_consts.empty for 0-length string

except the very first time when creating the 0-length string constant
23:23
MoarVM/better_empty_strings: 2a0dc7f171 | (Timo Paulssen)++ | 2 files
latin1.c and ascii.c can return str_consts.empty for 0-length string

except the very first time when creating the 0-length string constant
23:25
timo (had it on top of the other branch first)
Geth MoarVM: timo++ created pull request #1827:
return pre-made empty string constant from latin1 and ascii
23:26
MasterDuke nice