github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
brrt good * 09:36
nwc10 good *, brrt 09:37
jnthn o/ 09:38
brrt ohai nwc10, jnthn 09:39
MasterDuke ahoy. i'll throw out this gist with some segvs to see if i can get a bite gist.github.com/MasterDuke17/df204...218ece6c72 (why the nautical/fishing themed message? ...no idea) 09:40
it's interesting behavior with the sample code. if executed code is `perl -E 'while(1) { say "y" x 100 }'`, sometimes there's a little pause before the first line is printed, then two or three lines, then a long pause, etc. sometime it starts printing right away 10:04
but if it's `perl -E 'for(1..100_000) { say "y" x 100 }'`, it seems to always start printing right away and just keeps printing until the output ends with no pauses 10:05
and some of these long pauses are tens of seconds 10:06
MasterDuke timotimo: `error loading heap snapshotUnhandled exception in code scheduled on thread 7Malformed UTF-8 near bytes 61 c3 00 in submethod BUILD at /home/dan/Source/perl6/install/share/perl6/site/sources/BE7D3EE380568657EBC1780EA1C0BBDFC91FA530 (App::MoarVM::HeapAnalyzer::Model) line 429` 10:22
hm, do i need to be on some branch of moarperf? or wait, use your fork of App::MoarVM::HeapAnalyzer? 10:23
MasterDuke timotimo: got it working by pointing at your fork on the nqp-op-make-things-faster-or-something-like-this branch 10:42
Geth MoarVM: fc092556b9 | 0racle++ (committed using GitHub Web editor) | src/core/interp.c
Declare loop var before loop

Fixes broken builds on older versions of GCC, resolves #1309.
11:49
MoarVM: b5bb4f8d16 | (Patrick Böker)++ (committed using GitHub Web editor) | src/core/interp.c
Merge pull request #1315 from 0racle/patch-1

Fix build on older GCCs
linkable6 MOARVM#1309 [closed]: github.com/MoarVM/MoarVM/issues/1309 Make fails on older compiler
MasterDuke huh. i added `MVMuint64 i = 0;` before this loop github.com/MoarVM/MoarVM/blob/mast...#L417-L420 and `i++;` inside, and `fprintf(stderr, "%lu tags seen in add_frame_roots\n", i);` after. 12:53
when running the example code i've been playing with, i get stuff like `139658176961344 tags seen in add_frame_roots` and that 2046 times! 12:54
MasterDuke that seems less than optimal 12:54
nine isn't MVMuint64 %lld? 12:57
MasterDuke nope. `warning: format ‘%lld’ expects argument of type ‘long long int’, but argument 3 has type ‘MVMuint64’ {aka ‘long unsigned int’} [-Wformat=]` 12:58
nine I can never keep those apart 12:59
MasterDuke well, i thank you for turning on all those warnings, the compiler always corrects me if i get it wrong 13:00
nine :)
MasterDuke also, github.com/MoarVM/MoarVM/blob/mast...tion.c#L19 MVM_mallocs and sticks it into `foo->continuation_tags`, but i never see `foo->continuation_tags` freed 13:02
jnthn MasterDuke: It's done in frames.c, I think, but I'd not spend time on it...continuation_tags are gone in new-disp 13:03
MasterDuke ah 13:04
then this whole example might look different?
jnthn Well, there are still continuation tags, just they are stored as a callstack record 13:05
nine MasterDuke: clear_tag in src/core/continuation.c
MasterDuke oh, and whoops, freed in MVM_continuation_free_tags (very end of continuation.c)
MasterDuke jnthn: so there could still be a huge number of them? 13:06
oh hm. i might have compiled with --optimize=0. wonder if that makes a difference 13:08
jnthn Yes, the values are at least 70% junk without --optimize=0 in my experience... 13:09
Oh, wonder if you meant without :)
MasterDuke yeah. seeing if i get the same numbers with vs without 13:10
jnthn If I'm looking at stuff in gdb, I don't trust it for anything more than the stack trace without --optimize=0
If it's printf then they're reliable either way
MasterDuke those were numbers from printf
huh. now i'm not seeing those large numbers at all 13:13
MasterDuke arg. there were consistently reproducible before. but now i've recompiled with optimization off and on and MVM_GC_DEBUG off and on and i just get `1 tags seen` 13:15
nine as it should be 13:21
MasterDuke nor can i repro the long pauses. ugh 13:30
whoops, no, those are still there. i was running the `for(1..100_000)` version which doesn't have them 13:34
ok, so it seems the number of continuation_tags was a red herring. but then why still so much time spent in MVM_gc_root_add_frame_roots_to_worklist and MVM_gc_root_add_frame_registers_to_worklist? and why the long pauses? 14:07
that's only in the `while(1)` version. for the `for(1..100_000)` version the top according to perf is check_reg and MVM_get_lexical_by_name 14:11
~43k times for $*PROMISE and $*OUT, ~20k times for $*LOCK-ASYNC-RECURSION-LIST and $?CLASS 14:14
MasterDuke interesting. 20k $*PROMISE and $*OUT from the lexical_names hash, 20k times from lexical_names_list 14:20
of the times it hit the hash, 24566 times num_lexicals was 7, 24016 it was 8, 18477 it was 9. bit of a drop to the next; 6781 it was 12, 5350 it was 6 14:25
MasterDuke some rough benchmarking with my example code suggests that increasing the value of lexicals to put in a list before turning into a hash up to 10 doesn't really make the list case any slower 15:24
here github.com/MoarVM/MoarVM/blob/mast...ode.c#L664
and it's slightly faster than the hash case. 350 vs 434 15:28
those are average differences between telemetry intervals 15:29