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