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.
00:02 reportable6 left 00:03 reportable6 joined 00:07 patrickb left 01:16 [Coke] left 01:20 [Coke] joined 03:03 frost joined 05:02 benchable6 left, nativecallable6 left, releasable6 left, reportable6 left, greppable6 left, committable6 left, shareable6 left, notable6 left, unicodable6 left, quotable6 left, coverable6 left, bloatable6 left, bisectable6 left, squashable6 left, statisfiable6 left, evalable6 left, sourceable6 left, tellable6 left, linkable6 left 05:03 bisectable6 joined, nativecallable6 joined, tellable6 joined, committable6 joined 05:04 notable6 joined, squashable6 joined, sourceable6 joined, statisfiable6 joined 05:05 bloatable6 joined, linkable6 joined, benchable6 joined, evalable6 joined 05:06 quotable6 joined 06:03 unicodable6 joined 06:04 reportable6 joined 06:05 coverable6 joined 07:03 shareable6 joined 07:04 ilogger2 left, jnthnwrthngtn left, jnthnwrthngtn joined, ilogger2 joined 08:05 greppable6 joined
nine timo: none at all. Apparently we didn't get any output at all, but also no error. Could it be that we don't manage to flush STDOUT on exit on Mac OS? 08:49
Geth MoarVM/new-disp-nativecall-libffi: 32 commits pushed by (Stefan Seifert)++, (Nicholas Clark)++
review: github.com/MoarVM/MoarVM/compare/d...b602a6e46c
dogbert17 nine: the bug you fixed, was that the occurs once in 10000 runs thingie? 09:42
10:03 releasable6 joined
nine dogbert17: no, I wish that one was as easy. The one I fixed is an Inline::Perl5 test failure that popped up after the new-special-return merge 10:47
dogbert17 I have a couple of bugs that are probably easier to deal with ... famous last words :) 10:48
jnthnwrthngtn moarning o/ 10:49
dogbert17 good morning jnthnwrthngtn, how was the curry yeasterday?
10:50 discord-raku-bot left 10:51 discord-raku-bot joined
jnthnwrthngtn dogbert17: Delicious, although I probably ate too much of it. :) 10:53
dogbert17 so Prague has some excellent Indian restaurants then it seems
lizmat the only place where /me has had excellent Indian food in Prague, was at jnthnwrthngtn's place :-) 10:58
jnthnwrthngtn nine: Everything fixed up in the nativecall PR(s)? 11:08
nine jnthnwrthngtn: not yet. alloca and the comment about optimizer are still open 11:12
Geth MoarVM: 8a91bf8eb0 | (Stefan Seifert)++ | src/core/interp.c
Fix JITed return from nested runloops

When a callback frame is completely JIT compiled, including a return_o, we did not notice that it's time to exit the runloop. MVM_callstack_unwind_frame will already have set tc->cur_frame to the frame that called the native routine that in turn ran the callback and returned 0 to signal that the runloop should end. This 0 got forwarded by MVM_frame_try_return but JIT compiled code does not ... (8 more lines)
MoarVM: 64f90d4652 | niner++ (committed using GitHub Web editor) | src/core/interp.c
Merge pull request #1601 from MoarVM/fix_jited_return_from_native_runloops

Fix JITed return from nested runloops
lizmat bump time? 11:14
11:38 Altai-man joined
lizmat takes that as a yes 11:48
nine It's not a life changing decision anyway :)
lizmat indeed, but it would unbreak the test-t Inline::Perl5 tests, no ? 11:49
nine No, those are fixed in Inline::Perl5 11:50
lizmat ah, but I didn't see that bumped?
nine Indeed. I haven't done a new release yet
lizmat ok, just checking :-) 11:51
12:02 reportable6 left 12:05 reportable6 joined 13:06 Kaipi left 13:07 Kaiepi joined 13:34 frost left
[Coke] is playing Deus Ex: Mankind Divided at the moment, and is doing all the Prague missions. I wonder if I can see anyone's apartment from here... 15:17
timo yesterday i saw someone from canada recount when in a movie the characters were shown running towards the exact movie theater that person was sitting in to watch the movie in question 15:22
apparently they engage in an activity with their friends where they try to spot their apartment complex / building in movies, since filming around there seems to be common for some reason 15:23
www.youtube.com/watch?v=aimZkOFqRPk - a five minute clip about "Maple Cringe" 15:24
correction: they film lots of stuff in that exact building? 15:25
[Coke] notes that "at the moment" means as time permits, not right this actual moment. :) 15:32
timo of course
that's fair 15:33
Geth MoarVM/new-disp-nativecall-libffi: 32 commits pushed by (Stefan Seifert)++, (Nicholas Clark)++
review: github.com/MoarVM/MoarVM/compare/e...d35f81dbc5
MoarVM/new-disp-nativecall-libffi: dcefde605d | (Stefan Seifert)++ | 2 files
Stack allocate args, free_strs and free_rws lists in native calls

