00:52 geekosaur joined 01:49 ilbot3 joined 01:55 colomon joined 05:37 brrt joined 05:59 domidumont joined
brrt brain is not producing any inspiration for the JIT today... 06:03
06:05 domidumont joined
brrt let's see where we were 06:10
i've added the opr_kind to the JIT expr info
(so to the 'metadata' nodes)
happily, those are 0 if not defined 06:11
saves me a bug of difficulty
that wasn't grammar 06:13
anyway
what i need to do now is associate them with the live ranges 06:14
the thing after that is to have a 'type' specific memroy-location allocator
06:48 brrt joined 06:55 domidumont joined 07:40 sivoais joined
brrt the association with live ranges is where my brain is drying up 07:52
so lets try and figure that out
- if something is 'basic', then obviously, the type of the value is the same as the type of the node it represents
- if a copy of some sort (DO/COPY pseudotile), then.. 07:53
- either the copied value has a type and the DO/COPY does not, in which case nothing changes 07:54
- or the DO/COPY has some value, and the copied value has not, in which case we assign the copied values' type 08:03
- or they both have a value and it agrees, in which case we're ok 08:04
-or it doesn't agree
the same thing is kind of true of IF / PHI nodes
samcv i know that feeling about not as much inspiration :P 08:09
you seem to be working with it though :)
brrt :-) 08:12
so there's another thing i didn't think of...
if we load a value directly from a local, it should kind of agree with the local types map
and indeed, set and getlex don't have a type, i think 08:13
okay, in that case, we kind of want to use the local_types map 08:19
08:34 robertle_ joined 08:45 geekosaur joined
lizmat www.reddit.com/r/perl6/comments/6h...o_gnu_yes/ # wonder how Perl 6 is doing after jnthn's latest refactoring 08:46
jnthn morning #moarvm 08:53
lizmat: Haven't looked much at output yet, though it's certainly not anything like so speedy as it could be 08:55
samcv yeah it does seem a bit slow lizmat 09:01
hm
not as slow as they show 09:02
getting 250-280KiB/s
jnthn But anyway, yes output has gotten slower, 'cus it calls .encode, which normalizes the encoding every time through and so forth 09:03
samcv i can get 3.4MB using nqp::say
if i set it to a variable i get way faster speeds 09:04
hmm now it went down
hmm looks like a fluk? idk i got 3 mb on perl 6 code and now it's back to what it was at before only a tiny bit faster 09:05
jnthn, any way to cache it on the user code side? 09:06
i can go from 270 to 380KB/s by doing $*OUT.open 09:10
jnthn huh, I don't know how $*OUT.open would change anything :S 09:19
09:20 zakharyas joined
jnthn Urgh. So it turns out that actually coping with deopt during args processing is even trickier as we need to recreate the args processing context 09:44
Uh, in the inline case I mean 09:45
But it also turns out that my "did we deopt" check was wrong too (it checked everywhere, not just in the args processing region)
This is especially good in that it means I can do a much simpler and far more localized change and get the inlining I was hoping for, rather than a bunch of wider-ranging and delicate chances. 09:54
*changes
Geth MoarVM: ebe2bb0b38 | (Jonathan Worthington)++ | src/spesh/args.c
Correct deopt check when removing named arg marks.

