|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm 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 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 | ||
|
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. |
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 | ||
|
12:30
brrt left
|
|||
| 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 | ||
|
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, 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) | ||
|
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 | |
| 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 | ||
|
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
|
|||