github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
brrt \o 06:28
brrt .tell jnthn i'll have a look at the gist 06:31
yoleaux brrt: I'll pass your message to jnthn.
samcv timotimo: did the slides show up properly with that link? 08:57
nine Seems to me that having a release branch and keeping master open for development would be the better strategy overall. That way we can keep the normal development workflow with feature branches and don't have to rely on all involved people to know not to push to master. So in essence, people wouldn't have to know or care about the release process unless they really want to get a fix into the release - which 09:28
yoleaux 15 Aug 2018 16:40Z <brrt> nine: that's an interesting case for the jit optimizer... I want to make it so that we can use spesh facts that correspond to nodes
nine seems to be the exception anyway.
Geth MoarVM/postrelease-opts: e6104a7d01 | (Jonathan Worthington)++ | src/jit/x64/emit.dasc
Use mov64 to load a pointer; brrt++
 09:43
jnthn Stage parse : 45.864 10:10
Today's new low :)
(with commit I'll push in a moment, after spectesting) 10:11
Geth MoarVM/postrelease-opts: 4bda18a426 | (Jonathan Worthington)++ | 4 files
Lower unbox of P6[int|num|str]

This aids the performance of NQP code, which uses these rather than P6opaque-based box types. Also includes a fix for the interpretation of sp_get_s, which I can only figure has never been exercised before as it was utterly broke.		 10:16
jnthn Righty, now to see if I can get faster unbox of bigints too 10:18
Geth MoarVM/postrelease-opts: 2cc53306e1 | (Jonathan Worthington)++ | 11 files
Lower the unboxing of a bigint in a P6opaque

Now, if it's a small bigint (fits within 32 bits), we just pull it right out without having to make a function call. We only make a call in the case there's a real mp_int that we need to range check and take the value from.		 10:52
jnthn Yes, I can :)
Geth MoarVM/hllbool: 6 commits pushed by (Stefan Seifert)++ 10:56
Geth MoarVM/postrelease-opts: 3edfdf2b91 | (Jonathan Worthington)++ | src/6model/reprs/P6opaque.c
Use a cheaper op for str/num P6opaque box bind

We know that the body of the object will always be the direct one, not a replacement version of it, so we can simply bind directly into that without paying for the cost of the indirection.		 11:15
dogbert17 jnthn: you're on a roll today, impressive 11:17
timotimo ooh, that last one could maybe be made a more general opt that spesh knows about; when things just got created, the p6o versions could be lowered automatically 12:17
timotimo samcv: the slides work well 12:31
jnthn timotimo: Yeah, already pondered that :) 12:33
Didn't quite figure where to put it though 12:34
Geth MoarVM/postrelease-opts: a302b04bbf | (Jonathan Worthington)++ | 10 files
Don't enforce write barrier when boxing

The object was only just created. It must be in the nursery, since that's a rule for using `fastcreate`. Thus it can not be a gen2 object pointing to a nursery object, which is when the barrier would trigger.		 13:16
nine Oh, it looks like hllbool already makes stage parse a bit faster. Even without any more advanced spesh optimizations. 13:25
timotimo huh, but how? 13:26
jnthn also wonders 13:28
nine JIT compilation 13:32
timotimo huh, but p6bool should have been at least compiled to C function calls
i.e. not bail the frames completely
timotimo looks at the jit impls 13:33
jnthn I thought extops compiled to C function calls
But yeah, can help
timotimo yes, they normally do
jnthn (to get rid of the function call)
nine Maybe also the spesh optimization turning hllbool of a known value into a set.
Of course it may just be benchmarking noise
timotimo hm, i wonder how often that even happens 13:34
pro tip: we could use the spesh_comments mechanism to find out :) :)
nine: usually we'd compare ins->info->opcode against MVM_OP_* rather than comparing ins->info against MVM_op_get_op(MVM_OP_*) 13:35
(in optimize_hllbool)
dogbert17 jnthn: that last fix might contain a bug 13:36
Geth MoarVM/hllbool: 4 commits pushed by (Stefan Seifert)++ 13:37
nine timotimo: oh thanks! I forgot fixing that
jnthn dogbert17: Details?
(Was an opt rather than a fix)
dogbert17 Literally all spectests fails
timotimo hah 13:38
jnthn Looked good here
dogbert17 now, that's odd
jnthn Platform?
Also make sure you rebuild Rakudo 13:39
Or the extops
*or at least
dogbert17 ok, I did only rebuild MoarVM 13:40
yeah, looks better after a Rakudo rebuild, sorry for the noise 13:43
jnthn np :) 13:44
dogbert17 I usually get away with rebuilding MoarVM only. I guess specific changes requires a Rakudo rebuild as well 13:45
jnthn Yeah, things that add spesh ops can
timotimo github.com/MoarVM/MoarVM/issues/293 - if someone wants to improve that situation 13:46
jnthn I think we're making progress towards improving it my getting rid of the extops... :) 13:47
timotimo true 13:48
dogbert17 only two files failed now - with 'Parse errors: No plan found in TAP output'. This time it was t/spec/S04-statement-parsing/hash.t and t/spec/S32-basics/xxPOS-native.t 13:50
running these tests solo uncovers nothing nor does valgrind 13:51
jnthn D'oh, my new inline size decision algorithm produces negative sizes... 13:52
timotimo whoops
jnthn oh, I guess it has to approximate in one case...heh
jnthn Grr...that attempt helps some micro-benchmarks, but hurts CORE.setting and similar quite a bit 14:03
jnthn dogbert17: Yeah, I've been seeing the odd thing that fails like that, it varies between run and has happened for a while on that branch 14:13
Geth MoarVM/postrelease-opts: 498f189297 | (Jonathan Worthington)++ | 3 files
Subtract nested inlinees when checking inline size

