| IRC logs at
Set by AlexDaniel on 12 June 2018.
00:54 Altai-man_ joined 00:57 sena_kun left 02:11 harrow left 02:25 harrow joined 02:55 sena_kun joined 02:57 Altai-man_ left 03:09 elcaro left 04:54 Altai-man_ joined 04:56 sena_kun left 06:55 sena_kun joined 06:57 Altai-man_ left 07:40 squashable6 left 07:43 squashable6 joined 07:49 zakharyas joined 07:50 Geth left 07:58 Geth joined 08:54 Altai-man_ joined 08:57 sena_kun left 09:24 squashable6 left 09:26 squashable6 joined 09:33 brrt joined 09:35 leont joined
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 (why the nautical/fishing themed message? 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
10:13 brrt left
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
10:30 MasterDuke left 10:37 brrt joined 10:38 MasterDuke joined
MasterDuke timotimo: got it working by pointing at your fork on the nqp-op-make-things-faster-or-something-like-this branch 10:42
10:55 sena_kun joined 10:56 Altai-man_ left 11:00 squashable6 left 11:04 squashable6 joined 11:24 zakharyas left 11:47 patrickb joined
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.
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]: Make fails on older compiler
12:30 brrt left
MasterDuke huh. i added `MVMuint64 i = 0;` before this loop 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
12:54 Altai-man_ joined
MasterDuke that seems less than optimal 12:54
12:57 sena_kun left
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, 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)
13:06 brrt joined
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
13:14 zakharyas joined
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
14:20 patrickb left
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
14:28 brrt left 14:55 sena_kun joined 14:57 Altai-man_ left
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
and it's slightly faster than the hash case. 350 vs 434 15:28
those are average differences between telemetry intervals 15:29
15:58 leont_ joined 16:08 squashable6 left 16:10 squashable6 joined 16:30 MasterDuke left 16:54 Altai-man_ joined 16:57 sena_kun left 17:33 Kaiepi left 17:36 Kaiepi joined 18:05 MasterDuke joined 18:13 zakharyas left 18:55 sena_kun joined 18:57 Altai-man_ left 19:11 zakharyas joined 20:08 raku-bridge3 joined, raku-bridge3 left, raku-bridge3 joined 20:09 lizmat_ joined 20:11 Kaeipi joined 20:14 tbrowder__ joined 20:18 Kaiepi left, tbrowder left, lizmat left, raku-bridge left, tbrowder__ is now known as tbrowder 20:19 raku-bridge3 is now known as raku-bridge 20:38 kawaii left 20:54 Altai-man_ joined 20:56 sena_kun left 20:57 zakharyas left 21:40 kawaii joined 22:32 lizmat_ is now known as lizmat 22:55 sena_kun joined 22:56 Altai-man_ left 23:09 MasterDuke left 23:51 leont_ left, leont left