Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-08-18

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

All times shown according to UTC.

Time Nick Message
01:52 ilbot3 joined #moarvm
01:52 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
02:39 pharv_ joined #moarvm
03:35 greppable6 joined #moarvm
03:35 evalable6 joined #moarvm
03:43 Geth ¦ MoarVM: MasterDuke17++ created pull request #649: Add hostname to failed to resolve error
03:43 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/649
04:37 samcv MasterDuke, why do you use char *waste[] = { host_cstr, NULL }
05:54 samcv MasterDuke, ah nvm i see that is what the function expects. to mark the end of the list of pointers
05:55 Geth ¦ MoarVM: 1aed82c35c | MasterDuke17++ | src/io/syncsocket.c
05:55 Geth ¦ MoarVM: Add hostname to failed to resolve error
05:55 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/1aed82c35c
05:55 Geth ¦ MoarVM: 7eb69fc167 | (Samantha McVey)++ (committed using GitHub Web editor) | src/io/syncsocket.c
05:55 Geth ¦ MoarVM: Merge pull request #649 from MasterDuke17/add_hostname_to_failed_to_resolve_error
05:55 Geth ¦ MoarVM:
05:55 Geth ¦ MoarVM: Add hostname to failed to resolve error
05:56 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7eb69fc167
06:09 brrt joined #moarvm
06:37 Geth ¦ MoarVM: 9c578330f7 | (Stefan Seifert)++ | src/jit/graph.c
06:37 Geth ¦ MoarVM: JIT MVM_OP_param_rp_o
06:37 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9c578330f7
07:02 brrt joined #moarvm
07:11 brrt good * #moarvm
07:20 nwc10 good *, brrt
07:27 brrt ohai nwc10
07:56 zakharyas joined #moarvm
08:06 Geth ¦ MoarVM: 84f426ecaa | (Stefan Seifert)++ | src/jit/graph.c
08:06 Geth ¦ MoarVM: JIT param_rp_i
08:06 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/84f426ecaa
08:12 brrt joined #moarvm
08:18 domidumont joined #moarvm
08:19 robertle joined #moarvm
08:23 domidumont joined #moarvm
08:26 brrt joined #moarvm
08:33 nine Is it true that even-moar-jit cannot just reduce unnecessary LOAD/STOREs but also unnecessary boxing/unboxing?
08:35 jnthn I doubt it can avoid the box/unbox stuff; that's something that'd probably want doing during the spesh phase
08:35 yoleaux 01:22Z <AlexDaniel> jnthn: if I tap on $procasync.stdout (without :bin), what kind of data am I getting? And what kind of assumptions can I have about it?
08:35 yoleaux 01:22Z <AlexDaniel> jnthn: I'm asking because I was expecting lines (stuff separated by \n), but apparently this is a dumb assumption given the limit of 65536
08:37 jnthn .tell AlexDaniel You're getting what you'd get with :bin fed into a streaming decoder, then with everything that's "ready" taken out of it; bytes representing incomplete codepoints in the encoding, or codepoint(s) that might form a grapeheme with what comes next, will be held back.
08:37 yoleaux jnthn: I'll pass your message to AlexDaniel.
08:38 jnthn .tell AlexDaniel Note that you can use $procasync.stdout.lines to have the output broken up into lines as it arrives if that's what you want.
08:38 yoleaux jnthn: I'll pass your message to AlexDaniel.
08:42 brrt boxing/unboxing is currently invokish
08:43 brrt in the general case that would be very, very hard
08:43 brrt and if even-moar-jit can do it, spesh should also be able to
08:43 brrt (it'd operate on the same 'level' of data)
08:43 brrt that said
08:50 zakharyas joined #moarvm
08:51 Ven joined #moarvm
08:55 jnthn box/unbox ain't invokish
08:55 jnthn decont is
08:59 nine So what does invokish mean in this context?
08:59 jnthn May invoke soemthing
09:00 jnthn For example, decont may just read a memory location in the best case, but in the case of PROXY may run the FETCH
09:00 nine invoke a C function or a HLL routine?
09:01 jnthn HLL
09:01 jnthn Which means changing the current sub, and thus bytecode/JIT code
09:01 nine Yep, I can see how that can make a whole lot of difference :)
09:25 btyler joined #moarvm
09:39 brrt joined #moarvm
10:13 brrt joined #moarvm
10:16 brrt box aint invokish?
10:16 brrt oh
10:19 jnthn Hmm, just looking at how we JIT decont
10:19 jnthn Which is invokish
10:19 jnthn And don't see how we handle the invoke case
10:19 jnthn Oh, but maybe we don't have to...
10:20 jnthn 'cus the guard is added as a general case based on the flag :)
10:23 brrt aye
10:23 brrt i'm thinking of changing that from a per-op flag to a per-template flag, or, maybe to have a template be able to override it
10:24 brrt jnthn, i was thinking of splitting the changes to the legacy jit from even-moar-jit, and then rebasing even-moar-jit on top of that
10:24 brrt that would mean closing the current PR, fwiw
10:24 jnthn Ah...I guess I can continue off reviewing where I got to
10:24 jnthn Had so little time to do that :S
10:26 brrt well, fixing stuff is actually a bit more important :-)
10:28 brrt i'd expect that the merge conflicts which are regular in the even-moar-jit branch would be a bit less frequent then
10:32 dogbert17 have anyone here glanced at timotimo's latest Coverity Scan results?
10:33 brrt glanced, not done anything about them :-(
10:33 brrt plenty of them are high priority actually
10:35 dogbert17 indeed
10:41 dogbert17 would the missing break statement here cause any problems? https://github.com/MoarVM/MoarVM/blob/master/src/spesh/optimize.c#L2059
10:45 jnthn No, but it's sloppy
10:51 Geth ¦ MoarVM: 167b20fab2 | (Jonathan Worthington)++ | src/jit/graph.c
10:51 Geth ¦ MoarVM: Basic JIT of cas_o, atomicload_o, atomicstore_o.
10:51 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/167b20fab2
11:06 brrt joined #moarvm
11:06 brrt heh, i'd expected you to have to write assembly for that
11:07 brrt (for the atomic ops i mean)
11:08 jnthn Oh, if only we could lower them so far :)
11:08 jnthn We can't for Scalar containers yet
11:08 jnthn For the same reason we can't lower assignments in general to just pointer writes yet
11:09 jnthn Which is that spesh can't toss assignment type checks yet
11:17 brrt :-(
11:23 jnthn Aww, something I figured might be a nice op causes spectest failures
11:23 jnthn sub foo($a) { }
11:24 jnthn Today will wrap whatever is passed into a new ro Scalar container
11:24 jnthn To make sure it doesn't flatten
11:24 jnthn When it's
11:24 jnthn sub foo(Int $a) { }
11:24 jnthn It notes Int !~~ Iterable and Iterable !~~ Int so it doesn't bother
11:25 jnthn So I figured, ah, but if we emit an istype Iterable check into the code we can compile then we can conditionally wrap it at runtime
11:25 jnthn Which is more code *but* spesh can strip it out
11:26 jnthn Which is pretty much does (yay)
11:26 jnthn But some odd spectest fails crop up
11:26 nine Maybe it again just reveals some hidden breakage?
11:28 jnthn What on earth...
11:28 jnthn cmp-ok ().item.VAR, '===', ().item.perl.EVAL.VAR, '().item .perl.EVAL roundtrip preserves itemization';
11:29 jnthn Another failure is because it wants the variable's name when you assign to a readonly thing, which is a bit less available now
11:30 jnthn Since it relies on the throw-away wrapping
11:30 jnthn Well, pointless wrapping
11:31 jnthn Hmm, guess theres's no way I'm getting away wiht this patch this side of the release
11:31 nine :(
11:31 jnthn Mostly was doing it 'cus I looked at spesh output and then went and changed $ to \ in some sigs then thought, hmm, but spesh can do this for us...
11:31 jnthn And it'll be a potentially huge number of allocations saved
11:32 jnthn Lunch now, but will push my patch after in a branch for anyone who wants to tinker
11:32 jnthn bbs
11:49 nine 5.718s!
11:49 nine jnthn: at least your experiment gave me a way to further optimize Inline::Perl5
11:52 nine btw. came across this oddity:
11:52 nine m: sub foo returns int32 { int32.new(0) }; multi sub bar(int32 \v) { }; bar(foo)
11:52 camelia rakudo-moar a30ce6: OUTPUT: «Cannot resolve caller bar(Int); none of these signatures match:?    (int32 \v)?  in block <unit> at <tmp> line 1??»
12:03 nine csv-ip5xs.pl is now ~ 33 times slower than csv-test-xs.pl btw.
12:04 brrt (is that better or worse?)
12:08 nine Oh that's the best result so far
12:12 brrt :-)
12:30 zakharyas joined #moarvm
12:36 jnthn Also got a CAS-heavy benchmark down from ~4s to ~2.5s
12:36 jnthn https://gist.github.com/jnthn/270633f76db049a52999cdb63a00df27 fwiw
12:38 Geth ¦ MoarVM: 779ba84131 | (Jonathan Worthington)++ | src/spesh/log.h
12:38 Geth ¦ MoarVM: Raise threshold on static frame logging.
12:38 Geth ¦ MoarVM:
12:38 Geth ¦ MoarVM: If various threads are logging it, then we can end up in a situation
12:38 Geth ¦ MoarVM: where no thread logs enough to send a buffer that marks the frame as
12:38 Geth ¦ MoarVM: hot. So boost this threshold to cope with that. Gets a lot more things
12:38 Geth ¦ MoarVM: specialized/JITted in a multi-threaded benchmark.
12:38 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/779ba84131
12:43 jnthn Mebbe we can do a bit better in some cases by avoiding the checks in https://github.com/MoarVM/MoarVM/blob/master/src/6model/containers.c#L534 for a known type and known concrete
12:44 jnthn then we can just JIT into a call to the function pointer
12:44 brrt heh, yeah
12:44 brrt seems legit
12:45 jnthn Guess it saves some cycles :)
12:45 * brrt wonders if the expr jit could automate that
12:45 brrt i mean, the concretness check is explicit enough
12:46 brrt and if we have a node that represents a spesh op, and its facts tells us that we have concrete op, then why not….
12:47 brrt known concrete removes one part, known type replaces the load of the containerspec function pointer with a constant pointer
12:47 brrt seems doable
12:47 jnthn Yeah, doing it now
12:47 jnthn Oh, not the clever thing
12:47 jnthn Just the by hand thing
12:48 jnthn But yeah, it had occurred to me that if in our op defs we were more declarative about this
12:48 jnthn Then we could do better
12:48 nine One can never be too declarative...
12:49 brrt plenty of flag space leftover :-)
12:49 brrt but the opt is generic enough to generalize
12:51 Geth ¦ MoarVM: duke-m++ created pull request #650: removing test that will always fail
12:51 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/650
12:51 Geth ¦ MoarVM/even-moar-jit: 1a164f8359 | Mario++ (committed using GitHub Web editor) | src/6model/reprs/VMArray.c
12:51 Geth ¦ MoarVM/even-moar-jit: removing test that will always fail
12:51 Geth ¦ MoarVM/even-moar-jit:
12:51 Geth ¦ MoarVM/even-moar-jit: MVMuint64 (uint64) will always be positive
12:51 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/1a164f8359
12:51 Geth ¦ MoarVM/even-moar-jit: 51914ae99f | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/6model/reprs/VMArray.c
12:51 Geth ¦ MoarVM/even-moar-jit: Merge pull request #650 from duke-m/patch-1
12:51 Geth ¦ MoarVM/even-moar-jit:
12:51 Geth ¦ MoarVM/even-moar-jit: removing test that will always fail
12:51 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/51914ae99f
13:00 jnthn Huh, curious, that was agaisnt even-moar-jit
13:00 jnthn Didn't notice
13:01 jnthn Ah well, guess we get it in master
13:01 brrt hehe, yeah, well, i'm going to rebase even-moar-jit anyway, so this will probably drop out anyway
13:02 brrt i'm fairly sure that was already merged on amster
13:02 brrt *master
13:39 Geth ¦ MoarVM: ddd7449acc | (Jonathan Worthington)++ | 9 files
13:39 Geth ¦ MoarVM: Less checks and better JIT on container atomics.
13:39 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ddd7449acc
13:39 Geth ¦ MoarVM: 075a6a56d6 | (Jonathan Worthington)++ | src/spesh/facts.c
13:39 Geth ¦ MoarVM: We know cas_o and atomicload_o are decont-y.
13:39 Geth ¦ MoarVM:
13:39 Geth ¦ MoarVM: So flag that up in facts, thus allowing a p6decontrv to go away, which
13:39 Geth ¦ MoarVM: further cheapens the cas function.
13:40 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/075a6a56d6
13:40 jnthn That's probably as good a JIT of the container ones as we'll get for the time being
13:41 jnthn (Without a load more work to make spesh understand Scalar containers better)
13:50 dogbert17 does that mean you're done with the atomics
13:51 jnthn No, still need to look at how we might spesh/JIT the native int ones
13:53 dogbert17 will it be tricky to fix?
13:54 jnthn Well, a quick "just call the function" JITting should in theory be easy
13:55 jnthn Though I'm not sure how spesh feels about native references...
14:05 jnthn Wow, yeah, JITting the cas_i won't help at all
14:05 jnthn oh, I misread
14:05 jnthn ah, indeed
14:06 jnthn No, it won't unless I fix something else first
14:06 jnthn After spesh
14:06 jnthn an argument `int $target is rw`
14:06 jnthn is still
14:06 jnthn sp_getarg_o       r2(2), liti16(0)
14:06 jnthn iscont_i          r8(1),   r2(2)
14:06 jnthn assertparamcheck   r8(1)
14:06 brrt joined #moarvm
14:07 jnthn oh, actually
14:07 jnthn the latter two do JIT already :)
14:07 raschipi joined #moarvm
14:17 brrt i thik timmotimo did that one at some point
14:19 jnthn bah, being able to JIT cas_i doesn't change much at all
14:20 jnthn Probably 'cus it ain't a very clever JITting
14:28 Geth ¦ MoarVM: c92516179e | (Jonathan Worthington)++ | src/jit/graph.c
14:28 Geth ¦ MoarVM: Basic JITting of all the CAS integer ops.
14:28 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c92516179e
14:38 Zoffix joined #moarvm
14:41 dogbert17 oops: MoarVM panic: Must not GC when in the specializer/JIT
14:42 jnthn ooh
14:42 jnthn Hww'd you trigger that one?
14:42 dogbert17 I ran this a few times: MVM_SPESH_NODELAY=1 ./perl6-m t/spec/S03-operators/set_symmetric_difference.t
14:44 dogbert17 the backtrace in gdb looks a bit bizarre, masses of 0xb7ca79ff in optimize_bb (tc=tc@entry=0x808d388, g=<optimized out>, bb=0xb4eed494, p=0xb4638c24) at src/spesh/optimize.c:2108
14:44 jnthn With GC debug turned on, I guess?
14:45 dogbert17 yes, set to 2
14:45 jnthn yeah, worth a MoarVM issue
14:46 dogbert17 coming up, I ran an entire spectest with GC_DEBUG and MVM_SPESH_NODELAY=1, got a few filing files I haven't seen before
15:00 AlexDaniel joined #moarvm
15:08 Geth ¦ MoarVM: cc51d9b8e5 | (Jonathan Worthington)++ | src/spesh/optimize.c
15:08 Geth ¦ MoarVM: Specialize iscont and iscont_[ins].
15:08 Geth ¦ MoarVM:
15:08 Geth ¦ MoarVM: The latter improves parameter handling specialization for code that
15:08 Geth ¦ MoarVM: takes native references, which in turn means that should code could be
15:08 Geth ¦ MoarVM: inlined (although that is seemingly not happening today).
15:08 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/cc51d9b8e5
15:10 jnthn Enough for today. I guess on Monday I'll see if I can get it to be able to inline those
15:10 jnthn It's not even fastinvoke'ing them
15:11 jnthn I guess something to do with something somewhere not grokking native ref arguments
15:11 dogbert17_ joined #moarvm
15:11 brrt joined #moarvm
15:12 jnthn I figure spending the time making those inline will give a bigger win than trying to make the cas_i and friends themselves go faster
15:12 jnthn Since it's by now a tiny callframe
15:12 jnthn uh, tiny amount of code in the frame I mean
15:22 nine jnthn: with your new commits I'm down to 5.436s or 31x slower than Perl 5 :)
15:23 jnthn Oh, I managed to speed your stuff up too? :)
15:23 jnthn Surprise bonus :D
15:23 nine Inline::Perl5 does use native references quite a bit
15:23 jnthn Ah
15:32 dogbert17_ jnthn: grab a cold beer
16:31 robertle joined #moarvm
16:53 raschipi left #moarvm
16:53 japhb joined #moarvm
16:56 raschipi joined #moarvm
17:10 dogbert17 joined #moarvm
17:33 zakharyas joined #moarvm
17:55 zakharyas joined #moarvm
19:22 domidumont joined #moarvm
20:36 dogbert17 jnthn: https://github.com/MoarVM/MoarVM/issues/651
20:44 jnthn dogbert17: Thanks :)
20:44 yoleaux 20:28Z <Zoffix> jnthn: what's atomicsize? The docs mention it, but never say what it is
20:44 jnthn huh, I wrote a doc for it saying exactly what it is o.O
20:44 Zoffix Oh, lemme search entire repo instead of one page >_<
20:45 Zoffix jnthn: don't see it
20:45 jnthn Zoffix: https://github.com/perl6/doc/blob/master/doc/Type/atomicint.pod6#L3
20:46 jnthn Doesn't show up on doc.perl6.org for some reason
20:46 Zoffix jnthn: that's atomicINT I'm asking about atomicSIZE /me is confused
20:46 jnthn oh
20:46 jnthn uh, where did you see it mentioned?
20:46 jnthn oh, I see
20:46 jnthn It's a thinko, d'oh
20:46 jnthn Should say atomicint
20:47 jnthn Maybe I was thinking "the size of C<atomicint>" and then wrote atomicsize :P
20:47 Zoffix OK, I'll change it
20:48 jnthn Fixed
20:48 jnthn Oh, heh :)
20:49 Zoffix ok :)
20:53 domidumont joined #moarvm
21:37 timotimo the thing where we gc inside spesh is because i didn't merge the code that makes sure all wvals are safe before trying to inline stuff
21:38 timotimo we should just reject speshing a frame that has such a thing
21:38 timotimo though it's not guaranteed that the wval will ever be deserialized if we just wait
21:39 timotimo so i'm not sure whether refusing to spesh such a frame will cause it to either not be speshed for a much longer time or that it shows up again every plan from then on
21:39 timotimo well, i expect it'll try re-speshing after a bunch of matching invocations got logged again
21:40 MasterDuke joined #moarvm
21:46 MasterDuke anybody have a problem with https://github.com/MoarVM/MoarVM/pull/638 ? it's just changes in comments
21:51 timotimo perhaps the thing about control exceptions was meant to be in the comment block following that one
21:57 MasterDuke could be, but i definitely don't know enough about that code to say
22:21 dogbert17 samcv, timotimo: dunno if it's of any interest, but one of the coverity scan errors pertains to MVM_unicode_string_compare
22:21 samcv yeah i saw that. the function is going to change a lot so it's okay
22:21 samcv i mean i have stuff not merged in yet
22:22 dogbert17 cool, just wanted to mention it
22:23 timotimo i'll go to bed soon and will probably not be here for almost all of tomorrow
23:42 Geth ¦ MoarVM: bf437fc54d | (Samantha McVey)++ | 3 files
23:42 Geth ¦ MoarVM: Introduce NFG_CHECK which checks string is in NFG form
23:42 Geth ¦ MoarVM:
23:42 Geth ¦ MoarVM: * MVM_DEBUG_NFG, if 1, any calls to NFG_CHECK will re_nfg the given string
23:42 Geth ¦ MoarVM:   and compare num_graphs before and after the normalization.
23:42 Geth ¦ MoarVM: * If it is different debug information will be printed out.
23:42 Geth ¦ MoarVM:
23:42 Geth ¦ MoarVM: * MVM_DEBUG_NFG_STRICT does as above but does not only rely on num_graphs.
23:42 Geth ¦ MoarVM: <…commit message has 6 more lines…>
23:42 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/bf437fc54d

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