|
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. |
|||
|
03:28
rypervenche left
03:31
rypervenche joined
03:33
tbrowder left,
patrickb left
03:35
tbrowder joined
03:56
tbrowder left,
ilogger2 left,
harrow left,
bisectable6 left
03:57
bisectable6__ joined,
harrow joined
03:58
tbrowder joined,
ilogger2 joined
03:59
patrickb joined
07:10
lizmat left
07:11
lizmat joined
07:33
sena_kun joined
08:11
sena_kun left
18:07
sena_kun joined
|
|||
| MasterDuke | interesting. the patch that doesn't allocate an empty array in MVM_nfa_run_proto (and accounts for that in nqp) looks like maybe it takes *slightly* more instructions when compiling CORE.e, even though the number of allocations is definitely reduced | 18:32 | |
| i wonder if it would be a terrible idea to have elems of a VMNull return 0 instead of the `elems requires a concrete object (got a VMNull type object instead)` exception | 18:37 | ||
| lizmat | also for nqp::chars and nqp::null_s | 18:46 | |
| tellable6 | 2024-08-24T13:57:17Z #raku-dev <finanalyst> lizmat just sent you an email about RakuDoc/highlighting conflict | ||
| MasterDuke | the patch is definitely faster with a microbenchmark that calls nqp::nfarunproto in a loop creating no fates...but that's not really a surprise i guess | 18:57 | |
| and a simple microbenchmark that just generates one fate is a tiny bit more instructions, and pretty much the same time | 19:11 | ||
| which is good, since i think that'd be the worst case for this change | 19:12 | ||
|
19:42
Techcable left
19:46
Techcable joined
19:49
lizmat left
20:05
lizmat joined
22:42
sena_kun left
|
|||