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:19 MasterDuke joined
MasterDuke . 00:20
tellable6 2024-04-16T22:20:34Z #moarvm <lizmat> MasterDuke: I haz an idea to make MoarVM get a faster startup, but am scared to do this myself in MoarVM :-)
MasterDuke lizmat: i suspect the idea is switching cuiids from strings to ints?
a quick glance through moarvm doesn't reveal any obvious reason it *has* to be a string 00:22
02:03 vrurg_ left 02:04 vrurg joined
MasterDuke github.com/MoarVM/MoarVM/compare/m...uid_to_int builds MoarVM. however, NQP with no changes dies with `+++ Compiling   gen/moar/stage1/QRegex.moarvm 02:08
Serialization Error: missing static code ref for closure '' (/home/dan/Source/perl6/install/share/nqp/lib/MAST/Ops.nqp:8335)
   at NQP::src/vm/moar/QAST/QASTCompilerMAST.nqp:878  (src/vm/moar/stage0/QAST.moarvm:serialize_sc)1`
i'm less sure what modifications NQP needs
japhb Maybe it was originally intended to allow creating the IDs using a GUID generator and assigning them to compiles that persisted longer? 02:09
MasterDuke dunno. they were strings from the start, but the git commit messages and/or code comments don't really say why string vs int 02:10
ugexe the only thing that immediately sticks out to me is `MVMuint64 cuid_idx = get_vm_string_index(tc, ss, MVM_coerce_i_s(tc, sf->body.cuuid));` 02:55
string the default value is now 0 instead of null pointer or empty string
since the default value^
github.com/MoarVM/MoarVM/blob/d5da...#L129-L133
which maybe changes the behavior of ^ 02:56
i'm not sure if that'd actually matter though 02:57
04:09 MasterDuke left 05:42 vrurg left, vrurg joined
nine Inline::Perl5 generates cuids using 128 bit random numbers. 07:32
Do we actually know that switching to numbers would make things measurably faster? 07:36
07:55 sena_kun joined
lizmat well, it would mean not needing to walk the string heap for 21K+ entries at startup 08:23
for 6.c
+ 1200+ for 6.d 08:24
+ 3000 for 6.e
but I guess Inline::Perl5 kills the idea 08:25
MasterDuke: sorry for the noise
tellable6 lizmat, I'll pass your message to MasterDuke
nine Question is does that take a noticable time? Strings are prefixed by their length. So all we do when calculating the fast table is read that length, jump to the next string and repeat. Reading 20K memory locations in a dense memory block shouldn't take much time. This walk is pretty cache friendly. 09:03
lizmat that's also roughly 20K * 8 bytes of strings in memory 09:04
(as most strings are 5 chars, padded to 8 bytes) 09:05
nine If they are accessed. Bytecode files are memory mapped. The kernel will only actually read those parts into memory that are accessed. And it can flush parts from the cache if they are not used anymore (e.g. after the initial scan) 09:06
lizmat but are they flushed? aren't the cuuids not used as strings during runtime ? 09:07
nine Undoubtedly there is a cost of having these as strings. I'm just very unsure about this being a noticable cost.
I think they are really only used in error and logging messages 09:08
09:15 sena_kun left
lizmat in that case let's forget about that idea for nonw 09:17
*now
13:59 Util left 14:11 lizmat_ joined 14:15 lizmat left 14:16 lizmat joined 14:17 lizmat__ joined 14:20 lizmat_ left 14:21 lizmat left, lizmat__ left, lizmat joined 15:13 lizmat_ joined 15:16 lizmat left 15:52 lizmat joined 15:55 lizmat_ left 18:01 sena_kun joined 18:30 sena_kun left, sena_kun joined 18:42 Altai-man joined, sena_kun left 19:11 sena_kun joined, Altai-man left 19:34 sena_kun left 19:35 sena_kun joined 20:53 sena_kun left, sena_kun joined 21:58 vrurg left 22:07 vrurg joined 22:35 lizmat_ joined 22:39 lizmat left 22:49 lizmat_ left, lizmat joined 23:11 sena_kun left