Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-06-07

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:03 MasterDuke joined #moarvm
00:41 lizmat joined #moarvm
01:48 ilbot3 joined #moarvm
01:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:32 brrt joined #moarvm
05:56 brrt joined #moarvm
06:07 domidumont joined #moarvm
06:11 brrt … i know what is my bug
06:11 brrt *finally&
06:12 brrt also
06:12 brrt lol
06:12 brrt hands up for anybody who is interested
06:13 domidumont joined #moarvm
06:21 Geth ¦ MoarVM/even-moar-jit: 9e7bd1bb9f | (Bart Wiegmans)++ | src/jit/expr.c
06:21 Geth ¦ MoarVM/even-moar-jit: Destructive templates invalidate their result
06:21 Geth ¦ MoarVM/even-moar-jit:
06:21 Geth ¦ MoarVM/even-moar-jit: Otherwise you can have nasty situations in which a subsequent node
06:21 Geth ¦ MoarVM/even-moar-jit: refers to the old version of a value with all the ensuing hilarity.
06:21 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/9e7bd1bb9f
06:21 brrt this gives us almost, but not quite,  sp_fastcreate
06:35 nine .tell brrt o/
06:35 yoleaux nine: I'll pass your message to brrt.
06:35 nwc10 .tell brrt yes I am interested. Was AFK on an emergency toothbrush delivery mission
06:35 yoleaux nwc10: I'll pass your message to brrt.
06:41 brrt joined #moarvm
06:41 nine Good morning, brrt!
06:42 brrt good morning nine
06:42 yoleaux 06:35Z <nine> brrt: o/
06:42 yoleaux 06:35Z <nwc10> brrt: yes I am interested. Was AFK on an emergency toothbrush delivery mission
06:42 brrt :-D
06:42 brrt 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
06:43 brrt so 'normal' templates directly yield a value (for the expression compiler to do as it sees fit)
06:43 brrt 'destructive' templates return a result, but write it directly to local memory
06:43 brrt so they don't yield a value
06:44 brrt so, i implemented that way back in the past
06:44 brrt but i had forgotten that it might happen that there'd be an earlier version of that same variable already defined
06:45 brrt 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:46 brrt 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:47 brrt 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:48 nine Is "computed" this lookup table?
06:48 brrt yes
06:48 brrt it is a part of expression tree building
06:49 brrt 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:50 brrt so that we don't have to issue the same load twice
07:12 lizmat joined #moarvm
07:43 domidumont joined #moarvm
08:12 brrt okay, the register allocator has clearly gone mad in the frame i'm looking at
08:13 brrt spilling stuff it shouldn't
08:29 robertle joined #moarvm
08:32 lizmat .oO( frame abuse )
08:58 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. https://github.com/perl6/doc/issues/1208#issuecomment-281522376
09:39 AlexDaniel joined #moarvm
09:41 sivoais joined #moarvm
10:02 brrt so the proximal cause is that my newly-created value is overwritten, which is weird for sure, uhuh
10:02 brrt oh, wait a minute
10:24 timotimo we waited almost half an hour! :P
10:30 brrt hmmm
10:31 brrt i feel like there could be an interaction between 'full' and 'point' spills
10:31 brrt but this is a case of register allocator gone mad anyway
11:07 brrt yeah, this is interaction between full and point spills alright
11:08 brrt the tl;dr
11:08 brrt i may need to spill-to-allocate a register for the CALL result
11:28 brrt 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:30 domidumont joined #moarvm
11:31 brrt so it's an ordering issue again
11:37 brrt hmmm
12:24 domidumont1 joined #moarvm
12:41 zakharyas joined #moarvm
12:54 geekosaur joined #moarvm
13:37 brrt joined #moarvm
13:37 * brrt mumbles something about people arguing markdown is more readable than POD
13:39 eveo 'cause obviously it is.
13:39 eveo :)
13:39 brrt srsly though
13:40 brrt markdown has no formal specification, isn't strictly speaking 'parseable', and has a gazillion dialect
13:40 brrt s
13:40 brrt how is that… better, in any reasonable sense
13:41 brrt i ???? for engineering
13:41 eveo I am serious. L«C<some code>|/foo/bar» vs [`some code`](/foo/bar). B<SHOUT> vs **SHOUT**
13:41 eveo Markdown is way easier to type too
13:41 brrt that is nothing but convention and familiarity, and you know it
13:42 brrt what is harder or easier about the one or the other
13:42 brrt they use approximately as many punctuation characters
13:42 eveo No, it's all about typing angular brakets, without the help of things like Emmet that lets you avoid doing that with HTML
13:42 brrt .. typing angular brackets is horrible, typing stars and square brackets is not?
13:42 eveo Nope
13:43 eveo 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
13:43 eveo "that" being what? That's is physically easier to type `` than C<> ?
13:43 robertle I wonder whether some language preferenfces may have something to do with the keyboard layout in question ;)
13:44 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
13:44 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
13:44 eveo I use 6 finger typing
13:44 brrt robertle: ????
13:45 brrt well, there you go
13:45 brrt you type one way, i type another. there is no 'objectivity' about the easiness in typing there
13:45 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?
13:45 eveo "C" = left pinkie + left index; "<" = right ring finger + right thumb<; ">" = same
13:46 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?
13:46 brrt * is… exactly the same, just a bit further to reach
13:46 brrt lol
13:47 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
13:47 eveo Your argument about readability ends right there, I'd say.
13:47 * eveo goes to do productive stuff.
13:47 nine eveo: sorry, but no *bold*, /italic/, _underline_. I have no idea why we suddenly have to double the markers.
13:47 brrt nine: that's org-mode syntax, that's not going to work with markdown unfortuantely
13:48 brrt **bold**, *italic*, _underline_ <- i'm not sure that even works
13:48 nine My irssi even underlines the "underline" there ;)
13:48 brrt hehe
13:49 brrt anyway, yeah, it's bikeshedding. but the 'obviousness' of it all surprised me
13:49 brrt don't worry. you can type markdown all you like
13:49 brrt it's just that you're wrong :-P
13:51 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...
13:52 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
13:52 * brrt nods
13:53 brrt good for the soul
13:58 brrt so one of the possible solutions for the point/full-spill interaction is to….  add another layer of indirection
13:58 brrt i don't much like that though
14:38 domidumont joined #moarvm
14:54 domidumont joined #moarvm
15:10 brrt joined #moarvm
15:11 ggoebel joined #moarvm
15:27 domidumont joined #moarvm
15:56 Geth ¦ MoarVM/even-moar-jit: 266b60f606 | (Bart Wiegmans)++ | 2 files
15:56 Geth ¦ MoarVM/even-moar-jit: Describe point/full spill conflict
15:56 Geth ¦ MoarVM/even-moar-jit:
15:56 Geth ¦ MoarVM/even-moar-jit: This conflict causes failures during NQP build when sp_fastcreate is
15:56 Geth ¦ MoarVM/even-moar-jit: enabled. A point spill will ignore the full spill and potentially
15:56 Geth ¦ MoarVM/even-moar-jit: overwrite the value that it was spilled for.
15:56 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/266b60f606
15:58 brrt this is one of those core assumptions gone bad deals...
15:58 brrt but, i'll figure something out :-)
16:09 lizmat devirt: repr op getattrs_o couldn't be devirtualized: type unknown   # found in MVM_JIT_LOG, should we be worried ?
16:10 jnthn No
16:11 jnthn It just means an optimization it sometimes has the info to do can't be done in this case
16:11 jnthn 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
16:13 lizmat could this trigger it showing up as not-JITted in --profile ?
16:13 lizmat because the log states this particular method *did* get JITted
16:14 lizmat ah, or it could mean it got deoptimized
16:15 lizmat 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:16 lizmat Of 1002426 specialized or JIT-compiled frames, there were 4744 deoptimizations (that's 0.47% of all optimized frames).
16:16 lizmat jnthn: is that expected behaviour?  that it JITs something again and again, and deoptimizes again and again ?
16:16 jnthn That's not really what happens
16:17 jnthn Or at least, I highly doubt it
16:17 jnthn It may run the JITted code and fall out of it
16:17 jnthn Many times
16:17 jnthn But that isn't producing fresh JIT code every time
16:18 jnthn 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?
16:18 lizmat so it *is* potentially unnecessary overhead ?
16:18 jnthn Potentially we come out worse at times
16:18 jnthn It's hard to say in general though
16:18 jnthn I mean, if you run JITted
16:19 jnthn And then after it does some owrk hit a depot
16:19 jnthn Then you can still find that the savings of being in the specialized/JITted code exceed the cost of the deopt later
16:19 jnthn But yes, at present we hedge on deopt being rare
16:19 jnthn And don't have a strategy for backing out common deopts
16:20 jnthn 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 ?
16:21 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 jnthn Well, I know it is 'cus that's how I've done it in the past
16:22 jnthn 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 jnthn And then trying to map that back up to what Perl 6 code was originally compiled into that bytecode :)
16:23 lizmat feels like something that could be optimized ?
16:23 jnthn In what sense?
16:23 lizmat s/optimized/automated/
16:23 jnthn Ah
16:23 jnthn Well, ideally at some point we'd be able to incldue it in the profile output too
16:23 jnthn We can probably go so far as saying a line number, an expected type, and an actual type
16:25 lizmat that would be cool  :-)
16:25 jnthn As usual, it's all about the tuits :)
16:26 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 :)
16:28 jnthn Tomorrow I'll continue on with the Proc stuff
16:28 jnthn I guess next job is Proc::Async on JVM
16:28 jnthn And then re-implementing Proc using Proc::Async
16:28 jnthn And then killing off yet more code
16:29 jnthn We might soon get to the point where we no longer need to build up a libuv event loop per thread
16:29 jnthn And can just have the one running for async I/O, timers, etc.
16:30 lizmat sounds like a big improvement  :-)
16:30 jnthn Well, guess it has to save us something :)
16:33 * jnthn wanders home
16:33 jnthn Will hopefully get my blog post finished this evening. :)
16:46 robertle joined #moarvm
17:41 lizmat joined #moarvm
17:44 zakharyas joined #moarvm
19:49 patrickz joined #moarvm
20:24 praisethemoon joined #moarvm
20:24 praisethemoon joined #moarvm
20:30 brrt joined #moarvm
20:34 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.
20:36 brrt in case we'd do trace compilation, that tradeoff gets amplified
20:37 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)
20:39 brrt i'm pondering killing off point spilling as a strategy
20:43 brrt it's basically never legal to point-spill something that is then later respilled
20:44 brrt so, how to avoid it, other than not doing at all
20:44 brrt and what is the complexity of replacing it with a full spill
20:51 jnthn Well, yeah, the more you speculate, the bigger the potential losses. :)
21:14 brrt jnthn: have plans to go to the new yapc::eu / TPC::EU?
21:24 tbrowder_ joined #moarvm
21:29 leego_ joined #moarvm
21:39 ggoebel joined #moarvm
21:41 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
22:02 samcv i'm going to add some more ops
22:03 timotimo "ops i did it again"
22:03 samcv for ignorecase + ignaremark
22:03 samcv for index and for eqat
22:03 samcv equaticim_s i suppose and indexicim_s
22:04 samcv 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:06 lizmat samcv++
22:06 samcv :-)
22:06 lizmat but how will that affect the JVM ?
22:06 samcv no effect
22:06 samcv JVM doesn't have NFG anyway. so i think it can't do it?
22:06 jnthn I think these are only spat out by the regex compiler?
22:06 samcv ^
22:06 samcv that too
22:07 jnthn And that code is per-VM
22:08 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:16 samcv \o/ yay works.
22:16 samcv just gotta polish this up
22:41 geekosaur joined #moarvm
22:55 TimToady joined #moarvm
23:02 jnthn Phew, finally got my blog post finished. https://6guts.wordpress.com/2017/06/08/sorting-out-synchronous-io/ :)
23:02 jnthn timotimo: I think I might record them separately from the call graph
23:03 jnthn timotimo: Probably just (file, line, expected) as the key and a list of got as the value
23:03 jnthn Hm, though
23:03 jnthn Maybe line isn't specific enough and will be misleading
23:03 timotimo don't we want to differentiate different spesh candidates?
23:03 jnthn Not really
23:03 timotimo also, yeah, inlines will give you jumpy line numbers, too
23:03 jnthn Yeah, though we need to fix that more generally anyway :)
23:04 timotimo what's there to fix? it's in the nature of the thing
23:05 jnthn We can emit a new annotations segment when we emit the bytecode, I guess :)
23:07 timotimo i'm not sure what the end result would look like
23:07 timotimo 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?
23:09 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:10 jnthn To do that you'd need to use the inlines table of the spesh candidate
23:16 timotimo i didn't realize we didn't just copy the annotations over while inlining
23:18 jnthn 'night, #moarvm
23:19 timotimo gnite jnthn :)
23:43 samcv nite
23:46 timotimo i'll go to sleep now, too

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary