travis-ci MoarVM build failed. Samantha McVey 'Merge pull request #781 from samcv/ucd-critic 00:30
travis-ci.org/MoarVM/MoarVM/builds/330705279 github.com/MoarVM/MoarVM/compare/a...4869e37bcb
MasterDuke is there any benefit to creating templates that just call c functions for the expr jit? or is the fall(back|through) to the old jit just as efficient? 19:22
timotimo depends on what the next step in the bb would have been 19:53
MasterDuke would it ever be less efficient? 19:55
timotimo shouldn't be
jnthn Possibly the expr JIT can avoid some dupe loads
timotimo that's true
jnthn So could come out better
timotimo it might also be able to avoid stores :)
MasterDuke sounds like it's worth it to go to the effort of creating templates for all the ops then? 19:57
timotimo just make sure to prioritize working on the ones that are more common 19:58
MasterDuke sure 19:59
timotimo does the "parse jitgraph" script help any? 20:00
MasterDuke however; the most common, sp_findmeth, might be out of my paygrade right now. it's been ~10 years since i've really read assembly and ~15 years since i've written any 20:01
haven't really looked at the output yet 20:02
but i think it's saying all were skipped 20:03
timotimo i'd rather read the C implementation in interp.c than try to go from emit.dasc to a template jit thingie
MasterDuke because of surprising lines
timotimo right, that's unsurprising :)
MasterDuke but wouldn't what's in emit.dasc be optimized? 20:04
timotimo i'd expect it to be 1:1 translated from interp.c
MasterDuke or you're saying the expr jit should do a better job optimizing a conversion of the c implementation than a conversion of the asm? 20:05
hm, the comments for sp_findmeth in both interp.c and emit.dasc look similar 20:07
timotimo the wins come from the template jit being able to look at multiple ops in a row; from C to emit.dasc is mostly 1:1 translations because the lego jit doesn't have much additional information 20:10
MasterDuke ah 20:12
timotimo it can do better than interp.c if a type is known and a reprop is called, like push_o for example. either it has to look up an object's STable, find its REPR, and grab the function pointer from in there 20:42
but the jit can put the function pointer right into the compiled assembly code
timotimo jnthn: looking into beefing up udp receiving; is it okay to be ignoring UV_UDP_PARTIAL flags if they get set? 22:40
* Indicates message was truncated because read buffer was too small. The 22:41
* remainder was discarded by the OS. Used in uv_udp_recv_cb.
timotimo though i don't think we control buffer size at all from our end? 22:42
jnthn If I remember correctly, this is about the size of the read buffer we pass to libuv
libuv drops bytes on the floor if that's too short
But I think (though please check it) that our buffer size is the maxium packet size anyway 22:43
geekosaur um, the OS UDP interface does have such a flag
timotimo doesn't libuv decide what size it wants and calls on_alloc from us?
geekosaur uf you tell it to recv() or recvfrom() to a buffer that is too small for the packet received,it sets the partial flag on the result
jnthn It passes a suggested size, which we can ignore or respect
geekosaur: That's probably why libuv works that way, then :) 22:44
timotimo we have no way to see if an incoming packet is too big for us?
geekosaur nope. UDP is kinda dumb that way
jnthn geekosaur: Is there a maximum possible size it could be, though?
(Or perhaps a way to find that out?) 22:45
geekosaur there is, but it is system and to some extent network dependent.
timotimo MTU is the upper limit, right?
geekosaur and that last part basically means you can't find out
jnthn If I'm reading en.wikipedia.org/wiki/User_Datagra..._structure right then it's 2 bytes for the size field in the packet 22:46
geekosaur it us, but note that (a) path MTU discovery is not really a thing on UDP, because it requires retransmits (b) the max MTU is the lowest max MTU of the traversed network nodes
jnthn Which would imply 64KB is the most one could expect
geekosaur and (c) there is n guarantee that two packets fromt he same source to the same destination follow the same path 22:47
timotimo you can also send UDP over a unix domain socket, right?
does that give us practically infinite mtu?
geekosaur you can, but the max MTU will depend on kernel buffers for unix domain sockets. which often are the same as pipe buffers 22:48
timotimo fair enough
int uv_recv_buffer_size(uv_handle_t* handle, int* value)¶ 22:50
maybe this is how we can change the buffer size 22:51
lizmat from former work, I know that UDP packets that get too long, may also be dropped completely by routers 22:57
so it's usually in the interest of the sender to keep packages as small as possible
timotimo true, there's no ICMP fragmentation reports for udp 22:58
because if you're using UDP, you're fine with data getting lost
i wonder if holding on to the last sockaddr so as not to rebuild string after string after string of the same ip address over and over again 23:01
(and also an Int object for the port)
lizmat and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2018/01/22/...-optimism/ 23:14
timotimo i'm slightly confused. the callback that (i believe) gets called when a udp message comes in already has parameters for 2x port and 2x hostname, but none of them got passed by the udp impl so far and why doesn't that explode violently? %) 23:19
(that was in fact the listener supply, not the message supply) 23:25
timotimo are optional parameters in our callbacks for asyncreadbytes and friends costly at all i wonder ... 23:53
jnthn Not terribly 23:54
timotimo i don't have a design for the API of receiving udp messages including the host and port, but it looks like the plumbing around everything will make returning proper objects a bit annoying 23:57
i.e. the encoded supply just grabs the emitted things from the supply and calls .encode on it to get a string instead of the buf

Powered by Cro and the Raku® Programming Language.

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

Thank you!