So that if we do nested inlines, they don't contribute to the size of the overall thing. This seems to be on the most part a win: various Perl 6 microbenchmarks run faster, spectest seems unimpacted, there is a slight impact on spectest compilation time but nothing enormous.		 14:15
dogbert17 jnthn: I have one gist showing this behaviour: gist.github.com/dogbert17/2d499ec5...9c7db6107b 14:19
jnthn hmmm 14:20
timotimo a recording made with rr might be useful 14:23
do you just need to run it often enough to reproduce it?
dogbert17 timotimo: the gisted SEGV came from t/spec/S03-operators/buf.t, I usually have to run the system under load to make it appear 14:35
timotimo maybe it's time to try out rr's chaos mode 14:36
though it doesn't do any multithreading of its own, right?
only the spesh thread?
dogbert17 why do I get the feeling that the gist was utterly useless :-) 14:38
timotimo the oh, i could have seen it from the "info threads" output 14:39
i just looked at the one code line; i've seen that same thing before, too
the sc_idx somehow gets to be a wildly out-of-bounds value
dogbert17 I believe that is indeed the case 14:42
timotimo we have the case, now let's go for the cause 14:44
dogbert17 ran a new spectest including jnthn's latest commit, this time t/spec/S03-operators/autoincrement.t failed with Parse errors: No plan found in TAP output 14:46
it's definitely random and seems to happen early during the program run 14:47
dogbert17 timotimo: got it again, sc_idx = 32181872 14:53
unfortunately I had forgot to turn off the JIT this time 14:54
there's an assert commented out a few rows above, 367 /*assert(REPR(new_addr));*/, perhaps I should reenable that 15:00
dogbert17 no, that was a bad idea 15:04
timotimo haha 15:05
timotimo perhaps it doesn't hold for STables themselves? or maybe frames get to be in there, too? 15:05
dogbert17 damn, now it failed at another location 15:24
jnthn Yeah, soemthing's up...I'll bug hunt it probably next week though :)
dogbert17 here's a gist, perhaps there might be a clue in there 15:26
gist.github.com/dogbert17/988ea189...d2d94c102d
timotimo interesting, so the entry that's in there seems to have an object id, though that could also be reading bogus memory to come up with that idea 15:27
Geth MoarVM/postrelease-opts: 560df3dbc6 | (Jonathan Worthington)++ | src/spesh/optimize.c
Turn hllize to set if the change is a no-op

This not only avoids a little work, but also eliminates an op that might prevent inlining.		 15:49
jnthn Aside from microbenchmark improvements, it seems postrelease-opts brings a ~8% wallclock improvement in one real-world application too 16:27
Enough for now. Maybe a little more optimization fun over the weekend. We'll see :) 16:31
o/
MasterDuke timotimo: i don't think MVM_dump_bytecode_stackframe(tc, 1) is what i want 21:23
the annotations in what it dumps are all in src/Perl6/*, but i'm hoping for stuff in src/core/* 21:24

Powered by Cro and the Raku® Programming Language.

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

Thank you!