github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
Geth MoarVM: 7aa9500ee4 | (Timo Paulssen)++ | src/profiler/instrument.c
nativecallcast invokes, so have profiler track it
 00:18
timotimo we should really be able to figure out which ops allocate with clever use of breakpoints. like, whenever MVM_gc_alloc is called, check what line in interp.c it corresponds to and build a Set of those 00:21
01:14 fake_space_whale joined 01:15 p6bannerbot sets mode: +v fake_space_whale 04:59 fake_space_whale left 06:30 lizmat_ joined, p6bannerbot sets mode: +v lizmat_ 06:33 lizmat left 07:15 domidumont joined 07:16 p6bannerbot sets mode: +v domidumont 07:27 AlexDaniel left
nine We only have a return_i op, but no return_u op. 09:55
So we actually coerce a uint64 to int64 before returning it. Considering that in memory uint and int are the same and it's just the interpretation that differs, couldn't we just omit the coercer and use return_i to return the uint? 09:57
Ah, no. The bytecode validator complains 10:06
timotimo the bytecode validator doesn't run after spesh, i don't think 10:40
so spesh could probably turn it into a set op
10:41 lizmat_ is now known as lizmat
nine That would get rid of the coercer before the return but still wouldn't get the block to get a uint return_kind 10:42
timotimo ah 11:12
jnthn We probably should add a return_u; unsigned handling is still a bit sketchy 11:30
nine And sp_getarg_u 11:33
Though sp_getarg_i seems to work just fine for unsinged args 11:34
Geth MoarVM/nqp-mbc: 27 commits pushed by (Stefan Seifert)++
review: github.com/MoarVM/MoarVM/compare/d...8e0e67f9f9		 11:43
nine ^^^ rebase
Geth MoarVM/nqp-mbc: 8 commits pushed by (Stefan Seifert)++ 11:45
MoarVM/nqp-mbc: 7 commits pushed by (Stefan Seifert)++ 11:46
13:53 fake_space_whale joined 13:54 p6bannerbot sets mode: +v fake_space_whale
nine Does anyone feel like reviewing nqp-mbc or should I just merge it and we improve it afterwards? 14:21
timotimo well, we're far from a release anyway; do you mean only the moarvm branch or also the nqp branch? 14:33
i don't think there'd be a problem merging only the moarvm branch
maybe the ecosystem should be toasted with the nqp-mbc mast backend 14:34
nine I'd need to merge the branches in all repos 14:35
timotimo ah 14:37
releasable6: status
releasable6 timotimo, Next release in ā‰ˆ14 days and ā‰ˆ4 hours. 2 blockers. 0 out of 58 commits logged
timotimo, Details: gist.github.com/2d4fa0c8c355d9b9db...fd3fd751a6
timotimo 2 weeks should be plenty to find and fix problems; wost case a revert should still be possible, right?
nine sure
timotimo you have my +1 at least 14:38
dogbert17 does any of you know why having a BEGIN phaser at the beginning of a one-liner slows it down massively? 14:40
nine++ (go for it)
Geth MoarVM/master: 43 commits pushed by (Stefan Seifert)++
review: github.com/MoarVM/MoarVM/compare/7...baeee5f3f0
nine It is....done! 14:41
That was quite a bit more work than expected, but such is life :)
dogbert17 impressive
timotimo i'm wondering if any of this work would let us have a slimmer implementation for nativecall's compilation parts - for moar only, of course 14:43
but i guess since that already builds qast, and qast to mbc is now a step shorter, it'll already benefit a lot 14:44
nine Yes, we could still gain a bit there 14:45
timotimo oh? cool
it'd be pretty rad if we could compile multiple functions at once, too
nine at once? 14:47
14:48 shareable6 left
timotimo into a single compunit 14:48
14:48 shareable6 joined 14:49 p6bannerbot sets mode: +v shareable6
nine Right now compilation of nativeinvoke goes through $call_gen in QASTOperationsMAST. That's very generic. We already know that it has exactly 2 args and what kind they are. It'd be possible to handle them like speshresolve. 14:49
timotimo gotta go AFK now for a while, though
nine You mean threaded?
timotimo not necessarily; could just be lazy 14:50
have a counter of how often unoptimized functions were called
when it reaches a threshold, compile all functions that were called in the mean time and reset the counter
say, how about a hook we can call at BEGIN time 14:51
nine FWIW it already compiles those optimized functions at BEGIN time, so your typical binding module won't incur any runtime overhead
timotimo like, my @funcs = ::.grep(*.is-native); NativeCall::CompileAll(@funcs)
nine github.com/rakudo/rakudo/blob/mast...l.pm6#L736
timotimo ah, i thought the first call would cause compilation 14:52
in that case they all land in the single compunit, too
fantastic!
but, hold on
ooh, it installs a check phaser?
nine How do you think I've kept ahead in the benchmarking game for so long :)
timotimo you're scary smart, sir. 14:53
nine bows
timotimo does the AFK thing
o/
dogbert17 nine: do you have any theories as to why 'BEGIN { }; { for ^10_000_000 { }; say now - ENTER now }' is much slower than '{ for ^10_000_000 { }; say now - ENTER now }' 14:56
nine Err...no? 14:59
dogbert17 it's quite strange methinks 15:02
dogbert17 is trying to build Rakudo on a RPi2 atm 15:03
15:05 travis-ci joined, p6bannerbot sets mode: +v travis-ci
travis-ci MoarVM build errored. Stefan Seifert 'Merge branch 'nqp-mbc'' 15:05
travis-ci.org/MoarVM/MoarVM/builds/450228766 github.com/MoarVM/MoarVM/compare/7...baeee5f3f0
15:05 travis-ci left
nine How can I create an actual int literal in NQP? 15:06
MasterDuke nine: i get a couple new warnings now: gist.github.com/MasterDuke17/21f2d...32596f2ce5 15:23
Geth MoarVM: 255bf8a7ad | (Stefan Seifert)++ | src/core/validation.c
Fix error in format string in validate_reg_operand

  Thanks to MasterDuke++ for pointing this out!		 15:26
