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:07 reportable6 left 00:10 reportable6 joined
Geth MoarVM/validator_labels_array_bitfield: 1744a2e45a | (Timo Paulssen)++ | src/core/validation.c
use fixedsize allocator in validator for labels arr
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
00:42 vrurg left 00:43 vrurg joined
Geth MoarVM/validator_labels_array_bitfield: 02e896f923 | (Timo Paulssen)++ | src/core/validation.c
branchlessly update fb->specializable
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
01:47 kjp left
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
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
02:45 frost joined 03:45 coverable6 left, releasable6 left, bloatable6 left, notable6 left, unicodable6 left, greppable6 left, benchable6 left, evalable6 left, sourceable6 left, shareable6 left, quotable6 left, linkable6 left, reportable6 left, nativecallable6 left, statisfiable6 left, tellable6 left, committable6 left, bisectable6 left, quotable6 joined, shareable6 joined, linkable6 joined, bloatable6 joined, committable6 joined 03:46 coverable6 joined, bisectable6 joined, statisfiable6 joined, notable6 joined, greppable6 joined 03:47 releasable6 joined, sourceable6 joined, reportable6 joined, unicodable6 joined, evalable6 joined, benchable6 joined, nativecallable6 joined 03:48 tellable6 joined 04:48 statisfiable6 left, reportable6 left, tellable6 left, unicodable6 left, bloatable6 left, committable6 left, nativecallable6 left, linkable6 left, evalable6 left, bisectable6 left, benchable6 left, notable6 left, coverable6 left, sourceable6 left, greppable6 left, releasable6 left, shareable6 left, quotable6 left 04:49 shareable6 joined, bisectable6 joined, bloatable6 joined, coverable6 joined, committable6 joined, reportable6 joined, benchable6 joined, linkable6 joined 04:50 evalable6 joined, tellable6 joined, greppable6 joined, nativecallable6 joined, releasable6 joined 04:51 quotable6 joined, sourceable6 joined, notable6 joined, statisfiable6 joined, unicodable6 joined 05:51 benchable6 left, releasable6 left, unicodable6 left, notable6 left, bloatable6 left, shareable6 left, linkable6 left, evalable6 left, tellable6 left, quotable6 left, sourceable6 left, statisfiable6 left, committable6 left, greppable6 left, bisectable6 left, reportable6 left, coverable6 left, nativecallable6 left, tellable6 joined, bloatable6 joined, coverable6 joined 05:52 statisfiable6 joined, reportable6 joined, notable6 joined, sourceable6 joined, bisectable6 joined, benchable6 joined, releasable6 joined, shareable6 joined, committable6 joined, greppable6 joined 05:53 nativecallable6 joined, unicodable6 joined, evalable6 joined, quotable6 joined, linkable6 joined 06:07 reportable6 left 06:08 reportable6 joined
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
08:28 frost left 08:31 frost joined
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
09:09 crystalfrost[m] joined
nine 482 spectest files passing on RakuAST. 302 without doing a non-RakuAST spectest run first 09:10
timo \o/
09:30 linkable6 left, linkable6 joined 09:37 Altai-man joined 09:40 sena_kun left 09:48 Altai-man left 10:33 sena_kun joined
lizmat nine++ 11:15
12:08 reportable6 left 12:10 reportable6 joined 12:15 frost left 12:33 frost joined 13:26 frost left
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
17:17 vrurg_ joined, vrurg left 17:26 sena_kun left 18:07 reportable6 left 18:08 reportable6 joined 18:18 sena_kun joined 19:17 japhb left 19:19 sena_kun left 19:20 sena_kun joined 19:22 japhb joined 19:41 sena_kun left 19:46 vrurg_ is now known as vrurg 20:04 sena_kun joined 21:49 kjp joined 23:14 [Coke]_ joined 23:16 [Coke] left 23:28 mst left