|
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 |
09:33 | |
| 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 |
11:13 | ||
| 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 |
15:41 | |
| 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. |
16:07 | ||
| 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 |
16:31 | |
| 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 | |
| aww | |||
|
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" |
18:59 | |
| 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 |
20:52 | |
|
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 | |
| *ctypes | |||
| japhb | m: say 12.9/1.47 | ||
| camelia | 8.77551 | ||
| japhb | If the above is a fair comparison, that's awesome! | 22:47 | |
| nine++ | |||
| 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 | |