|
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 |
15:59 | |
| 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 | |||