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
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
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
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 =)
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
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.		 16:05
[Coke] aw, lost the commit line. 16:20
dalek arVM: 457df7c | jnthn++ | src/instrument/crossthreadwrite.c:
Fix thinko in an earlier refactor.
 17:01
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.
diakopter o_O 18:04
jnthn: yes, the instruction offset was helpful .. early on :D 18:10
(but not since)

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!