timotimo just a little "general" spesh log viewing shows we have a lot of objects from wvals that don't have a debug_name set. i'm *expecting* those are things that come from nqp, but i can't know until i try a fresh stage0 00:04
it could also be i'm missing some *HOW that should also get the setdebugtypename treatment
how about EnumHOW for example?
i can just look that up!
it could be the setdebugtypename thing wants to live in Perl6::Metamodel::Naming 00:06
instead of the ClassHOW where it currently resides
gist.github.com/timo/1693af31a1315a56cbf2 - some example output 00:14
i get much more outputs now that i also have it in nqp 00:21
+ wval r3(1), liti16(0), liti16(7) (P6opaque: Perl6::Actions+{HAS-decl-actions}) 00:22
+ wval r5(1), liti16(0), liti16(7) (P6opaque: Perl6::QGrammar+{q}+{postproc}+{postproc}+{startstop})
another data point about things: with a doubled multi dispatch cache i don't get the "without precompiled things, the find_best_dispatchee stuff gets everywhere" behavior any more 00:24
a stage0 update right now will up the stage0 size from 2593K to 2554K (+/- 11K rounding errors) 00:43
00:45 ggoebel16 joined
timotimo hm. our nqp code already goes through a fudger that looks out for #? stuff; maybe we could have a #?if stage2 so we don't have to bumb the stage0 every time we add new ops and want to use them inside nqp 00:45
though we may need an additional stage at the end if we have something like that 00:46
if we really want the code that compiles the nqp to be the code that compiled the nqp that compiles the code
02:00 mojca joined 02:24 vendethiel joined 02:48 ilbot3 joined 02:53 TimToady joined 03:20 mojca joined 03:35 geekosaur joined 03:39 cognominal joined 03:53 cognominal joined 07:02 domidumont joined 07:07 domidumont joined 07:09 FROGGS joined 08:28 zakharyas joined 09:58 cognominal joined 10:18 cognominal joined 11:08 cognominal joined 11:23 cognominal joined 11:54 cognominal joined 13:24 cognominal joined 13:29 ilbot3 joined 13:36 camelia joined
timotimo so far i've only considered the effect of making p6opaque smaller in its serialized form on the core setting, but maybe it'd be much more interesting for the stage0? 13:50
13:58 vendethiel joined 14:16 mojca joined 14:32 zakharyas joined
hoelzro I'm reading jnthn++ 's latest post on 6guts; nice trick with the lazy tospace allocation! 15:19
jnthn :) 15:20
I thought that was the most boring of the changes :)
timotimo hehe. 15:21
hoelzro it's something I never would have thought to do, but makes *so* much sense once having read it 15:23
that's what makes it so nice =)
15:27 cognominal joined
timotimo Introduce a new callchain mode: folded ( perf report -g folded) to print callchains in a line, facilitating perf report output processing by other tools, such as Brendan Gregg's flamegraph tools commit, commit, commit 15:27
^- something added in linux 4.5, which was just released on sunday 15:28
16:04 TimToady joined, dalek joined
dalek arVM: 3c7ee6e | jnthn++ | src/ (5 files):
Don't keep around barely-used bytecode maps.

These essentially doubled the amount of space we used for bytecode of frames that we actually ran, by keeping around a table noting if each byte was the start of an instruction. This was used for the low level backtraces to give an accurate instruction offset and...that's all!
I can't remember the last time I debugged something using that index. Worse, it's misleading because it doesn't actually factor in that we may be in some specialization of the bytecode. So, tossed it for now. 44fcdb3 | jnthn++ | src/ (4 files): Only allocate instrumentation state if needed.
We only need to keep it when profiling, doing cross-thread write logs, and so forth. This cuts the size of static frames down by 5 pointers each. On the empty loop program, 144KB saving for NQP and 1,036KB for Rakudo.
[Coke] aw, lost the commit line. 16:20
16:55 cognominal joined
dalek arVM: 457df7c | jnthn++ | src/instrument/crossthreadwrite.c:
Fix thinko in an earlier refactor.
arVM: 99bf383 | jnthn++ | src/6model/reprs/MVMMultiCache.h:
Boost size of multi-dispatch cache.

After finding even simple programs could sometimes end up overflowing it in some cases. This alone cuts 40% off a benchmark submitted by RabidGravy++ doing sine wave generation.
17:29 vendethiel joined 17:49 vendethiel joined
diakopter o_O 18:04
jnthn: yes, the instruction offset was helpful .. early on :D 18:10
(but not since)
18:11 FROGGS joined 18:18 patrickz joined 18:30 domidumont joined 18:33 vendethiel joined 19:36 dalek joined 20:10 cognominal joined 20:11 cognominal joined 20:22 zakharyas joined 20:28 domidumont joined 20:55 cognominal joined 21:22 zakharyas joined 22:01 zakharyas joined 22:57 mojca joined