MasterDuke nine++ that was fast 15:28
15:41 nativecallable6 left, nativecallable6 joined, p6bannerbot sets mode: +v nativecallable6 15:42 AlexDaniel joined, p6bannerbot sets mode: +v AlexDaniel 15:49 patrickb joined 15:50 p6bannerbot sets mode: +v patrickb 15:52 travis-ci joined, p6bannerbot sets mode: +v travis-ci
travis-ci MoarVM build errored. Stefan Seifert 'Fix error in format string in validate_reg_operand 15:52
travis-ci.org/MoarVM/MoarVM/builds/450239670 github.com/MoarVM/MoarVM/compare/4...5bf8a7ad03
15:52 travis-ci left 16:53 lizmat left 16:56 lizmat joined, p6bannerbot sets mode: +v lizmat 17:32 MasterDuke left
nwc10 nine: I get a backtrace failure early in the NQP build if I have MoarVM built with #define MVM_SPESH_CHECK_DU 1 17:44
and without, t/nqp/033-init.t t/nqp/081-radix.t and t/nqp/101-lexpad-stuff.t all fail with "MoarVM panic: Register types do not match between value and node"
and I forgot (to repeat) that I have SR0-amp-hack 17:56
on no, not *That*
I have MVM_SPESH_BLOCKING=1 and MVM_SPESH_NODELAY=1 set in my environment
(and #define MVM_ARRAY_CONC_DEBUG 1 and #define FSA_SIZE_DEBUG 1 but they probably don't matter. And yes this is under ASAN but it made no comment) 17:57
sorry, this all seems like a somewhat LTA response to what's actually "oh cool, the branch got merged" 17:58
timotimo nine: what exact kind of literal do you need? something with P6int repr? i.e. not a bigint? 18:53
nine Yeah, just an int 19:12
timotimo hm, is that what BOOTInt is, or is that bigint? 19:13
no, BOOTInt is actually a P6int 19:14
nine nwc10: well it was a huge branch with lots of optimizations. Regressions are not exactly surprising :)
timotimo rather than a P6bigint-boxing type
19:41 domidumont left 19:43 domidumont joined 19:44 p6bannerbot sets mode: +v domidumont 19:53 domidumont left 20:14 patrickb left 21:26 ugexe left 21:53 ugexe joined 21:54 p6bannerbot sets mode: +v ugexe 22:07 zakharyas joined 22:08 p6bannerbot sets mode: +v zakharyas
nine nwc10: my branch appears to be innocent after all. Even if I revert my 2 changes to spesh, the error still appears. So I presume the spesh bug was already there and my code just uncovered it. At least if my understanding is correct that errors in the DU chain can only be caused by spesh bugs. 22:31
22:31 zakharyas left 22:34 zakharyas joined, p6bannerbot sets mode: +v zakharyas 23:02 zakharyas left
timotimo jetbrains ide over x forwarding might not be a very good idea 23:24
timotimo grabs a bowl of chips
nope, it's not working well enough 23:31

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!