buggable ???????????? It's time for the monthly Accidental /win Lottery ???????????? We have 12 ballots submitted by 8 users! DRUM ROLL PLEASE!... 00:00
And the winning number is 14! Congratulations to nine! You win a can of WD40!
samcv woo 00:02
00:23 MasterDuke joined
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
MasterDuke k
samcv 23 is #
0x23.chr == # 00:29
that one never worked anyway so just ignore it
MasterDuke easy enough
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 00:53
samcv MasterDuke, is that exclusive or inclusive 01:02
MasterDuke exclusive 01:04
i assume it's this loop: or (i = 0; i < count; i++) if (roots[i] == obj) return i; 01:05
samcv yeah
MasterDuke the largest value for count is 161211, which occurs 54727 times (the most of any of the values for count) 01:06
samcv well it's 3x worse if i start the for loop at the top instead of the bottom 01:09
the scgetobjidx op calls it 01:10
01:34 Ven`` joined 01:51 ilbot3 joined
MasterDuke so instead of (incorrectly) jitting the param_op_* ops, i just make the arguments to INTERPOLATE non-optional 03:19
then, after jitting the eqat(ic|im|icim), it didn't cause any more BAILs 03:20
however, it still shows as not jitted in a profile (even though one of the loops inside it is shown as jitted) 03:21
why would that be? is it a problem? and is there a way to fix it if so?
Geth MoarVM: MasterDuke17++ created pull request #672:
JIT eqat(ic|im|icim)		 04:04
05:36 brrt joined
brrt good hi #moarvm 05:56
06:44 brrt joined
Geth MoarVM: deb5fbf35b | MasterDuke17++ (committed by Bart Wiegmans) | src/jit/graph.c
JIT eqat(ic|im|icim)
 06:54
