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