github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
nine Oh boy. I think I now understand the NativeCall JIT issue I found yesterday. For rw args, I read the value back from the args buffer after the call and assign them to the lexref. BUT since I side step most of the invoke compilation stuff, the arg_* instructions are never compiled to code and the values are never actually copied to the args buffer. 08:56
Instead, the native functions get pointers to the WORK registers where the original values are located. Seems like this just works most of the time by accident. 08:58
What I don't understand however is why this works in interpreted code.
Oh...of course. Because in the interpreted code the argument is actually copied to the args buffer :) 09:06
nine So either, I solve this by making it compile the arg_* instructions. Or I get rid of the getarg_* and have it take the written value from the WORK register 09:14
I guess the latter may run into issues with future spesh improvements while the former is a tiny bit slower but safer. 09:15
nine Though the latter would actually be pretty easy to implement... 09:43
Well, at least the bug hunt was totally worth it. The optimization that uncovered it got me some 5-10 % :) 10:34
jnthn Kaiepi: The typical pattern for that, as done with Proc::Async when we wanted to plumb fds together but still return a Supply, is to return a subclass of Supply which can be used to obtain the descriptor before being tapped 11:09
nine++ # bug hunting 11:10
lizmat jnthn: do you agree that something like "my int @a; @a[0] = 42" 11:12
should statically optimize to something like "nqp::assign(nqp::atpos(@a,0),42)" ? 11:13
*atpos_i
jnthn No, I think our inlining tech is closing in on doing that for us anyway 11:14
lizmat ok 11:15
jnthn Also I suspect the general case needs a range check?
lizmat I guess adding a postcircumfix<[ ]>(Blob:D , int) candidate wouldn't make sense for the same reason ? 11:16
jnthn What, that avoids calling .AT-POS?
lizmat yeah
jnthn Yeah, that breaks subclassing I guess
But for both Array and Hash it's already flattening the whole postcircumfix and AT-POS/AT-KEY thing into the caller 11:17
lizmat I guess we need spectests for that then :-)
jnthn :) 11:18
lizmat I guess we need to wait for an nqp release before we can merge all the nice goodies in MoarVM and bump everything, right ? 11:19
jnthn We can merge various things. Not the postrelease-opts (unless you want assorted SEGVs :)) 11:21
lizmat well, the next release target is only 2 weeks away 11:23
jnthn Then it'll happen after the next release, unless somebody else is up for the debugging :) 11:27
'cus this week I've got teaching + conf, and next week I'm taking some vacation :)
timotimo how do we feel about putting $arg.WHAT =:= ExactClass checks into core setting routine? 11:28
lizmat timotimo: been done before
timotimo was it bad?
jnthn Might turn out to be of marginal benefit these days given we spesh on arg type 11:29
lizmat DateTime.new basically does that so it can use a positional interface to create objects 11:30
jnthn otoh, it'll also specialize well in the other cases :)
(Where specializing on argument alone isn't enough to get the win)
lizmat but having Blob:D as a constraint, where it is a parameterized role, won't do much good 11:31
there would be a lot to test against
jnthn tbrowder_: Did you try a --ll-exception and working out exactly where the bad invoke is? 11:35
tbrowder_ not yet, but i will shortly 11:39
got to go now but thanks for help 11:42
jnthn: don’t waste time on my prob, i think i’ve run into the nqp not giving good err msg, will report later 11:46
got a good $/.dump, will report details on #perl6-dev, thanks! 12:36
AlexDaniel samcv: so is updating the wiki page part of the release process? gist.github.com/Whateverable/301c9...ouncements 23:28

Powered by Cro and the Raku® Programming Language.

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

Thank you!