01:52 ilbot3 joined 02:39 pharv_ joined 03:35 greppable6 joined, evalable6 joined
Geth MoarVM: MasterDuke17++ created pull request #649:
Add hostname to failed to resolve error		 03:43
samcv MasterDuke, why do you use char *waste[] = { host_cstr, NULL } 04:37
MasterDuke, ah nvm i see that is what the function expects. to mark the end of the list of pointers 05:54
Geth MoarVM: 1aed82c35c | MasterDuke17++ | src/io/syncsocket.c
Add hostname to failed to resolve error
 05:55
MoarVM: 7eb69fc167 | (Samantha McVey)++ (committed using GitHub Web editor) | src/io/syncsocket.c
Merge pull request #649 from MasterDuke17/add_hostname_to_failed_to_resolve_error

Add hostname to failed to resolve error
06:09 brrt joined
Geth MoarVM: 9c578330f7 | (Stefan Seifert)++ | src/jit/graph.c
JIT MVM_OP_param_rp_o
 06:37
07:02 brrt joined
brrt good * #moarvm 07:11
nwc10 good *, brrt 07:20
brrt ohai nwc10 07:27
07:56 zakharyas joined
Geth MoarVM: 84f426ecaa | (Stefan Seifert)++ | src/jit/graph.c
JIT param_rp_i
 08:06
08:12 brrt joined 08:18 domidumont joined 08:19 robertle joined 08:23 domidumont joined 08:26 brrt joined
nine Is it true that even-moar-jit cannot just reduce unnecessary LOAD/STOREs but also unnecessary boxing/unboxing? 08:33
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?
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
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.
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.
brrt boxing/unboxing is currently invokish 08:42
in the general case that would be very, very hard 08:43
and if even-moar-jit can do it, spesh should also be able to
(it'd operate on the same 'level' of data)
that said
08:50 zakharyas joined 08:51 Ven joined
jnthn box/unbox ain't invokish 08:55
decont is
nine So what does invokish mean in this context? 08:59
jnthn May invoke soemthing
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?
jnthn HLL 09:01
Which means changing the current sub, and thus bytecode/JIT code
nine Yep, I can see how that can make a whole lot of difference :)
09:25 btyler joined 09:39 brrt joined 10:13 brrt joined
brrt box aint invokish? 10:16
oh
jnthn Hmm, just looking at how we JIT decont 10:19
Which is invokish
And don't see how we handle the invoke case
Oh, but maybe we don't have to...
'cus the guard is added as a general case based on the flag :) 10:20
brrt aye 10:23
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
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
that would mean closing the current PR, fwiw
jnthn Ah...I guess I can continue off reviewing where I got to
Had so little time to do that :S
brrt well, fixing stuff is actually a bit more important :-) 10:26
i'd expect that the merge conflicts which are regular in the even-moar-jit branch would be a bit less frequent then 10:28
dogbert17 have anyone here glanced at timotimo's latest Coverity Scan results? 10:32
brrt glanced, not done anything about them :-( 10:33
plenty of them are high priority actually
dogbert17 indeed 10:35
would the missing break statement here cause any problems? github.com/MoarVM/MoarVM/blob/mast...ze.c#L2059 10:41
jnthn No, but it's sloppy 10:45
Geth MoarVM: 167b20fab2 | (Jonathan Worthington)++ | src/jit/graph.c
Basic JIT of cas_o, atomicload_o, atomicstore_o.
 10:51
11:06 brrt joined
brrt heh, i'd expected you to have to write assembly for that 11:06
(for the atomic ops i mean) 11:07
jnthn Oh, if only we could lower them so far :) 11:08
We can't for Scalar containers yet
For the same reason we can't lower assignments in general to just pointer writes yet
Which is that spesh can't toss assignment type checks yet 11:09
brrt :-( 11:17
jnthn Aww, something I figured might be a nice op causes spectest failures 11:23
sub foo($a) { }
Today will wrap whatever is passed into a new ro Scalar container 11:24
To make sure it doesn't flatten
When it's
sub foo(Int $a) { }
It notes Int !~~ Iterable and Iterable !~~ Int so it doesn't bother
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
Which is more code *but* spesh can strip it out
Which is pretty much does (yay) 11:26
But some odd spectest fails crop up
nine Maybe it again just reveals some hidden breakage?
jnthn What on earth... 11:28
cmp-ok ().item.VAR, '===', ().item.perl.EVAL.VAR, '().item .perl.EVAL roundtrip preserves itemization';
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:29
Since it relies on the throw-away wrapping 11:30
Well, pointless wrapping
Hmm, guess theres's no way I'm getting away wiht this patch this side of the release 11:31
nine :(
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...
And it'll be a potentially huge number of allocations saved
Lunch now, but will push my patch after in a branch for anyone who wants to tinker 11:32
bbs
nine 5.718s! 11:49
jnthn: at least your experiment gave me a way to further optimize Inline::Perl5
btw. came across this oddity: 11:52
m: sub foo returns int32 { int32.new(0) }; multi sub bar(int32 \v) { }; bar(foo)
camelia Cannot resolve caller bar(Int); none of these signatures match:? (int32 \v)? in block <unit> at <tmp> line 1??
nine csv-ip5xs.pl is now ~ 33 times slower than csv-test-xs.pl btw. 12:03
brrt (is that better or worse?) 12:04
nine Oh that's the best result so far 12:08
brrt :-) 12:12
12:30 zakharyas joined
jnthn Also got a CAS-heavy benchmark down from ~4s to ~2.5s 12:36
gist.github.com/jnthn/270633f76db0...b63a00df27 fwiw
Geth MoarVM: 779ba84131 | (Jonathan Worthington)++ | src/spesh/log.h
Raise threshold on static frame logging.

If various threads are logging it, then we can end up in a situation where no thread logs enough to send a buffer that marks the frame as hot. So boost this threshold to cope with that. Gets a lot more things specialized/JITted in a multi-threaded benchmark.		 12:38
jnthn Mebbe we can do a bit better in some cases by avoiding the checks in github.com/MoarVM/MoarVM/blob/mast...ers.c#L534 for a known type and known concrete 12:43
then we can just JIT into a call to the function pointer 12:44
brrt heh, yeah
seems legit
jnthn Guess it saves some cycles :) 12:45
brrt wonders if the expr jit could automate that
i mean, the concretness check is explicit enough
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:46
known concrete removes one part, known type replaces the load of the containerspec function pointer with a constant pointer 12:47
seems doable
jnthn Yeah, doing it now
Oh, not the clever thing
Just the by hand thing
But yeah, it had occurred to me that if in our op defs we were more declarative about this 12:48
Then we could do better
nine One can never be too declarative...
brrt plenty of flag space leftover :-) 12:49
but the opt is generic enough to generalize
Geth MoarVM: duke-m++ created pull request #650:
removing test that will always fail		 12:51
MoarVM/even-moar-jit: 1a164f8359 | Mario++ (committed using GitHub Web editor) | src/6model/reprs/VMArray.c
removing test that will always fail

