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:00 reportable6 left 00:03 reportable6 joined 00:17 timo left 00:18 timo joined 00:27 timo left 00:28 timo joined 01:20 MasterDuke joined
MasterDuke timo: i haven't looked at your commits closely yet, think they conflict with github.com/MoarVM/MoarVM/pull/1746 or complement it? 01:45
04:18 evalable6 left, linkable6 left 04:19 linkable6 joined, evalable6 joined 06:00 lizmat left, vrurg left, rypervenche left, gfldex left, xiaomiao left, JRaspass left, reportable6 left, gfldex joined, rypervenche joined, xiaomiao joined, JRaspass joined 06:01 lizmat joined, vrurg joined, rypervenche left, rypervenche joined, reportable6 joined 07:24 squashable6 left 07:26 squashable6 joined 09:57 quotable6 left, reportable6 left, squashable6 left, bloatable6 left, bisectable6 left, linkable6 left, greppable6 left, statisfiable6 left, unicodable6 left, tellable6 left, evalable6 left, sourceable6 left, releasable6 left, shareable6 left, benchable6 left, notable6 left, nativecallable6 left, coverable6 left, committable6 left, committable6 joined, squashable6 joined, notable6 joined, statisfiable6 joined 09:58 linkable6 joined, bloatable6 joined, unicodable6 joined, releasable6 joined, nativecallable6 joined, coverable6 joined 09:59 evalable6 joined, benchable6 joined, greppable6 joined, shareable6 joined, tellable6 joined, bisectable6 joined, reportable6 joined, sourceable6 joined 10:00 quotable6 joined 11:37 linkable6 left 11:39 linkable6 joined 12:00 reportable6 left 12:02 reportable6 joined
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2023/05/29/2023-...t-rolling/ 13:23
13:59 linkable6 left, evalable6 left, linkable6 joined 14:01 evalable6 joined
timo just a tiny bit of conflict i thin, mostly complement 14:46
Geth MoarVM/callercode_in_inline_is_just_curcode: d42ed3e275 | (Timo Paulssen)++ | src/spesh/optimize.c
Also note rewrite_callercode relies on no nested inlines
MoarVM/main: 3b4d55a081 | (Timo Paulssen)++ (committed by timo) | 3 files
callercode no longer prevents inlining

assuming that an inliner's curcode is what an inlinee's callercode is supposed to return, we can just turn callercode into curcode when inlining. There is already a guard that prevents an inlining block from immediately inlining another so we can't for example by accident skip over one level of ... (48 more lines)
MoarVM/main: b9df871d1f | (Timo Paulssen)++ (committed by timo) | src/spesh/optimize.c
Also note rewrite_callercode relies on no nested inlines
lizmat ok, shall I bump NQP/Rakudo ? 16:03
timo ^^ ?
timo you can if you like, it's not urgent i think, but of course it always helps to have the code in the hands of everyone who build the bleeding edge 16:10
lizmat my feelings exactly :-) 16:11
timo are we able to run the regular profiler on core setting compilation at the moment? :D 16:13
lizmat I don't think so
generally anything running more than a few seconds, creates too much data 16:14
timo i tried --profile-compile=coresettingprofile.sql and it didn't crash but there's also no file 16:23
it could be at some point we changed whether Raku's HLL Symbol @END_PHASERS is defined or not at the position where run_profiled is used for profile-compile, and maybe the end phasers don't actually run in this case? 16:37
i'm digging into it in any case
16:38 linkable6 left, evalable6 left, linkable6 joined
lizmat ++timo 16:38
timo yeah, the dump_profile_data never runs after it got pushed into the end phasers 16:40
16:41 evalable6 joined
timo we could get a flag that makes mvm not track allocations, which would reduce the size of profiling data 16:45
lizmat fwiw, I'm usually less interested in allocation info 16:47
not seeing much difference in speed in core setting building or spectests 16:52
timo sad 16:59
i still get a crash, let's see if i can figure it out 17:16
oh it's a stack overflow from the dump call graph node loop 17:18
i could only get the frame size for the dump call graph node loop function from 144 or so to 112 bytes 17:48
74k stack frames, whew ... 17:51
18:00 reportable6 left 18:03 reportable6 joined
timo something Very broke when we added return_u but forgot to tell the profiler to instrument that with "returned from frame" instruction 18:14
with spesh's inlining disabled, the output can actually be written 18:58
i think i will really need to go through the code again and find that nasty situation where IIRC optimizing a throw to a goto would cause trouble 18:59
MasterDuke timo: i think my PR fixes a segfault in the profiler 19:04
timo maybe it does the exact thing i just menitoned 19:06
i mean adding return_u to instrument.c 19:08
MasterDuke github.com/MoarVM/MoarVM/pull/1746...7c4f8fde2d yep, i thought that sounded familiar 19:26
i need to address nine++'s comments and finish that one up