00:03 MasterDuke joined 00:41 lizmat joined 01:48 ilbot3 joined 03:32 brrt joined 05:56 brrt joined 06:07 domidumont joined
brrt … i know what is my bug 06:11
*finally&
also 06:12
lol
hands up for anybody who is interested
06:13 domidumont joined
Geth MoarVM/even-moar-jit: 9e7bd1bb9f | (Bart Wiegmans)++ | src/jit/expr.c
Destructive templates invalidate their result

Otherwise you can have nasty situations in which a subsequent node refers to the old version of a value with all the ensuing hilarity.		 06:21
brrt this gives us almost, but not quite, sp_fastcreate
nine .tell brrt o/ 06:35
yoleaux nine: I'll pass your message to brrt.
nwc10 .tell brrt yes I am interested. Was AFK on an emergency toothbrush delivery mission
yoleaux nwc10: I'll pass your message to brrt.
06:41 brrt joined
nine Good morning, brrt! 06:41
brrt good morning nine 06:42
yoleaux 06:35Z <nine> brrt: o/
06:35Z <nwc10> brrt: yes I am interested. Was AFK on an emergency toothbrush delivery mission
brrt :-D
okay, the commit log mostly explains it i think? what happened was that we were compiling a rather long frame, and there would appear a 'destructive' template
so 'normal' templates directly yield a value (for the expression compiler to do as it sees fit) 06:43
'destructive' templates return a result, but write it directly to local memory
so they don't yield a value
so, i implemented that way back in the past 06:44
but i had forgotten that it might happen that there'd be an earlier version of that same variable already defined
so that code would create a new object and then assign it as an attribute, but, because creation is destructive, it would not overwrite the old 'definition' of the value in the lookup table 06:45
so rather than v3 of local(12) it'd write v2 of local(12), which wasn't the same type of object at all 06:46
there is another bug uncovered with this, but it happens much later in compilation, so i'll have to figure out why it happens 06:47
nine Is "computed" this lookup table? 06:48
brrt yes
it is a part of expression tree building
whenever we load a value from memory or have it as result, we stash that node and map it to the local MoarVM variable number 06:49
so that we don't have to issue the same load twice 06:50
07:12 lizmat joined 07:43 domidumont joined
brrt okay, the register allocator has clearly gone mad in the frame i'm looking at 08:12
spilling stuff it shouldn't 08:13
08:29 robertle joined
lizmat
.oO( frame abuse )
 08:32