MVMuint64 (uint64) will always be positive
MoarVM/even-moar-jit: 51914ae99f | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/6model/reprs/VMArray.c
Merge pull request #650 from duke-m/patch-1

removing test that will always fail
jnthn Huh, curious, that was agaisnt even-moar-jit 13:00
Didn't notice
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
i'm fairly sure that was already merged on amster 13:02
*master
Geth MoarVM: ddd7449acc | (Jonathan Worthington)++ | 9 files
Less checks and better JIT on container atomics.
 13:39
MoarVM: 075a6a56d6 | (Jonathan Worthington)++ | src/spesh/facts.c
We know cas_o and atomicload_o are decont-y.

So flag that up in facts, thus allowing a p6decontrv to go away, which further cheapens the cas function.
jnthn That's probably as good a JIT of the container ones as we'll get for the time being
(Without a load more work to make spesh understand Scalar containers better) 13:41
dogbert17 does that mean you're done with the atomics 13:50
jnthn No, still need to look at how we might spesh/JIT the native int ones 13:51
dogbert17 will it be tricky to fix? 13:53
jnthn Well, a quick "just call the function" JITting should in theory be easy 13:54
Though I'm not sure how spesh feels about native references... 13:55
Wow, yeah, JITting the cas_i won't help at all 14:05
oh, I misread
ah, indeed
No, it won't unless I fix something else first 14:06
After spesh
an argument `int $target is rw`
is still
sp_getarg_o r2(2), liti16(0)
iscont_i r8(1), r2(2)
assertparamcheck r8(1)
14:06 brrt joined
jnthn oh, actually 14:07
the latter two do JIT already :)
14:07 raschipi joined
brrt i thik timmotimo did that one at some point 14:17
jnthn bah, being able to JIT cas_i doesn't change much at all 14:19
Probably 'cus it ain't a very clever JITting 14:20
Geth MoarVM: c92516179e | (Jonathan Worthington)++ | src/jit/graph.c
Basic JITting of all the CAS integer ops.
 14:28