brrt rebase-and-merge is a thing these days
old-style suffix rule works beautifully on nmake…. guess i was wrong in blaming it 07:06
nine Woohoo! One can never have enough WD40 07:12
Zoffix :) 07:13
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:14
brrt (WD40 is a lubrication oil?) 07:15
also, may that be due to OSR maybe 07:16
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
rebase coming on 07:29
Geth MoarVM/jit-legacy-cleanup: 25 commits pushed by (Bart Wiegmans)++
review: github.com/MoarVM/MoarVM/compare/8...2aa92db4d2
07:41 buggable joined
brrt i have something of a suggestion 08:11
08:20 squashable6 joined 08:25 leont joined 08:32 zakharyas joined
samcv good hi brrt 08:39
timotimo i'm interested in this suggestion 08:40
samcv Hot off the presses! Unicode grant status update 4! cry.nu/perl6/grant-status-update-4/ tons of exciting things 08:45
brrt \o/ 08:47
oh, right, i was saying something
hehe
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
brrt it is the suggestion
samcv i'm not even sure what a workshop is
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
brrt it's not important at all
samcv ah ok
brrt what it means
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
samcv nice 08:51
i'm all for something like that
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
we could do topics like benchmarking, library optimizations, spesh/jit, regexp performance, etc 08:53
samcv sounds awesome
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...
brrt prague is kind of nice yes 08:56
a hackathon is maybe a better word for it
samcv++ good documentation on the strings 08:58
samcv thanks :) 08:59
brrt nine: yeah, maybe we should just do it? 09:30
only thing is.
…. i don't think i have enough energy to organize it? 09:31
jnthn 97154519 09:57
uh, I mean, morning
.oO( a common typo... )
Some kind of hackathon along those lines was discussed a little at SPW, fwiw 09:58
With Prague as a location :)
10:01 squashable6 joined
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
jnthn can suggest something on that front if it's to be v Praze :) 10:15
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:19
brrt moarning jnthn 10:21
i'm not going to go to the vm meetup btw
for the simple reason that i haven't got the time in that week
timotimo is that the moarvm core hacking meetup or the one jnthn was considering giving a talk at? 10:22
brrt the vm meetup was not a moarvm specific think 10:37
*thing
timotimo OK, so that other thing
brrt yeah 10:38
but also in prague
10:39 squashable6 joined 10:42 buggable joined 10:47 zakharyas joined 11:43 MasterDuke joined
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:02
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:05
12:08 leont joined 13:47 zakharyas joined 14:35 brrt joined
MasterDuke timotimo: you had some thoughts before, any more ideas about ^^^? 14:41
nine MasterDuke: I'd much rather we implement JIT compilation of param_op* ops instead of adjusting interfaces to the status quo 14:51
timotimo maybe we're not properly recording entering an osr'd routine while profiling 14:54
MasterDuke nine: sure, but it didn't really seem like a large adjustment in this case 14:55
nine MasterDuke: it isn't. But it's still the wrong direction :) 14:56
MasterDuke nine: would you be able to jit those ops?
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; }
You can pass the GET_REG(cur_op, 0) register to the function as argument
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
brrt nine: i was actually thinking of MVM_arg_get_positional(tc, arg_idx, MVM_reg_obj, &GET_REG(cur_op,0)) -> exists 14:59
and then branch on RV 15:00
so it needs only a little bit of assembly in the legacy JIT
but agian, that interface is different from what it is now
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?
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
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
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
brrt the optional can branch
maybe evil is overstated, but 'heavily macrofied and arguably in need of a cleanup' 15:05
and the reason its evil, is it basically solves the problem of having native integers and floating point numbers between objects 15:11
nine what the? Giving the target local a :returns makes it actually box _more_, not less 15:14
15:14 MasterDuke joined 15:21 brrt joined
brrt it's also like, a lot more complicated to do 15:22
oh, my last message did not arrive
i'm thinking of doing the simple-and-naive thing of doing postorder single-pass traversal and 'recursing down' from that point 15:23
the disadvantage is that we'll be visiting the same nodes multiple times
the tiler doesn't do that, for instance
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
at most
so, tradeoffs and all that
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 15:25
nine The bind node itself causes the coercion to an object! 16:11
16:27 robertle joined
nine I'd have a solution...if it weren't for type objects :/ 16:44
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
But with that I of course get "Cannot unbox a type object (Str) to a str"
16:46 dogbert2 joined
nine Which is only natural, since that's how native params are usually handled! 16:49
m: sub foo(int32 $f) { }; foo(Int) 16:50
camelia Cannot unbox a type object (Int) to int.? in sub foo at <tmp> line 1? in block <unit> at <tmp> line 1??
nine So NativeCall actually breaks established behavior of Perl 6
geekosaur well, yes 16:52
17:05 Geth joined
nine Who'd have thought that the real trickyness of JIT compiling native calls lies on the Perl 6 side? 17:06
17:44 lizmat joined 18:19 brrt joined
brrt good hi 18:20
.tell nine: I would have, in fact
yoleaux brrt: What kind of a name is "nine:"?!
brrt .tell nine I would've thought that, in fact :-) 18:21
yoleaux brrt: I'll pass your message to nine.
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:24
brrt :-) 18:25
MasterDuke so i'll leave if to you, nine, timotimo, etc
brrt the better option, imho, is figure out why we end up with the param_op in the speshed code 18:27
and maybe try and resolve that
but yeah, a refactor of args handling has long been on my list
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
i wish i knew better, to be honest 18:30
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:31
brrt also, no idea, i know very little of the rakudo compiler really 18:36
well, you can maybe run a --profile with --target=mast
and difff that from --target=mbc or something 18:37
or with --target=optimize
blegh, i'm far more tired than i'd like to admit 19:02
19:42 buggable joined 19:44 buggable joined 19:45 buggable joined 19:48 buggable joined
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 20:29 lizmat joined
samcv good ** 20:49
21:00 lizmat joined
Geth MoarVM: 6dcca22152 | (Samantha McVey)++ | src/strings/unicode_ops.c
Fix unlikely but possible stack overflow from user input

We use alloca to allocate onto the stack for unicode_cname_to_property_value_code. Set a limit at 1024 for the total length of the composed property value string (number + dash
  + property_value + NULL).
... (11 more lines)		 23:25
MoarVM: 8644fc6e5f | (Samantha McVey)++ | 2 files
Allow MVM_string_get_grapheme_at_nocheck to be inlined

Move MVM_string_get_grapheme_at_nocheck into iter.h so that it can be inlined. This makes the function 2x as fast for flat strings and 40% faster for strands. This should have big implications for speed since this function is used all over MoarVM.

Powered by Cro and the Raku® Programming Language.

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

Thank you!