MasterDuke timo: i'm not 100% sure that omitting a `if (repr_data->slot_type != MVM_ARRAY_OBJ) MVM_exception_throw_adhoc(tc, "MVMArray: atpos expected object register");` is safe 01:47
there does appear to be a performance benefit, but not earth shattering 01:48
`perf stat -r 5 ` when compiling CORE.c showed an average of `45636.11 msec task-clock` before and `44291.62 msec task-clock` after 01:49
376840131924 instructions before and 370807908625 after 01:50
`44449.25 msec task-clock` and 372857380706 instructions with those checks added 01:56
timo 45.6s vs 44.3s is significant 01:59
the variants that skip the check for what the type of the array has for its slots must only be used when the slot type is already known beforehand
ah, yes, either the functions in reprconv need to get that check, or all code that uses them has to do the check beforehand (less likely to be doable i think) 02:00
MasterDuke ok, i'll pr this with the checks in 02:01
i only did _[iso] because those were the most frequently hit, but i guess no harm in adding the others 02:02
oh ugh. i need to check and handle all the different sizes of i, u, n 02:19
this may end up not all that faster at all
timo ah, in that case the i we have already might have to be called i64 instead 02:20
i added those for devirtualization purposes for the jit, but they are also useful in deserialization code
MasterDuke not sure i follow? 02:22
timo at least i think that's why they exist? these shortcuts to directly get the repr functions from "inside" of the VMArray repr 02:25
ok i think i misremembered. this is about vmarray_at_pos_int64 and friends, which you get via MVM_VMArray_find_fast_impl_for_jit 02:26
that's something else
Geth MoarVM: MasterDuke17++ created pull request #1914:
Add type specialized VMArray atpos implementations		 03:09
timo MVM_repr_at_pos_s and MVM_repr_at_pos_o don't seem to check if the slot type is right 04:00
oh the check is in the target function 04:01
randomly, value->u64 = (MVMint64)body->slots.u64[body->start + real_index]; doesn't seem right? in terms of the cast that it uses? do we want to have the sign extension implications this has? 04:05
timo wingolog.org/archives/2024/10/03/p...ng-barrier hmm. 17:19
lizmat wonder what jnthn would have to say about that :-) 19:47
patrickb There is no way for me to make changes to or call internal libuv functions from moar, right? 22:42
Starting and managing a PTY child process on Windows is pretty annoying. Looking at what libuv does there means it's more than a few hundred lines of code only to start up the process let alone manage the lifetime. 22:43
patrickb If I could somehow manage to use the libuv machinery would help loads. But we want to keep working with a system libuv. 22:45
How bad would it be to try to call libuv internal functions? 22:46
lizmat patrickb: if you can make it work by using libuv internal functions, wouldn't it make more sense to create a public function in libuv that would do that ? 23:12
aka, contribute upstream ?
ugexe github.com/libuv/libuv/issues/2640 23:33

Powered by Cro and the Raku® Programming Language.

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

Thank you!