|
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 | ||