jnthn
.oO( You've been framed )
 08:58
yoleaux 6 Jun 2017 22:47Z <eveo> jnthn: would you be able to resolve this ticket? The question is is it guaranteed `run` will never use the shell to execute stuff. github.com/perl6/doc/issues/1208#i...-281522376
09:39 AlexDaniel joined 09:41 sivoais joined
brrt so the proximal cause is that my newly-created value is overwritten, which is weird for sure, uhuh 10:02
oh, wait a minute
timotimo we waited almost half an hour! :P 10:24
brrt hmmm 10:30
i feel like there could be an interaction between 'full' and 'point' spills 10:31
but this is a case of register allocator gone mad anyway
yeah, this is interaction between full and point spills alright 11:07
the tl;dr 11:08
i may need to spill-to-allocate a register for the CALL result
if that happens, the point restore which is placed *after* the CALL will overwrite the newly allocated value, because at the point the point spill was issued, it wasn't yet overwritten 11:28
11:30 domidumont joined
brrt so it's an ordering issue again 11:31
hmmm 11:37
12:24 domidumont1 joined 12:41 zakharyas joined 12:54 geekosaur joined 13:37 brrt joined
brrt mumbles something about people arguing markdown is more readable than POD 13:37
eveo 'cause obviously it is. 13:39
:)
brrt srsly though
markdown has no formal specification, isn't strictly speaking 'parseable', and has a gazillion dialect 13:40
s
how is that… better, in any reasonable sense
i ???? for engineering 13:41
eveo I am serious. L«C<some code>|/foo/bar» vs [`some code`](/foo/bar). B<SHOUT> vs **SHOUT**
Markdown is way easier to type too
brrt that is nothing but convention and familiarity, and you know it
what is harder or easier about the one or the other 13:42
they use approximately as many punctuation characters
eveo No, it's all about typing angular brakets, without the help of things like Emmet that lets you avoid doing that with HTML
brrt .. typing angular brackets is horrible, typing stars and square brackets is not?
eveo Nope
At least not for me. 13:43
brrt well, fine. but i posit that you have no better reasons for that, than convention and familiarity
eveo "that" being what? That's is physically easier to type `` than C<> ?
robertle I wonder whether some language preferenfces may have something to do with the keyboard layout in question ;)
nine eveo: with German keyboard layout C<> is actually much nicer to type 13:44
brrt well, in a US style keyboard, 10-finger-typing, I can't say it makes a difference to me
robertle which is also why lisp is so out of fashion, the round brackets are just way too far away from the home row on most keyboards
eveo I use 6 finger typing
brrt robertle: ????
well, there you go 13:45
you type one way, i type another. there is no 'objectivity' about the easiness in typing there
nine eveo: POD is also a bit more self documenting. B<SHOUT> is easy to remember and recognize as something being bold. But why is it **SHOUT** and not just *SHOUT* like we used for the past 40 years?
eveo "C" = left pinkie + left index; "<" = right ring finger + right thumb<; ">" = same
brrt well, for me, < is right-middle-finger + left pink 13:46
eveo nine: why is it B<> and not ** that we used for the past 40 years?
brrt * is… exactly the same, just a bit further to reach
lol
eveo Hell. Markdown renders on GitHub. Pod6 doesn't, even after we asked them to add it. 13:47
brrt anyway, one of the counterarguments is that the overloading of * to mean strong and italic at the same time
eveo Your argument about readability ends right there, I'd say.
eveo goes to do productive stuff.
nine eveo: sorry, but no *bold*, /italic/, _underline_. I have no idea why we suddenly have to double the markers.
brrt nine: that's org-mode syntax, that's not going to work with markdown unfortuantely
**bold**, *italic*, _underline_ <- i'm not sure that even works 13:48
nine My irssi even underlines the "underline" there ;)
brrt hehe
anyway, yeah, it's bikeshedding. but the 'obviousness' of it all surprised me 13:49
don't worry. you can type markdown all you like
it's just that you're wrong :-P
eveo Right back at ya. Enjoy your syntax errors and no fully-functional renderer in exitence. 13:51
robertle it would be cool though if github would render pod6...
nine Nothing like a good markup language flamewar to end a work day :) 13:52
brrt well, i was talking about pod as in both categories at the same time
brrt nods
good for the soul 13:53
so one of the possible solutions for the point/full-spill interaction is to…. add another layer of indirection 13:58
i don't much like that though
14:38 domidumont joined 14:54 domidumont joined 15:10 brrt joined 15:11 ggoebel joined 15:27 domidumont joined
Geth MoarVM/even-moar-jit: 266b60f606 | (Bart Wiegmans)++ | 2 files
Describe point/full spill conflict

