|
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. |
|||
|
01:23
MasterDuke joined
01:41
MasterDuke left
01:43
MasterDuke joined
|
|||
| 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 | |
|
03:20
MasterDuke left
|
|||
| 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 | ||
|
09:39
gfldex left
09:40
gfldex joined
09:58
sena_kun joined
11:16
lizmat left,
lizmat_ left
11:17
lizmat joined
11:26
Altai-man joined
11:29
sena_kun left
12:01
Geth joined
|
|||
| 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 | |
|
21:15
Altai-man left
21:16
Altai-man joined
|
|||
| 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 | ||
|
22:44
Altai-man left
|
|||
| 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 | |