|
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. |
|||
| guifa | Had to take a quick break for dinner (home with family) | 01:05 | |
| timo | maintaining your corporeal form comes before doing open source contributions :) | 01:15 | |
| guifa | hmmm | 01:41 | |
| whatever I did I managed to get Raku to launch and immediately get a sigkill lol | |||
| timo | you restored the ops to what they were before, right? you may need to do a bit more aggressive "make clean" than you might be used to | 01:44 | |
|
02:13
harrow left
|
|||
| guifa | phew, I did a fully fresh rebuild in a new location and now it's running. Time to try readding that syscall entry | 02:19 | |
| No MoarVM syscall with name 'async_socket_udp' | 02:28 | ||
| d'oh, it was async-socket-udp | |||
| see, I can be just as bad :) | |||
| Argument 0 to MoarVM syscall 'async-socket-udp' has repr ConcBlockingQueue, but should be MVMOSHandle. | 02:29 | ||
| $!.author++ | |||
|
02:37
harrow joined
|
|||
| guifa | SWEET | 02:41 | |
| call successfully transfered | |||
| timo++ for your amazing hand holding today | |||
| timo | :+1: | 02:43 | |
| š | |||
| guifa | now to reshoehorn in multicast | 02:47 | |
| biggest Q is if I can actually access the handle in subsequent calls. I think I can | 03:06 | ||
| close op obvs needs access to it too | 03:07 | ||
| timo | the os handles have a little bit of extra indirection through a few structs, i think they are called "somethingable", like closable and readable and such | 03:11 | |
| i don't think it'll be necessary to have something like multicastable because there's really not many kinds of handles that support that? | 03:12 | ||
| so virtualising the implementation there may not be necessary | |||
| guifa | oh I intended to do one syscall that just forwards the call to the current one opening up the handle | 04:12 | |
| and then a second sys call that adds the multicast listeners | |||
| That way, the only thing I'll need to do differently is check for the multicast flag in the original routine so it doesn't bomb on address in use. | 04:13 | ||
| The Raku side will handle converting bind-udp($multicast-address, $port), into effectively bind-udp('0.0.0.0', $port).multicast-subscribe($multicast-address) | 04:14 | ||
| timo | OK | 04:23 | |
| guifa | maybe I end up hating the design and go back to a monolith later. TIMTOWTDI :D | 04:26 | |
| timo | it's normally not a problem for the internals to be slightly or quite different from what the end-user-facing API is. just doing whatever is most convenient for now should be fine | 04:31 | |
| guifa | true. this is just perfectionist me thinking. Do we consider syscalls to have the same level of semi-permanance that op calls do? | 04:33 | |
| timo | you mean in terms of like API/ABI stability? | 04:35 | |
| i think of them as less permanent | 04:36 | ||
| they don't cause bytecode files to become literally unreadable if their definitions change from one version to another | |||
| guifa | yeah, basically what was going through my head | 04:37 | |
| I'm thinking for now, the fastest way to a workable solution is to duplicate the MVM_io_socket_udp_async . One stays exactly what we have now and will be called for uni/broadcast (I'll also add a higher level check to reject broadcast for IPv6 since it doesn't exist) | 04:39 | ||
| the other version will become MVM_io_socket_udp_async_multicast and be the test code I had up and running a while back | 04:40 | ||
| the syscall will simply capture the flag and call the appropriate routine | |||
| from a code reuse standpoint I hate it though :) | 04:41 | ||
|
10:26
sena_kun joined
10:29
sena_kun left
10:31
sena_kun joined
13:41
guifa left
|
|||
| ab5tract | guifa++ # for riding the rabbit hole rocketship on multicast support :) | 14:51 | |
|
18:37
committable6 left,
shareable6 left,
quotable6 left,
linkable6 left,
benchable6 left,
bisectable6 left,
releasable6 left,
notable6 left,
evalable6 left,
unicodable6 left
18:39
shareable6 joined
18:40
bloatable6 joined,
greppable6 joined,
unicodable6 joined,
linkable6 joined,
benchable6 joined,
releasable6 joined,
committable6 joined,
bloatable6 left,
committable6 left,
shareable6 left,
greppable6 left,
unicodable6 left,
benchable6 left,
releasable6 left,
linkable6 left
18:43
shareable6 joined,
quotable6 joined,
coverable6 joined,
benchable6 joined,
greppable6 joined
18:44
sourceable6 joined,
notable6 joined,
releasable6 joined,
evalable6 joined,
tellable6 joined,
unicodable6 joined
18:45
bloatable6 joined,
linkable6 joined,
committable6 joined,
nativecallable6 joined,
bisectable6 joined
20:03
MasterDuke joined
|
|||
| MasterDuke | discovered something interesting, the slow moarvm compile time on this mb air is mostly because of the computed goto in interp.c | 20:04 | |
| if I disable compiling as a computed goto the total compile time halves from ~60s to ~30s | 20:05 | ||
| it appears to be a known problem in clang. I believe it was fixed at some point (at least I don't see it on my linux x86 desktop with clang 18, while this laptop has clang 16) | 20:07 | ||
| not using the computed goto does seem to slightly slow down moarvm. the total time for a rakudo build goes from ~95s to ~100s | 20:51 | ||
| timo | yeah, computed goto should have multiple benefits | 20:52 | |
| makes the branch predictor a bit happier | |||
| MasterDuke | yeah, I figured, but had no idea what the actual amount of change would be. now I'm curious to try it on my desktop | 20:56 | |
| approx no difference (using gcc). ~1:35 with, ~1:37 without | 21:10 | ||
| and I had incorrect times for the laptop, it was ~1:10 with, ~1:14 without | 21:11 | ||
| (using clang), ~1:39 with, ~1:43 without | 21:24 | ||
| these were single runs though, so not very statistically significant | 21:25 | ||
|
22:44
MasterDuke left
22:52
guifa joined
23:32
sena_kun left
23:49
guifa left
|
|||