Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-09-01

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

All times shown according to UTC.

Time Nick Message
00:00 buggable ???????????? It's time for the monthly Accidental /win Lottery ???????????? We have 12 ballots submitted by 8 users! DRUM ROLL PLEASE!...
00:00 buggable And the winning number is 14! Congratulations to nine! You win a can of WD40!
00:02 samcv woo
00:23 MasterDuke joined #moarvm
00:28 MasterDuke samcv: does this mean anything? `src/strings/unicode.c:73800:78: warning: unknown escape sequence: '\X'      {"KEYCAP: 6",342},{"KEYCAP: 7",343},{"KEYCAP: 8",344},{"KEYCAP: 9",345},{"KEYCAP: \X{23}",346},`
00:28 samcv well you can ignore it. eventually i'll fix it
00:28 MasterDuke k
00:28 samcv 23 is #
00:29 samcv 0x23.chr == #
00:29 samcv that one never worked anyway so just ignore it
00:29 MasterDuke easy enough
00:53 MasterDuke huh, perf shows that the second most expensive function when doing `./perl6-m tools/build/install-core-dist.pl /home/dan/Source/perl6/install/share/perl6` is MVM_sc_find_object_idx at 10%. never seen that one before in a profile
01:02 samcv MasterDuke, is that exclusive or inclusive
01:04 MasterDuke exclusive
01:05 MasterDuke i assume it's this loop: or (i = 0; i < count; i++) if (roots[i] == obj) return i;
01:05 samcv yeah
01:06 MasterDuke the largest value for count is 161211, which occurs 54727 times (the most of any of the values for count)
01:09 samcv well it's 3x worse if i start the for loop at the top instead of the bottom
01:10 samcv the scgetobjidx op calls it
01:34 Ven`` joined #moarvm
01:51 ilbot3 joined #moarvm
01:51 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:19 MasterDuke so instead of (incorrectly) jitting the param_op_* ops, i just make the arguments to INTERPOLATE non-optional
03:20 MasterDuke then, after jitting the eqat(ic|im|icim), it didn't cause any more BAILs
03:21 MasterDuke however, it still shows as not jitted in a profile (even though one of the loops inside it is shown as jitted)
03:21 MasterDuke why would that be? is it a problem? and is there a way to fix it if so?
04:04 Geth ¦ MoarVM: MasterDuke17++ created pull request #672: JIT eqat(ic|im|icim)
04:04 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/672
05:36 brrt joined #moarvm
05:56 brrt good hi #moarvm
06:44 brrt joined #moarvm
06:54 Geth ¦ MoarVM: deb5fbf35b | MasterDuke17++ (committed by Bart Wiegmans) | src/jit/graph.c
06:54 Geth ¦ MoarVM: JIT eqat(ic|im|icim)
06:54 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/deb5fbf35b
06:54 brrt rebase-and-merge is a thing these days
07:06 brrt old-style suffix rule works beautifully on nmake…. guess i was wrong in blaming it
07:12 nine Woohoo! One can never have enough WD40
07:13 Zoffix :)
07:14 nine MasterDuke: I've seen that, too. The profiler still showed some sub as red, while the JIT.log clearly showed that it was successfully JIT compiled.
07:15 brrt (WD40 is a lubrication oil?)
07:16 brrt also, may that be due to OSR maybe
07:18 nine brrt: it it moves when it shouldn't, use duct tape, if it doesn't move when it should, use WD40
07:18 brrt see, engineering is easy
07:29 brrt rebase coming on
07:29 Geth ¦ MoarVM/jit-legacy-cleanup: 25 commits pushed by (Bart Wiegmans)++
07:29 Geth ¦ MoarVM/jit-legacy-cleanup: review: https://github.com/MoarVM/MoarVM/compare/8e28708c1b...2aa92db4d2
07:41 buggable joined #moarvm
08:11 brrt i have something of a suggestion
08:20 squashable6 joined #moarvm
08:25 leont joined #moarvm
08:32 zakharyas joined #moarvm
08:39 samcv good hi brrt
08:40 timotimo i'm interested in this suggestion
08:45 samcv Hot off the presses! Unicode grant status update 4! https://cry.nu/perl6/grant-status-update-4/ tons of exciting things
08:47 brrt \o/
08:47 brrt oh, right, i was saying something
08:47 brrt hehe
08:49 brrt my suggestion. if we think perl6 performance is the biggest bottleneck. and if we think that we have something of a low-bus-factor with regards to performance optimization. and, if we haven't been able to get a group of perl6 and moarvm developers together for some time now, might it be time to do a perl6 performance 'workshop' day thing?
08:49 samcv what is this 'workshop' thing you speak of
08:49 brrt it is the suggestion
08:49 samcv i'm not even sure what a workshop is
08:50 brrt like a swiss perl workshop, london perl workshop, dutch perl workshop
08:50 samcv well i mean i sort of due. but it's not well enough defined for me
08:50 brrt it's not important at all
08:50 samcv ah ok
08:50 brrt what it means
08:50 brrt what it means is that we have a day that we get together and meet up and share knowledge and mash up ideas and maybe even write some code
08:51 samcv nice
08:51 samcv i'm all for something like that
08:51 brrt so that, for instance, i get an idea of what the challenges are in the rakudo compiler, maybe the rakudo core devs get some idea of what is going on in moar-land, and that we can maybe identify things we could focus on
08:53 brrt we could do topics like benchmarking, library optimizations, spesh/jit, regexp performance, etc
08:53 samcv sounds awesome
08:55 brrt :-)
08:55 nine brrt: the idea of a moarvm hackathon has been floating around for quite a while. Maybe it's just due? :) I hear Prague is a lovely city...
08:56 brrt prague is kind of nice yes
08:56 brrt a hackathon is maybe a better word for it
08:58 brrt samcv++ good documentation on the strings
08:59 samcv thanks :)
09:30 brrt nine: yeah, maybe we should just do it?
09:30 brrt only thing is.
09:31 brrt …. i don't think i have enough energy to organize it?
09:57 jnthn 97154519
09:57 jnthn uh, I mean, morning
09:57 jnthn .oO( a common typo... )
09:58 jnthn Some kind of hackathon along those lines was discussed a little at SPW, fwiw
09:58 jnthn With Prague as a location :)
10:01 squashable6 joined #moarvm
10:14 nine Well it's not gonna be a very large event. So all we need is to find some common date and a suitable room with a hotel nearby.
10:14 jnthn Or suitable room in a hotel
10:15 * jnthn can suggest something on that front if it's to be v Praze :)
10:19 nine Apparently it's easy to find a 4 star hotel for ~ 75 Euros per night, single room or ~ 100 Euros per night, double room
10:21 brrt moarning jnthn
10:21 brrt i'm not going to go to the vm meetup btw
10:21 brrt for the simple reason that i haven't got the time in that week
10:22 timotimo is that the moarvm core hacking meetup or the one jnthn was considering giving a talk at?
10:37 brrt the vm meetup was not a moarvm specific think
10:37 brrt *thing
10:37 timotimo OK, so that other thing
10:38 brrt yeah
10:38 brrt but also in prague
10:39 squashable6 joined #moarvm
10:42 buggable joined #moarvm
10:47 zakharyas joined #moarvm
11:43 MasterDuke joined #moarvm
12:02 MasterDuke brrt, nine: re profile showing no jitting, neither the sub that doesn't show as being jitted nor the loop body inside the sub that does show as being jitted have an osr notation in the profile
12:05 MasterDuke fyi, this is the code i'm running (s.sql has 50k lines): `my @l = "s.sql".IO.lines; my $p = "Perl6"; my @m = @l.grep(/ $p /); say @m.elems`
12:08 leont joined #moarvm
13:47 zakharyas joined #moarvm
14:35 brrt joined #moarvm
14:41 MasterDuke timotimo: you had some thoughts before, any more ideas about ^^^?
14:51 nine MasterDuke: I'd much rather we implement JIT compilation of param_op* ops instead of adjusting interfaces to the status quo
14:54 timotimo maybe we're not properly recording entering an osr'd routine while profiling
14:55 MasterDuke nine: sure, but it didn't really seem like a large adjustment in this case
14:56 nine MasterDuke: it isn't. But it's still the wrong direction :)
14:56 MasterDuke nine: would you be able to jit those ops?
14:57 brrt JITting param_* ops is not super hard, but it requires a change of interface, and it needs some thought
14:57 nine MasterDuke: I think, the trick is to move more functionality into a C function. If this part is in a function, it's easy to JIT: MVMArgInfo param = MVM_args_get_optional_pos_obj(tc, &tc->cur_frame->params, arg_idx); if (param.exists) { GET_REG(cur_op, 0).o = param.arg.o; }
14:57 nine You can pass the GET_REG(cur_op, 0) register to the function as argument
14:58 MasterDuke i thought the conditional addition to cur_op was the tricky part?
14:58 nine But we shouldn't need that? It's JITed code, so there is no run loop and no tracking of cur_op
14:59 brrt nine: i was actually thinking of MVM_arg_get_positional(tc, arg_idx, MVM_reg_obj, &GET_REG(cur_op,0)) -> exists
15:00 brrt and then branch on RV
15:00 brrt so it needs only a little bit of assembly in the legacy JIT
15:00 brrt but agian, that interface is different from what it is now
15:01 nine brrt: I'd say if you're gonna call a C function, you may as well have that function do a much of the job as possible to gain from all those smart compiler optimizations and get the full return for the cost of the call overhead
15:01 brrt that's what it would do, i think?
15:02 nine Then I maybe don't understand your proposal correctly?
15:02 brrt my proposal is basically, have the address-to-write a parameter, and return the existence
15:03 brrt anyway, the reason i never got to do that, was, src/core/args.c is evil code
15:03 nine Oooh...of course, there will still be a need for a branch
15:04 brrt the required can throw
15:04 nine Just not for cur_op changes but for whatever initialization code is run if the param doesn't exist
15:04 brrt the optional can branch
15:05 brrt maybe evil is overstated, but 'heavily macrofied and arguably in need of a cleanup'
15:11 brrt and the reason its evil, is it basically solves the problem of having native integers and floating point numbers between objects
15:14 nine what the? Giving the target local a :returns makes it actually box _more_, not less
15:14 MasterDuke joined #moarvm
15:21 brrt joined #moarvm
15:22 brrt it's also like, a lot more complicated to do
15:22 brrt oh, my last message did not arrive
15:23 brrt i'm thinking of doing the simple-and-naive thing of doing postorder single-pass traversal and 'recursing down' from that point
15:23 brrt the disadvantage is that we'll be visiting the same nodes multiple times
15:23 brrt the tiler doesn't do that, for instance
15:24 brrt the counterpoint is that we can combine the pattern trees to ensure that we only have to visit all children once per node
15:24 brrt at most
15:24 brrt so, tradeoffs and all that
15:25 brrt the reason to do it not like the tiler does, is that modifications invalidate the DFA state, and the tiler doesn't do that, but the optimizer obviously does
16:11 nine The bind node itself causes the coercion to an object!
16:27 robertle joined #moarvm
16:44 nine I'd have a solution...if it weren't for type objects :/
16:45 nine When I give the param local a proper :returns, I don't have to unbox manually. The compiler will handle that for me and that's the only way I've found so far to avoid those box_i instructions.
16:45 nine But with that I of course get "Cannot unbox a type object (Str) to a str"
16:46 dogbert2 joined #moarvm
16:49 nine Which is only natural, since that's how native params are usually handled!
16:50 nine m: sub foo(int32 $f) { }; foo(Int)
16:50 camelia rakudo-moar 909688: OUTPUT: «Cannot unbox a type object (Int) to int.?  in sub foo at <tmp> line 1?  in block <unit> at <tmp> line 1??»
16:50 nine So NativeCall actually breaks established behavior of Perl 6
16:52 geekosaur well, yes
17:05 Geth joined #moarvm
17:06 nine Who'd have thought that the real trickyness of JIT compiling native calls lies on the Perl 6 side?
17:44 lizmat joined #moarvm
18:19 brrt joined #moarvm
18:20 brrt good hi
18:20 brrt .tell nine: I would have, in fact
18:20 yoleaux brrt: What kind of a name is "nine:"?!
18:21 brrt .tell nine I would've thought that, in fact :-)
18:21 yoleaux brrt: I'll pass your message to nine.
18:24 MasterDuke brrt: i think i understand your param_op_* JITting proposal, but even "only a little bit of assembly in the legacy JIT" is more assembly than i've written in 20 years
18:25 brrt :-)
18:25 MasterDuke so i'll leave if to you, nine, timotimo, etc
18:27 brrt the better option, imho, is figure out why we end up with the param_op in the speshed code
18:27 brrt and maybe try and resolve that
18:27 brrt but yeah, a refactor of args handling has long been on my list
18:28 MasterDuke but meanwhile, do you have any ideas how to investigate why the routine isn't showing as JITted in the profile (when i apply my rakudo PR and there aren't any BAILs for it in the jit log)?
18:28 brrt not really
18:30 brrt i wish i knew better, to be honest
18:31 MasterDuke heh, np. how about another question then. know of any good way to profile just the mast stage? it's the second longest after parse, but i'm not sure how to get a rakudo or perf profile of just it
18:36 brrt also, no idea, i know very little of the rakudo compiler really
18:36 brrt well, you can maybe run a --profile with --target=mast
18:37 brrt and difff that from --target=mbc or something
18:37 brrt or with --target=optimize
19:02 brrt blegh, i'm far more tired than i'd like to admit
19:42 buggable joined #moarvm
19:44 buggable joined #moarvm
19:45 buggable joined #moarvm
19:48 buggable joined #moarvm
20:12 nine Ok, giving the param the low level like doesn't fly. BUT...having locals with the appropriate low level types and only assigning the decontend params to them when the params are actually defined works :) Still not issue free, but at least a step forwards
20:12 yoleaux 18:21Z <brrt> nine: I would've thought that, in fact :-)
20:13 AlexDani` joined #moarvm
20:29 lizmat joined #moarvm
20:49 samcv good **
21:00 lizmat joined #moarvm
23:25 Geth ¦ MoarVM: 6dcca22152 | (Samantha McVey)++ | src/strings/unicode_ops.c
23:25 Geth ¦ MoarVM: Fix unlikely but possible stack overflow from user input
23:25 Geth ¦ MoarVM:
23:25 Geth ¦ MoarVM: We use alloca to allocate onto the stack for
23:25 Geth ¦ MoarVM: unicode_cname_to_property_value_code. Set a limit at 1024 for the
23:25 Geth ¦ MoarVM: total length of the composed property value string (number + dash
23:25 Geth ¦ MoarVM: + property_value + NULL).
23:25 Geth ¦ MoarVM:
23:25 Geth ¦ MoarVM: <…commit message has 11 more lines…>
23:25 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/6dcca22152
23:25 Geth ¦ MoarVM: 8644fc6e5f | (Samantha McVey)++ | 2 files
23:25 Geth ¦ MoarVM: Allow MVM_string_get_grapheme_at_nocheck to be inlined
23:25 Geth ¦ MoarVM:
23:25 Geth ¦ MoarVM: Move MVM_string_get_grapheme_at_nocheck into iter.h so that it can be
23:25 Geth ¦ MoarVM: inlined. This makes the function 2x as fast for flat strings and 40% faster
23:25 Geth ¦ MoarVM: for strands. This should have big implications for speed since this function
23:25 Geth ¦ MoarVM: is used all over MoarVM.
23:25 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8644fc6e5f

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