01:51 ilbot3 joined 03:33 pharv_ joined 03:47 pharv_ joined 04:02 SUPERNETS joined
SUPERNETS THIS NETWORK IS BLOWJOBS! GET ON SUPERNETS FOR COLD HARD CHATS NOW 04:02
05:50 lizmat joined
nine jnthn: the test runs just fine here on This is Rakudo version 2017.07-138-ga91ad2da8 built on MoarVM version 2017.07-347-g127fa2ce7 06:11
06:36 lizmat joined 07:30 dalek joined, synopsebot6 joined 08:14 lizmat joined 08:45 lizmat joined
jnthn morning, #moarvm 08:47
This network is...what? :P 08:48
I didn't know that was an adjective.
nine: Fails for me in that version, curiously enough. Though it's not an entirely reliable failure 09:06
Darn, the bisect points to e354d1f901468984b95c3ade53ae23f218760e37 09:13
But that was just a change to make more information available to allow more things to be optimized
So it doesn't actually provide much useful information on what's wrong
09:15 edehont joined, zakharyas joined
Geth MoarVM: 9dbaf5c494 | (Jonathan Worthington)++ | src/spesh/codegen.c
Ensure unreachable handlers fully -1'd.
 09:16
jnthn That doesn't fix it, just seemed a wise idea
Geth MoarVM: b70995783a | (Jonathan Worthington)++ | src/spesh/codegen.c
Ensure unreachable inline endpoints both -1'd.
 09:18
09:24 lizmat joined 09:29 lizmat joined 09:31 brimonk joined, harrisi joined, jpf4 joined 09:55 lizmat joined
Geth MoarVM: 91590c4171 | (Jonathan Worthington)++ | 3 files
Move sp_resolvecode op body into a function.
 10:00
MoarVM: 3c36ef2667 | (Jonathan Worthington)++ | 2 files
JIT sp_guardsf and sp_resolvecode.
10:02 lizmat joined
jnthn So of course with it JITted the test I was worrying about passes again :P 10:03
Provided I don't disable JIT
Since I know the current thing I've been working on didn't introduce this problem, though, I see no reason not to get it in.
nine samcv++'s talk is now starting :) 10:08
lizmat well, if we get the video running :-( 10:12
dogbert17_ is there a stream somewhere?
lizmat we have ignition
and liftoff 10:13
dogbert17_ never used it, is there a link one can go to and watch everything from afar :) 10:14
lizmat facebook.com/theperlconference
is the url
timotimo huh i can watch the stream but i can't scroll back to the beginning? 10:15
but i'm out the door in 5
lizmat timotimo: no idea
it is being recorded as well
dogbert17_ yay, it seems to work. Is that samcv? 10:16
lizmat yes
stmuk timotimo: I'd guess you can only rewind once the talk is complete 10:21
timotimo how come the camera's wiggling?
ok, i'm afk 10:24
stmuk no tripod? the audio is nice and clear which is the main thing
Geth MoarVM: 58d3874ed5 | (Jonathan Worthington)++ | 3 files
Implement speculative call optimization.