We only care about whether there is a deopt point during argument processing. If there isn't, we can safely strip out the tracking. It's only when there is that we must leave the tracking in place, which in turn prevents inlining. Previously we tracked it there was a deopt anywhere in the routine, rather than just up to the end of argument processing.		 10:03
jnthn Another couple of percent from that inlining.
Not quite so much as I'd hoped, but still
10:13 brrt joined
jnthn Currently I've reached the point where things are faster than before the I/O refactors in my for/lines thing 10:43
But many of the opts should help more generally 10:44
eveo awesome 10:52
11:00 zakharyas joined
jnthn callgrind++ # telling me when a microoptimization is actually making things worse 11:11
lunch & 11:16
brrt jnthn++ awesome! 11:40
dogbert17 jnthn++ optimizations 11:57
12:20 colomon joined
jnthn back 12:21
So, how shall I optimize this thing next... 12:22
dogbert17 does callgrind show anything in need of opts? 12:23
[Coke] Are you still opting the char counter? 12:24
jnthn [Coke]: Yes, except mostly what I've been finding so far has just been poor code-gen or poor spesh 12:25
[Coke]: Meaning the fixes should have implications far beyond that 12:26
[Coke] Would it be worthwhile to add a short "here's how I optimized this, and so can you." doc?
jnthn++
jnthn I'm not sure, in that most of the fixes are deep in code-gen or the specializer 12:27
I'll certainly blog about what I've done 12:28
And if there's anything generally useful I'm fine with it being lifted into the docs
[Coke] jnthn++ again. :)
jnthn So, what to optimize next... 12:29
jnthn has 3 things that all need work
lizmat volunteers as tie-breaker 12:30
jnthn Well, it's either doing the long-planned code-gen improvements for statementlist `for`, looking into utf-8 decoding, and looking into separator hunting
dogbert17 are they equally difficult you think? 12:31
jnthn Well, the `for` one I already know what to do up front :) 12:32
Though I know that when I do it, people will ask me to do the same but for more cases of it :P
lizmat perhaps then you won't need to do it yourself ?
jnthn Possibly :)
The idea is to have statementlist `for` compile into code that does a while loop that calls pull-one 12:33
Rather than go through sink-all
In simple cases. :)
The upshot of this is that we will typically end up with a monomorphic callsite at the pull-one rather than a megamorphic one 12:34
dogbert17 why not start with that one then, perhaps it can make to the next MoarVM release
jnthn Well, it's in Rakudo :)
But yeah
dogbert17 *make it*
jnthn digs in 12:35
dogbert17 lizmat: wasn't there some opt regarding map and grep which had to be removed because of some phaser problem a couple of months ago?
lizmat well, we still need an extra scope every now and then 12:36
dogbert17 it was a noticable change (at least in some of my code) 12:37
lizmat ah, grep you mean, with redo and stuff
dogbert17 yeah, that was it 12:47
13:07 zakharyas joined
eveo I did some digging for that reddit perf question and wrote a detailed answer: www.reddit.com/r/perl6/comments/6h...s/dixps6s/ 13:07
Looks like 50% of performance loss is actually in loop {} 13:08
lizmat I guess we need an opt that turns loop { } into postfix while 1 :-) 13:12
jnthn Or actually look at the generated code and figure out what's different :) 13:14
eveo Phaser support? 13:15
Which I'm assuming can be statically checked or something
eveo &
13:33 colomon joined
jnthn Well, seems I've got the better for code-gen for the simple loop case working 14:37
eveo \o/
jnthn Alas, spesh needs teaching to make the most of the new opportunities still.
But it's some more percent off at least :) 14:38
argh wat, suddenly new spectest failure after I fixed the only one I had left failing :/ 14:40
lizmat jnthn: param_rp_s what could be the cause of that ? 15:02
it's preventing &DYNAMIC from getting JITted 15:03
jnthn Means something didn't work out when it was trying to specialized something that takes a required positional string parameter 15:05
Though I don't know why the _s 'cus DYNAMIC is declared as \name 15:06
lizmat yeah, oops, that was after something I changed
turns out otherwise the JIT is being blocked by getlexreldyn
jnthn That one is probably fixable 15:07
lizmat then DYNAMIC could be JITted and loops with .say would be faster still :-) 15:08
15:11 brrt joined, zakharyas joined 15:15 AlexDaniel joined 15:16 evalable6 joined 15:17 bisectable6 joined, greppable6 joined
jnthn Found find_separator was missing an easy optimization 15:49
Though it is probable that it can be improved further also 15:50
(But by now we've had the big win, so it'll be smaller bits) 15:51
argh, and it breaks one spectest :/ 15:56
15:58 nwc10 joined
Geth MoarVM: 1f5be6a63a | (Jonathan Worthington)++ | src/strings/decode_stream.c
Make find_separator only look at the last chars.

Since there's no path where we'd be looking for the separator where we did not get it at the very end.		 16:25
jnthn m: say 1.866 / 2.004
camelia 0.931138
jnthn 7% improvement on line reading from that, and I think a fresher me in the morning can probably simplify that code a bit mroe too 16:26
eveo Sweet! 16:29
jnthn And there's still more places to look for opts :)
But I think my brane is frazzled enough by now. :) And the chili won't cook itself... 16:30
16:53 domidumont joined
Geth MoarVM: 5ea6aaab42 | jnthn++ | src/platform/win32/io.c
Don't barf on things we can't flush on Windows.
 17:41
19:29 AlexDaniel joined 20:03 colomon joined 20:25 praisethemoon joined 21:55 colomon joined
dogbert17 .seen samcv 22:01
yoleaux I saw samcv 21:11Z in #perl6: <samcv> and make them revert back to the old android designs. i don't think they understand how unicode works...
samcv hi
dogbert17 hi, have a doc question for you
do you think it would be ok to move the utf-c8 description from github.com/MoarVM/MoarVM/blob/mast...f8_c8.c#L3 to you unicode document? 22:02
I'm no expert on unicode perhaps something more is needed?
samcv like docs.perl6.org?
dogbert17 yeah, here's the issue: github.com/MoarVM/MoarVM/blob/mast...f8_c8.c#L3 22:03
github.com/perl6/doc/issues/1345
samcv ah yes
that would be a splendid idea. it's on my todo list now :) 22:04
dogbert17 cool ++samcv

Powered by Cro and the Raku® Programming Language.

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

Thank you!