14:38 Zoffix joined
dogbert17 oops: MoarVM panic: Must not GC when in the specializer/JIT 14:41
jnthn ooh 14:42
Hww'd you trigger that one?
dogbert17 I ran this a few times: MVM_SPESH_NODELAY=1 ./perl6-m t/spec/S03-operators/set_symmetric_difference.t
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?
dogbert17 yes, set to 2 14:45
jnthn yeah, worth a MoarVM issue
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 14:46
15:00 AlexDaniel joined
Geth MoarVM: cc51d9b8e5 | (Jonathan Worthington)++ | src/spesh/optimize.c
Specialize iscont and iscont_[ins].

The latter improves parameter handling specialization for code that takes native references, which in turn means that should code could be inlined (although that is seemingly not happening today).		 15:08
jnthn Enough for today. I guess on Monday I'll see if I can get it to be able to inline those 15:10
It's not even fastinvoke'ing them
I guess something to do with something somewhere not grokking native ref arguments 15:11
15:11 dogbert17_ joined, brrt joined
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
Since it's by now a tiny callframe
uh, tiny amount of code in the frame I mean
nine jnthn: with your new commits I'm down to 5.436s or 31x slower than Perl 5 :) 15:22
jnthn Oh, I managed to speed your stuff up too? :) 15:23
Surprise bonus :D
nine Inline::Perl5 does use native references quite a bit
jnthn Ah
dogbert17_ jnthn: grab a cold beer 15:32
16:31 robertle joined 16:53 raschipi left, japhb joined 16:56 raschipi joined 17:10 dogbert17 joined 17:33 zakharyas joined 17:55 zakharyas joined 19:22 domidumont joined
dogbert17 jnthn: github.com/MoarVM/MoarVM/issues/651 20:36
jnthn dogbert17: Thanks :) 20:44
yoleaux 20:28Z <Zoffix> jnthn: what's atomicsize? The docs mention it, but never say what it is
jnthn huh, I wrote a doc for it saying exactly what it is o.O
Zoffix Oh, lemme search entire repo instead of one page >_<
jnthn: don't see it 20:45
jnthn Zoffix: github.com/perl6/doc/blob/master/d...nt.pod6#L3
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
jnthn oh
uh, where did you see it mentioned?
oh, I see
It's a thinko, d'oh
Should say atomicint
Maybe I was thinking "the size of C<atomicint>" and then wrote atomicsize :P 20:47
Zoffix OK, I'll change it
jnthn Fixed 20:48
Oh, heh :)
Zoffix ok :) 20:49
20:53 domidumont joined
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:37
we should just reject speshing a frame that has such a thing 21:38
though it's not guaranteed that the wval will ever be deserialized if we just wait
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
well, i expect it'll try re-speshing after a bunch of matching invocations got logged again
21:40 MasterDuke joined
MasterDuke anybody have a problem with github.com/MoarVM/MoarVM/pull/638 ? it's just changes in comments 21:46
timotimo perhaps the thing about control exceptions was meant to be in the comment block following that one 21:51
MasterDuke could be, but i definitely don't know enough about that code to say 21:57
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
i mean i have stuff not merged in yet
dogbert17 cool, just wanted to mention it 22:22
timotimo i'll go to bed soon and will probably not be here for almost all of tomorrow 22:23
Geth MoarVM: bf437fc54d | (Samantha McVey)++ | 3 files
Introduce NFG_CHECK which checks string is in NFG form

  * MVM_DEBUG_NFG, if 1, any calls to NFG_CHECK will re_nfg the given string
   and compare num_graphs before and after the normalization.
  * If it is different debug information will be printed out.
  * MVM_DEBUG_NFG_STRICT does as above but does not only rely on num_graphs.
... (6 more lines)		 23:42

Powered by Cro and the Raku® Programming Language.

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

Thank you!