This is optimization of calls where we can't 100% determine the code object that will be invoked, but we know from our logging that it is likely to be consistent. Thus, we guard the static frame that's being invoked and then can either fast-invoke (pre-selection of the spesh candidate) or inline.		 10:26
lizmat shitov uses a handheld 10:27
11:03 lizmat joined 11:09 brrt joined
brrt ohai #moarvm 11:10
samcv++ talk went well i think 11:11
jnthn samcv++ 11:18
lunch & 11:20
11:34 AlexDani` joined 11:43 markmont joined
samcv thanks :) 11:55
11:59 Ven joined, lizmat joined
jnthn back 12:05
12:08 brrt joined
brrt idea. what if we don't have the variadic operators require the number of operand expressions 12:09
we can just list all variadic ones, count the number we have, and splice that into the list 12:10
reduce error surface, as it were
jnthn brrt: Context?
brrt an operator like (DO ….) or (ARGLIST ..) can take any number of expressions
provided we first prefix them with that number 12:11
but the expr-tree-compiler knows that number
currently checks it, too
so if you'd do (DO 3 (foo) (bar) (baz) (quix)) - it will tell you you made a mistake
but that's not ergonomic
so i propose translating (DO (foo) (bar) (baz) (quix)) to (DO 4 (foo) (bar) (baz) (quix)) simply by splicing the number of operands after the DO 12:12
jnthn ah, I see 12:13
Seems less error prone, yes
Urgh, some bug has shown up in the speculative call opt thing I pushed above 12:14
And of course the frame I've got it isolated to is pretty huge 12:15
dogbert17_ jnthn: I'm probably disturbing your debugging but does t/spec/S32-num/fatrat.t work for you? 12:36
dogbert17_ tries with the latest nqp 12:40
jnthn dogbert17_: That's exactly the one I'm debugging
I can get it down to one very specific application of the optimization 12:43
12:43 lizmat joined
jnthn Thing is, it looks entirely normal 12:44
It's actually this call that goes wrong: 12:45
nqp::findmethod(HLL::Grammar, 'EXPR')(self, $preclim, :noinfix($preclim eq 'y='));
But the consequence of it shows up, like, waaay later 12:46
dogbert17_ aha, I just noticed that I haven't been running HEAD nqp 12:50
I thought that was the reason the test failed and that I had disturbed you unnecessarily 12:52
jnthn No, the NQP patch is just addressing a code-gen bug that I spotted while investigating that regression 12:53
dogbert17_ ok, good to know
jnthn Worth having but doesn't address the regression itself 12:54
12:58 buggable joined
dogbert17_ it's a bit funny though, if I run './perl6 t/spec/S32-num/fatrat.t' then it fails immediately 12:59
with Confused 13:00
at /home/dogbert/repos/rakudo/t/spec/S32-num/fatrat.t:175
on the other hand, if I run './perl6-valgrind-m t/spec/S32-num/fatrat.t' it almost works, i.e. it starts running the tests and later fails at: 13:02
ok 245 - === with false outcome
Type check failed in assignment to $a; expected FatRat but got Rat (0.1)
in block at t/spec/S32-num/fatrat.t line 184
in block <unit> at t/spec/S32-num/fatrat.t line 182
jnthn Odd 13:05
It's not the guard insertion and so forth that's busted
It's only when we rewrite it into a fastinvoke that things go bad
13:06 lizmat joined
dogbert17_ so why does it work under valgrind but not without, odd 13:12
another useless observation, if I run './perl6 t/spec/S32-num/fatrat.t' several times it fails at different lines, e.g. 152, 154 and 175 13:14
13:17 lizmat joined 13:18 lizmat joined 13:20 lizmat joined
jnthn It seems that we might be preselecting candidates incorrectly 13:25
I just put in a debugging flag and stuff for it and there's a few
And they're all ones determined by MVM_spesh_arg_guard_run_callinfo 13:27
13:28 brrt joined
dogbert17_ you're closing in on the problem 13:28
13:29 lizmat joined
brrt .oO ( that also saves me a few minutes from my presentation ) 13:29
13:35 lizmat joined
jnthn And it's seemingly wrong for the very place I isolated the optimization to 13:41
Geth MoarVM/even-moar-jit: ebc681b3a3 | (Bart Wiegmans)++ | 3 files
Automatically insert variadic list length

This reduces the potential for errors - the template precompiler already knows the length, so why not have it add it.		 13:42
dogbert17_ btw, changing MVM_GC_DEBUG is no longer possible due to a new compiler directive being added '-Werror=pointer-arith' 14:07
jnthn Ah, one cause of mis-matches is that when we optimized there was only a certain specialization, and later a typed one showed up
dogbert17_: :( 14:08
dogbert17_ do you think that fixes the problem
jnthn I think it means my checker might be identifying problems where there are none 14:09
Yeah, it mis-identified some cases as wrong 14:13
14:13 AlexDani` joined
jnthn Now there's a lot less hits 14:14
Which means the hits we get are perhaps more genuinely problems
dogbert17_ so, a nice improvement at the very least then 14:16
jnthn "JIT: can't find deopt all idx" Hmmmmmmmm. 14:23
Yeah, it's looking increasingly like a deopt bug 14:28
Geth MoarVM: 5ba22cb5ea | (Jonathan Worthington)++ | src/spesh/dump.c
Dump certain result nodes in arg guards.
 14:29
14:35 lizmat joined
jnthn There's two things it could be. Either it's 'cus we don't deopt the top frame (likely, hopefully easier to fix) or because we somehow miss when resolving some deopt indexes (harder) 14:42
Geth MoarVM: 49ad5752cb | (Jonathan Worthington)++ | src/spesh/deopt.c
Better logging of full deopts.
 14:44
