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.
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
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
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
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
lizmat in that case let's forget about that idea for nonw 09:17
*now

Powered by Cro and the Raku® Programming Language.

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

Thank you!