github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
nine japhb: about 1.325G on master 06:11
japhb nine: Ah, so not huge yet, but still a decent improvement. 06:12
brrt \o
nine++ 06:13
all measurement statrs unscientific :-)
brrt oh, hey, I may have to handle nativeinvoke_o as well 06:14
timotimo it'd be interesting to find out the percentage of memory usage from managed vs unmanaged data there 11:23
yoleaux 09:22Z <jnthn> timotimo: www.collinsdictionary.com/dictiona...a-good-job
timotimo since managed data will be accessed by GC runs, whereas unmanaged data will only be used when the code that "uses" it runs
brrt \o 11:34
nwc10 o/ 11:36
timotimo \o
brrt ohai everyone
I think I need non-opcode template support... 11:39
i.e. templates that aren't specific to opcodes 11:42
nwc10 somehow managed to misead that as "I think I need chocolate"
brrt :-)
timotimo how would those get inserted? 11:44
brrt a special purpose tree building routine would choose them 11:47
e.g. you'd get something like 'template = MVM_jit_template_lookup(tc, MVM_JIT_TEMPLATE_MARK_BLOCKED);'
timotimo so more comparable to tiles rather than templates?
brrt and then you'd apply that template to the tree
well, they're still templates 11:48
timotimo i kind of wish we could have more nqp ops pointed out in the profile, but it'd be an extreme overhead to do it for all, and i'm not sure how to select which would be good to instrument etc etc 14:30
lizmat extreme maint overhead or execution overhead ? 14:43
timotimo execution overhead
lizmat still, for some extreme case, this could be very worthwhile provided it doesn't interfere with actual measurements ? 14:44
nine Err...how do I flatten an array into a call's arguments in NQP? 14:45
timotimo yeah, but actual measurement will definitely be interfered with 14:47
we already have pidm aps for perf, but it doesn't understand the output of the jit on a level that'd let you count hits for individual nqp ops 14:48
and of course the exprjit can cause nqp ops to kind of become fuzzy and semi-merged
lizmat
.oO( damn that chap Heisenberg )
nine Ah, same as in Perl 6 actually :) 14:49
lizmat sometimes NQP is QP :-)
timotimo and sometimes NQP is QWOP
jnthn It took me ages to figure out that pidm aps are :P 14:51
brrt yeah, me too :-D 14:52
we'll get to ELF support sometime :-) 14:54
(and once that's done, I'll be mapping MBC to ELF. and once *that* is done, static linking?) 14:55
lizmat jnthn: do we keep a cache of descriptors for hashes ?
I have a solution for github.com/rakudo/rakudo/issues/2348 14:56
but it creates a new Descriptor for each new Hash
well, one created with Hash.new 14:57
timotimo oops :) 15:00
jnthn lizmat: No, not as of yet
lizmat ok, so that part should be fine then :-) 15:01
nine And there go some 3 seconds :) 16:13
jnthn :)
What from? :) 16:14
nine From stage MAST
jnthn Yeah, I meant thanks to new binary writing ops, or something else? :)
nine I remembered that back when I still got profiles of the code compile_operand stood out. So instead of having that process operands based on opcode information, I have update_ops.p6 generate a generator sub for each op. No need to check types and flags when you have tailored code 16:16
Also this lets me move a couple of sanity checks to those generated subs' signatures
The 3 seconds are from plugging this into MAST::Op.new_with_operand_array. So there's still quite some indirection and some places that still go through compile_operand 16:17
jnthn :) 16:19
lizmat And another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2018/10/08/...ed-the-js/ 21:47

Powered by Cro and the Raku® Programming Language.

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

Thank you!