Makes it faster and leaks less memory in case of exceptions. Risk of stack overflow is minimal because if you pass that many arguments, you could overflow the stack with a normal call as well.
timo we were leaking data in case of exceptions? :D 16:27
Geth MoarVM/new-disp-nativecall-libffi: 33 commits pushed by (Stefan Seifert)++, (Nicholas Clark)++
review: github.com/MoarVM/MoarVM/compare/d...f497c92d77
nine timo: actually we still are. The memory we allocate for rw args 16:34
We don't if the native calls are JIT compiled though 16:35
timo that's at least something 16:36
nine So, all review comments for new-disp-nativecall are addressed and the branches are rebased
timo oh yeah! SDL_SetRenderDrawColor($render, 0xff, 0xff, 0xff, 0x00) now has four const_i64 in front of the runnativecall op 18:00
the getspeshslot ops for the Int objects are still there, because i imagine deopt requirements
18:02 reportable6 left 18:03 reportable6 joined
timo and runnativecall is also jitted to be basically just a regular-old call, if possible? 18:04
jnthnwrthngtn I believe so, yes :) 18:06
I'm curious how fast this is :)
I'd imagine pretty decent
timo this call only happens once per frame, and this runs at below 40fps due to what else it's doing :D
jnthnwrthngtn No, I meant how fast C calls are now vs. before :) 18:07
timo oh, of course
needs a good benchmark of some sort
jnthnwrthngtn nine: github.com/rakudo/rakudo/pull/4629...f4ad8f6ef6 says it moves the EVAL to BEGIN time but I don't see how it achieves that? 18:18
home time & 18:20
18:23 Altai-man left
timo sp_runnativecall_i r6(3), r36(0), liti64(101212352), r37(0), r32(1), r35(0), r6(2) # [048] BAIL: op <sp_runnativecall_i> (type of arg 2 (1) NYI) 18:32
18:40 linkable6 left 18:41 linkable6 joined
timo [Delayed temps to release: 9(0), 10(0), 11(0), 12(0), 13(0), 14(0), 15(0), 16(0), 17(0))] 18:44
sp_runnativecall_i r18(0), r11(0), liti64(72045936), r12(0), r13(0), r14(0), r15(0), r16(0), r17(0)
^- implemented dumping of the release regs annotation
Geth MoarVM: 10e5344c3f | (Timo Paulssen)++ | src/spesh/dump.c
show annotation for delayed temps in spesh log

rather than just "unknown"
nine jnthnwrthngtn: oh darn....seems like I lost a BEGIN when trying around. And adding it breaks in far too interesting ways like "Premature heredoc consumption" or "When invoking 121 '', provided outer frame 0x4834d80 (159 '') does not match expected static frame 0x4830580 (153 '')" 19:02
jnthnwrthngtn nine: OK, maybe we'll leave that opt for later then 19:18
nine I may have a solution: moving the code into NativeCall::Dispatcher and requiring that module conditionally 19:19
(in an EVAL)
or even without EVAL 19:20
Oh, that saves a LOT of time. 19:24
Pushed a better version
timo oh my 19:31
meanwhile i'm teaching runnativecode's jit compilation to handle CArray arguments
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2021/11/15/2021-...nce-again/ 19:32
timo the jitted code we end up with for four const_i64 in a row followed by a runnativecall is still rather long, it puts the constant ints into the moar-registers, then reads them back out 19:48
gist.github.com/timo/ff98e2f4cbcd4...e8dacd4984 - this is roughly what that looks like 19:52
nine timo: but, it already does? 19:54
timo how so?
i put the changes i made into the same gist so you can look-see 19:56
nine github.com/MoarVM/MoarVM/blob/new-...ph.c#L3807
Oh, sorry. CArray vs VMArray
Carry on :D
timo yep 19:57
is it ok to push that patch to nativecall-new-disp-libffi?
you may prefer a PR onto your PR :) 19:58
20:12 patrickb joined
nine just push :) 20:43
Geth MoarVM/new-disp-nativecall-libffi: 0746645817 | (Timo Paulssen)++ | 3 files
teach jit of runnativecall about CArray arguments
21:14 linkable6 left, evalable6 left 21:15 evalable6 joined 21:16 linkable6 joined 22:03 squashable6 left 22:04 squashable6 joined
jnthnwrthngtn m: say 1.47 / 2.55 22:14
camelia 0.576471
jnthnwrthngtn I got curious and measured 100 million calls to the C abs function via NativeCall (I figure it's a very cheap function, so this mostly measures native call overhead). 22:15
new-disp-nativecall does it in 58% of the time. That's quite a saving. :) 22:16
japhb Wow, impressive work! jnthnwrthngtn, did you test with libffi as well? Or is that only for supporting other OSen? 22:20
jnthnwrthngtn Impressive work on the part of nine++, that is. :) 22:27
Didn't try that but I doubt it makes much difference, given that dyncall or libffi are only used during warmup, and then we JIT the calls 22:28
japhb jnthnwrthngtn: Ah, makes sense. For some reason I thought there were still things that couldn't be JITted 22:34
jnthnwrthngtn There are, but my example wasn't one of them :) 22:38
japhb Heh, gotcha 22:45
jnthnwrthngtn For comparison, Python ctyles does it in 12.9s 22:46
japhb m: say 12.9/1.47
camelia 8.77551
japhb If the above is a fair comparison, that's awesome! 22:47
jnthnwrthngtn Ruby's ffi extension fares a bit better, at 5.9s 22:49
I dunno which are the "best" FFIs
Perl with FFI::Platypus is 10.4s 22:55
(Which is what is suggested to use when looking at the docs for the FFI module)
23:47 ggoebel joined
ggoebel jnthnwrthngtn: have you seen github.com/dyu/ffi-overhead 23:47