| IRC logs at
Set by AlexDaniel on 12 June 2018.
01:09 linkable6 left 01:11 linkable6 joined 01:26 squashable6 left, linkable6 left 01:27 linkable6 joined 01:29 squashable6 joined
vrurg .tell nine I have solved it. 01:37
tellable6 vrurg, I'll pass your message to nine
01:44 lucasb left 03:00 leont left 04:12 japhb left 04:18 japhb joined 05:02 samcv left 05:03 samcv joined 07:28 Geth joined 07:49 domidumont joined
Geth MoarVM: e316dc34e2 | (Jonathan Worthington)++ | src/profiler/instrument.c
Fix confused profiler output in multi-threaded app

At some point we started to assign indexes to static frames and then look them up, so as to cheapen GC of the profiler data. Unfortunately, this introduced a bug when we recorded profiles in multi-threaded programs: the wrong thread context was used to resolve those indices when dumping the profile results, which in turn led to the indices resolving to the wrong static frame. Thus the output of profiles involving multiple threads would often end up garbled.
MoarVM: 4ae157c33d | niner++ (committed using GitHub Web editor) | src/profiler/instrument.c
Merge pull request #1441 from MoarVM/fix-profiler-thread-bug

Fix confused profiler output in multi-threaded app
nine jnthn: the sad thing about this ^^^ is that the compiler could have warned us about the unused argument, but we don't let it
tellable6 2021-02-24T01:37:32Z #moarvm <vrurg> nine I have solved it.
MasterDuke because of all the false warnings we'd get from unused `tc`s? 08:36
nine yes 08:37
Those and other args, mostly in 6model functions
08:40 leont joined
nine That's some 8791 warnings :D 08:40
MasterDuke ha 08:44
nwc10 I was going to say "don't scare leont with things like that" but I on reflection think he's big/battle scarred enough to take it 08:46
leont Heheh
MasterDuke only 177 unique if you exclude src/6model/*  and any warnings for 'tc' 08:54
a couple of those i checked are false positives (i.e., used in an #ifdef or #define), but some seem legit (e.g., 'unwind' here 09:16
09:16 zakharyas joined 09:26 Raeiyhan joined
Raeiyhan hello 09:28
would like to register for rvm
nine rvm? 09:31
Raeiyhan ruby virtual machine 09:37
MasterDuke this channel is about the moar virtual machine (which is for running raku code, not ruby) 09:39
Raeiyhan ok 09:40
10:08 MasterDuke left 10:22 MasterDuke joined 10:33 Raeiyhan left 11:29 MasterDuke left 11:30 MasterDuke joined 11:44 sena_kun left 12:34 zakharyas left 12:36 sena_kun joined 12:42 sxmx left 12:55 sxmx joined
MasterDuke well, it looks like the reason my remove_spesh_candidate branch is slower is that it's doing massively more temporary allocations (according to heaptrack), caused by allocating more frames 13:53
it's calling allocate_frame 470440 more times. 677015 times fewer for non heap-allocated, but 1147455 times more for heap-allocated 14:11
14:29 brrt joined
MasterDuke i don't understand why these heaptrack profiles are so very different. sure there are more frames allocated on my branch, but the difference doesn't seem enough to explain these profiles (and perf shows something similar) 15:06
lizmat is it ok to bump MOarVM to get the profiler fixes ? 15:07
nine yes
lizmat ah,,.. I guess not, until sena_kun has done a point release
sena_kun lizmat, yes
lizmat ...
sena_kun: if you say yes again, I will bump :-) 15:09
sena_kun I am doing one out of branch today, so can be bumped.
lizmat okidoki
15:34 lizmat left 15:48 lizmat joined 16:07 brrt left 16:25 Geth left 17:58 domidumont left 18:53 camelia left 19:13 brrt joined 19:19 camelia joined 20:04 camelia left 20:07 camelia joined 20:09 camelia left 20:10 camelia joined 20:14 sortiz joined 20:18 camelia left 20:24 camelia joined 21:11 zakharyas joined 21:27 brrt left 22:10 sena_kun left 22:11 sena_kun joined 22:23 sxmx left 22:25 sxmx joined 22:32 zakharyas left 23:49 MasterDuke left