This conflict causes failures during NQP build when sp_fastcreate is enabled. A point spill will ignore the full spill and potentially overwrite the value that it was spilled for.		 15:56
brrt this is one of those core assumptions gone bad deals... 15:58
but, i'll figure something out :-)
lizmat devirt: repr op getattrs_o couldn't be devirtualized: type unknown # found in MVM_JIT_LOG, should we be worried ? 16:09
jnthn No 16:10
It just means an optimization it sometimes has the info to do can't be done in this case 16:11
Could be for many reasons, including the code being a cold branch in a hot routine so we never gathered data on what types show up
lizmat could this trigger it showing up as not-JITted in --profile ? 16:13
because the log states this particular method *did* get JITted
ah, or it could mean it got deoptimized 16:14
so it looks like this particular case after 256 times it got optimized, then deoptimized and then next iteration optimized again, and deoptimized again, etc. for the next 4744 times 16:15
Of 1002426 specialized or JIT-compiled frames, there were 4744 deoptimizations (that's 0.47% of all optimized frames). 16:16
jnthn: is that expected behaviour? that it JITs something again and again, and deoptimizes again and again ?
jnthn That's not really what happens
Or at least, I highly doubt it 16:17
It may run the JITted code and fall out of it
Many times
But that isn't producing fresh JIT code every time
The same frame may be JITted more than once; there's a limit on the number of specializations of something like 4 or 8, though 16:18
lizmat but if it falls out of the Jitted code, it would need to run the deopted code again, no?
so it *is* potentially unnecessary overhead ?
jnthn Potentially we come out worse at times
It's hard to say in general though
I mean, if you run JITted
And then after it does some owrk hit a depot 16:19
Then you can still find that the savings of being in the specialized/JITted code exceed the cost of the deopt later
But yes, at present we hedge on deopt being rare
And don't have a strategy for backing out common deopts
In a perfect world we'd perhaps re-specialize but not making the assumption that triggers the deopt 16:20
lizmat is there a way to figure out what causes the deopt ?
jnthn I think if you compile a MoarVM with deopt debug logging turned on, then look at the spesh logs, it is possible to correlate the two 16:21
Well, I know it is 'cus that's how I've done it in the past
But it involves reading bytecode and understanding what the deopt is against and then reading ahead to work out what optimized code is being guarded by that deopt 16:22
And then trying to map that back up to what Perl 6 code was originally compiled into that bytecode :)
lizmat feels like something that could be optimized ? 16:23
jnthn In what sense?
lizmat s/optimized/automated/
jnthn Ah
Well, ideally at some point we'd be able to incldue it in the profile output too
We can probably go so far as saying a line number, an expected type, and an actual type
lizmat that would be cool :-) 16:25
jnthn As usual, it's all about the tuits :)
lizmat yeah :-( 16:26
jnthn Though can't complain, I've had plenty of Perl 6 tuits of late. That's why I/O guts have had a bunch of work :)
Tomorrow I'll continue on with the Proc stuff 16:28
I guess next job is Proc::Async on JVM
And then re-implementing Proc using Proc::Async
And then killing off yet more code
We might soon get to the point where we no longer need to build up a libuv event loop per thread 16:29
And can just have the one running for async I/O, timers, etc.
lizmat sounds like a big improvement :-) 16:30
jnthn Well, guess it has to save us something :)
jnthn wanders home 16:33
Will hopefully get my blog post finished this evening. :)
16:46 robertle joined 17:41 lizmat joined 17:44 zakharyas joined 19:49 patrickz joined 20:24 praisethemoon joined 20:30 brrt joined
brrt .tell lizmat that particular error doesn't have anything to do with deoptimization; deoptimization is currently especially costly in case we do inlining (because we have to reconstruct the frames that would-have-been) 20:34
yoleaux brrt: I'll pass your message to lizmat.
brrt in case we'd do trace compilation, that tradeoff gets amplified 20:36
lizmat ack 20:37
yoleaux 20:34Z <brrt> lizmat: that particular error doesn't have anything to do with deoptimization; deoptimization is currently especially costly in case we do inlining (because we have to reconstruct the frames that would-have-been)
brrt i'm pondering killing off point spilling as a strategy 20:39
it's basically never legal to point-spill something that is then later respilled 20:43
so, how to avoid it, other than not doing at all 20:44
and what is the complexity of replacing it with a full spill
jnthn Well, yeah, the more you speculate, the bigger the potential losses. :) 20:51
brrt jnthn: have plans to go to the new yapc::eu / TPC::EU? 21:14
21:24 tbrowder_ joined 21:29 leego_ joined 21:39 ggoebel joined
timotimo jnthn, would you put these deopt detail nodes (i.e. line number and/or bytecode index and expected vs received) into the call graph nodes themselves, too? that could give us a rather big amount of data all in all, depending on how the deopting functions are spread out across the program 21:41
samcv i'm going to add some more ops 22:02
timotimo "ops i did it again" 22:03
samcv for ignorecase + ignaremark
for index and for eqat
equaticim_s i suppose and indexicim_s
will make me very happy. so i can solve that RT about totally broken ignorecase+ignoremark and also make the code for it in nqp a lot less... horrible 22:04
lizmat samcv++ 22:06
samcv :-)
lizmat but how will that affect the JVM ?
samcv no effect
JVM doesn't have NFG anyway. so i think it can't do it?
jnthn I think these are only spat out by the regex compiler?
samcv ^
that too
jnthn And that code is per-VM 22:07
samcv there's a eqatim_s currently which i *can* def make better. but i'll work on making things that don't work at all work before improving the working things 22:08
\o/ yay works. 22:16
just gotta polish this up
22:41 geekosaur joined 22:55 TimToady joined
jnthn Phew, finally got my blog post finished. 6guts.wordpress.com/2017/06/08/sor...ronous-io/ :) 23:02
timotimo: I think I might record them separately from the call graph
timotimo: Probably just (file, line, expected) as the key and a list of got as the value 23:03
Hm, though
Maybe line isn't specific enough and will be misleading
timotimo don't we want to differentiate different spesh candidates?
jnthn Not really
timotimo also, yeah, inlines will give you jumpy line numbers, too
jnthn Yeah, though we need to fix that more generally anyway :)
timotimo what's there to fix? it's in the nature of the thing 23:04
jnthn We can emit a new annotations segment when we emit the bytecode, I guess :) 23:05
timotimo i'm not sure what the end result would look like 23:07
would we give the line number of the callsite and in the extra segment we'd put the line numbers belonging to the inside of the inlined thing?
jnthn oh, you're talking about reconstructing the call stack, I was just thinking of having a file/line rather than a sub name :) 23:09
To do that you'd need to use the inlines table of the spesh candidate 23:10
timotimo i didn't realize we didn't just copy the annotations over while inlining 23:16
jnthn 'night, #moarvm 23:18
timotimo gnite jnthn :) 23:19
samcv nite 23:43
timotimo i'll go to sleep now, too 23:46

Powered by Cro and the Raku® Programming Language.

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

Thank you!