dogbert17_ hopes it's the easier to fix problem 14:47
nwc10 "seen" brrt? 14:48
(maybe I should ask on #yapc)
jnthn Pushed a commit an hour and 6 mins ago...
nwc10 ah OK. 14:49
my "problem" is that nqp won't build with his branch now, and MoarVM won't merge (cnflicts)
which actually was the thing that prompted me to be looking for him
clearly I'm not awake enough to remmeber the "what" and tie it back to the "why"
14:50 lizmat joined 14:58 lizmat joined
Geth MoarVM: 7f0f753e55 | (Jonathan Worthington)++ | 4 files
Add debugging aid for spesh preselection.
 15:14
MoarVM: ec6781acfd | (Jonathan Worthington)++ | 7 files
Make rebless deopt stack top frame also.

Previously it would only deoptimize the frames below this point. That was not sufficient in a frame like `statement` in the Perl 6 grammar, which does a rebless and then more calls that may, thanks to the recent speculative calls specialization work, have been specialized.		 15:20
jnthn That's the fatrat fix 15:21
Another case of a long-standing bug that was only just exposed by more aggressive optimizations being available 15:22
15:26 lizmat joined
jnthn But darn, various failures under spesh stress testing still 15:31
Ah, seems there's something that goes awry with enum value creation 15:33
hm, with rebless
15:41 Ven joined
jnthn Ah, seems this is a simpler one at least. 15:47
15:51 lizmat joined
Geth MoarVM: 37deb55eea | (Jonathan Worthington)++ | src/spesh/facts.c
Bump usage of writers in deopt instructions.

Otherwise, we might tweak the register that the operation writes into, causing the value to not be in the right place after deopt.		 15:52
jnthn Yeah, that clears up the trouble. :) 15:55
16:04 dogbert17 joined
dogbert17 jnthn++ 16:04
jnthn With the new speculative code opt, we can now - in theory - inline the block in for ^10000000 { } 16:07
In practice, it seems to miss out on inlining it about half of the time, which is bizzare.
dogbert17 do you think it will have an effect on test-t?
jnthn But when it does nail the inline it runs in about 0.68s instead of 1.75s
dogbert17: Hopefully :) 16:08
Though it sure will need some tuning
I think it probably makes some bad decisions at the moment
Also it inserts some guards that it then doesn't use, so I need to re-order things to try and not do that.
I think there's budget for one more attempted opt, which will be to see if I can get inlining of closures to work. 16:09
I'm curious why it manages to miss the opt some of the itme
*time
ohh 16:10
It misses the OSR
dogbert17 do you know why?
jnthn No 16:11
nwc10 so time to cook food?
dogbert17 Vindaloo?
jnthn It's probably a race 16:12
But...how is it happening...
nwc10 it consistently misses the OSR?
jnthn No
It hits it sometimes, misses it sometimes
There's potential for a race in that it's produce by one thread, and watched for by the other 16:13
It isn't a problem producing the specialization 16:14
I can see from the inline log that it consistently manages to inline
Geth MoarVM: c0f7a3b14f | (Jonathan Worthington)++ | src/spesh/candidate.c
Fix data race that could lead to missed OSR.
 16:20
jnthn Makes a factor of 3 difference if it manages or not :P
dogbert17 impressive
so, what's for dinner? 16:21
jnthn I got curious and disabled the opt I spent the last couple of days putting in 16:22
0m1.412s before
0m0.667s after
m: say 0.667 / 1.412
camelia 0.472380?
jnthn for ^10000000 { } in half the time :)
Dinner is shepherd's pie :) 16:23
dogbert17 very nice
what, that doesn't sound like an Indian dish :)
jnthn There actually are various Indian-style variants of it by making a different kind of sauce 16:27
Though mine is the traditional worcestershire sauce version 16:28
dogbert17 so nothing extremely spicy today 16:29
jnthn No, not really
Oh, for more fun
Didn't find worcestershire sauce for sale here 16:30
So have to concoct it myself :)
dogbert17 :)
jnthn Indian is the most common thing I cook, but it's nice to have some variety :) 16:31
Anyways, I'm off home to warm/eat that :)
(Cooked a big one yesterday, so it'll feed us for at least 2 dinners :)) 16:32
dogbert17 is getting hungry 16:33
16:42 zakharyas joined 16:52 lizmat joined 16:57 Ven joined 17:04 colomon joined 17:17 colomon joined 17:21 lizmat joined 17:59 colomon joined 18:23 SourceBaby joined 18:29 Ven joined 19:08 brrt joined
brrt ohai 19:12
19:15 stmuk_ joined
brrt samcv bumped MOAR_REVISION, which is why my branch won't build 19:17
timotimo ah yeah 19:28
personally, i'd like a --ignore-revision flag for configure.pl
19:50 brrt joined 19:56 evanm joined
Geth MoarVM/even-moar-jit: 48 commits pushed by (David Warring)++, MasterDuke17++, (Timo Paulssen)++, (Stefan Seifert)++, (Dagfinn Ilmari Mannsåker)++, (Jan-Olof Hendig)++, niner++, (Jonathan Worthington)++, (Samantha McVey)++, (Bart Wiegmans)++
review: github.com/MoarVM/MoarVM/compare/e...15d364f1d4		 20:00
20:01 Geth joined 20:34 lizmat joined 20:49 colomon joined 21:37 markmont joined 21:41 evanm joined 22:16 dogbert17 joined 22:46 colomon joined 23:24 colomon joined 23:38 colomon joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!