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.
Geth MoarVM/validator_labels_array_bitfield: 1744a2e45a | (Timo Paulssen)++ | src/core/validation.c
use fixedsize allocator in validator for labels arr
 00:35
MoarVM/validator_labels_array_bitfield: 86bc450310 | (Timo Paulssen)++ | src/core/validation.c
use bitfield for validator label positions
timo anyone want to test if this improves startup times? it kind of looks like it doesn't on my machine
raku -e 'say "hi"' allocates a total of 380 kbytes with this patch, so it'd have been 4 times that without. that's only the sum, though, and these allocations are short-lived, too 00:38
about 300 kbytes is the size of the biggest single allocation without the / 4 factor 00:42
i think we can even still halve the size, since we are 16 bit aligned with the bytecode at the moment
Geth MoarVM/validator_labels_array_bitfield: 02e896f923 | (Timo Paulssen)++ | src/core/validation.c
branchlessly update fb->specializable
 00:54
timo this little bit of code actually emitted a branch, believe it or not :P
here's where the real perf happens
it feels like the validator is a good candidate for a little bit of vectorization work 00:56
Geth MoarVM/update_ops_look_for_preexisting_sequences: a2b60e7003 | (Timo Paulssen)++ | tools/update_ops.raku
find a new op's argument flags in earlier ops
 01:49
timo the code here spits out that the space taken up by flags for ops could shrink from 2.4kbytes down to 925 bytes. however, that does not include that when we move the operands flags out, all ops will still have a pointer-sized entry in them. could go down to two bytes if turned into an offset into the array of all flags, though? 01:51
1916 bytes of offsets or 7664 bytes of pointers 01:54
so the 2.4kbytes would be if all flags were concatenated, skipping the empty flags, which are currently inlined to the MVMOpInfo struct and therefore always 8 bytes big
but in fact, the total size based 01:55
on the 8 bytes for flags is the same as the 7664 number
so if we have a big buffer of flags that would be just 925 bytes big, we'll pay an additional 1916 bytes to put indices where the flags lived 01:56
m: say 7664 - (925 + 1916)
camelia 4823
timo m: say 7664 - (2497 + 1916) 01:57
camelia 3251
timo we could save 3251 bytes with a simple approach (just concatenate and then save 6 bytes per op info entry) or 4823 bytes with a slightly more involved approach (find op flags anywhere earlier in the op flags buffer, including overlapping between different ops) 01:58
this is also a "smallest common supersequence" problem that can be solved to optimize that 925 number even further 01:59
little trade-off here in code complexity (a pointer indirection every time we need to get at an op's flags) growing, but memory in total shrinking 02:01
always count on timo to swoop in with some probably only barely useful optimization idea 02:02
nine Huh...I thought the fixed size allocator went away when we switched to mimalloc 06:38
timo oh, is mimalloc good enough at that? okay :D 07:23
i'm woefully out of date, clearly
nine Apparently we haven't thrown out the fixed size allocator yet, but it doesn't give any advantages over mimalloc 07:27
timo we don't even get storage reduction through not double-tracking allocation sizes? 07:37
nine Don't know about that one 07:48
timo well, the branch is not only fixedsized allocator transformation. maybe the rest is still worth having 08:36
but i may not have time to measure things properly today 08:37
nine 482 spectest files passing on RakuAST. 302 without doing a non-RakuAST spectest run first 09:10
timo \o/
lizmat nine++ 11:15
lizmat And yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2022/06/27/2022-...-seasoned/ 14:21
vrurg I wonder if valgrind is capable of helping me to trace down likely memory issues. In my work project I get errors like Buf[int8] not matching Blob, VMNull from symbol lookups, etc. Could be caused by double-free, wrong pointers, whatever. But for now I have no clue what to look at. 14:43
timo it's worth a try at least, but i can't make any guarantees 15:22

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!