github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:59 shareable6 joined, p6bannerbot sets mode: +v shareable6 01:50 MasterDuke left 01:58 MasterDuke joined, p6bannerbot sets mode: +v MasterDuke, MasterDuke left, MasterDuke joined, herbert.freenode.net sets mode: +v MasterDuke, p6bannerbot sets mode: +v MasterDuke 02:54 disi joined 02:55 disi is now known as Guest68038, p6bannerbot sets mode: +v Guest68038 02:59 Guest68038 left 04:58 FuzzySockets joined 05:00 FuzzySockets left 05:12 Ben6426 joined 05:13 Ben6426 left 05:29 brrt joined 05:30 p6bannerbot sets mode: +v brrt 05:51 greppable6 joined 05:52 p6bannerbot sets mode: +v greppable6 05:55 lizmat left 06:27 Sharker joined, Sharker left
brrt \o 06:28
06:30 lizmat joined
brrt .tell jnthn i'll have a look at the gist 06:31
yoleaux brrt: I'll pass your message to jnthn.
07:02 TehNut joined 07:06 TehNut left 07:45 zakharyas joined, p6bannerbot sets mode: +v zakharyas 07:49 lizmat left 08:04 zakharyas left 08:05 zakharyas joined 08:06 p6bannerbot sets mode: +v zakharyas 08:14 GigabytePro12 joined, p6bannerbot sets mode: +v GigabytePro12 08:16 GigabytePro12 left 08:22 norkle27 joined 08:23 p6bannerbot sets mode: +v norkle27 08:27 LambdaComplex21 joined 08:28 p6bannerbot sets mode: +v LambdaComplex21, LambdaComplex21 left 08:30 norkle27 left 08:48 macky joined 08:49 p6bannerbot sets mode: +v macky, macky left 08:52 ZzZombo joined, p6bannerbot sets mode: +v ZzZombo
samcv timotimo: did the slides show up properly with that link? 08:57
09:00 brrt left 09:05 zakharyas left, zakharyas joined 09:06 p6bannerbot sets mode: +v zakharyas 09:07 sophiya joined 09:08 p6bannerbot sets mode: +v sophiya, sophiya left
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.
09:29 L2358 joined 09:30 p6bannerbot sets mode: +v L2358, L2358 left 09:39 L0j1k21 joined 09:40 L0j1k21 left
Geth MoarVM/postrelease-opts: e6104a7d01 | (Jonathan Worthington)++ | src/jit/x64/emit.dasc
Use mov64 to load a pointer; brrt++
 09:43
09:46 lizmat joined 09:47 p6bannerbot sets mode: +v lizmat 10:01 lizmat left 10:04 zakharyas left, mniip8 joined 10:05 p6bannerbot sets mode: +v mniip8 10:07 mniip8 left
jnthn Stage parse : 45.864 10:10
Today's new low :)
(with commit I'll push in a moment, after spectesting) 10:11
10:13 zakharyas joined 10:14 p6bannerbot sets mode: +v zakharyas
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
10:21 lizmat joined 10:22 p6bannerbot sets mode: +v lizmat 10:31 lizmat left 10:38 johnpark_pj joined 10:39 p6bannerbot sets mode: +v johnpark_pj 10:42 johnpark_pj left
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
10:56 ZzZombo left 11:04 zakharyas left, zakharyas joined 11:05 p6bannerbot sets mode: +v zakharyas 11:09 CrunchyChewie7 joined 11:10 p6bannerbot sets mode: +v CrunchyChewie7 11:11 CrunchyChewie7 left 11:14 zakharyas left
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
11:25 lizmat joined, p6bannerbot sets mode: +v lizmat 11:30 lizmat left 11:33 lizmat joined, lizmat left 11:37 lizmat joined 11:38 p6bannerbot sets mode: +v lizmat 11:41 lizmat left 12:15 RichiH8 joined, RichiH8 left
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
12:20 lagbox24 joined 12:21 lagbox24 left
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
12:47 lutoma12 joined, lutoma12 left 12:49 jelly11 joined 12:50 p6bannerbot sets mode: +v jelly11, stmuk joined 12:51 p6bannerbot sets mode: +v stmuk 12:53 stmuk_ left 12:57 jelly11 left 13:02 lizmat joined 13:03 p6bannerbot sets mode: +v lizmat
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
13:18 zakharyas joined, p6bannerbot sets mode: +v zakharyas 13:21 lizmat left
nine Oh, it looks like hllbool already makes stage parse a bit faster. Even without any more advanced spesh optimizations. 13:25
13:26 lizmat joined
timotimo huh, but how? 13:26
13:27 p6bannerbot sets mode: +v lizmat
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
13:44 lizmat left
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
13:46 lizmat joined, Guest42469 joined
timotimo github.com/MoarVM/MoarVM/issues/293 - if someone wants to improve that situation 13:46
13:47 p6bannerbot sets mode: +v lizmat, p6bannerbot sets mode: +v Guest42469
jnthn I think we're making progress towards improving it my getting rid of the extops... :) 13:47
13:47 johtso joined
timotimo true 13:48
13:48 johtso left, Guest42469 left
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
13:58 lizmat left
jnthn Grr...that attempt helps some micro-benchmarks, but hurts CORE.setting and similar quite a bit 14:03
14:03 zakharyas left 14:04 zakharyas joined 14:05 p6bannerbot sets mode: +v zakharyas
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
14:19 lizmat joined 14:20 p6bannerbot sets mode: +v lizmat
jnthn hmmm 14:20
14:22 MasterDuke left
timotimo a recording made with rr might be useful 14:23
do you just need to run it often enough to reproduce it?
14:24 lizmat left
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
14:47 hiya26 joined 14:48 p6bannerbot sets mode: +v hiya26 14:49 hiya26 left
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
15:04 zakharyas left
dogbert17 no, that was a bad idea 15:04
timotimo haha 15:05
15:05 zakharyas joined
timotimo perhaps it doesn't hold for STables themselves? or maybe frames get to be in there, too? 15:05
15:06 p6bannerbot sets mode: +v zakharyas 15:09 lizmat joined 15:10 p6bannerbot sets mode: +v lizmat, lizmat left
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
16:02 zakharyas left
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/
16:42 pierte joined, pierte left 18:13 MasterDuke joined, p6bannerbot sets mode: +v MasterDuke 18:14 MasterDuke left, MasterDuke joined, herbert.freenode.net sets mode: +v MasterDuke, p6bannerbot sets mode: +v MasterDuke 18:25 zakharyas joined, p6bannerbot sets mode: +v zakharyas 18:26 tesu15 joined 18:27 p6bannerbot sets mode: +v tesu15, tesu15 left 18:35 EXCEPTS joined 18:36 p6bannerbot sets mode: +v EXCEPTS 18:37 EXCEPTS left 18:45 RichiH13 joined, p6bannerbot sets mode: +v RichiH13 18:47 RichiH13 left 18:58 stmuk_ joined 18:59 p6bannerbot sets mode: +v stmuk_ 19:00 zakharyas left, stmuk left 19:30 thomasb9511 joined 19:31 p6bannerbot sets mode: +v thomasb9511 19:32 thomasb9511 left 19:55 diakopter left 20:07 Kaiepi left, Kaypie joined 20:08 p6bannerbot sets mode: +v Kaypie 20:37 d__b joined 20:38 p6bannerbot sets mode: +v d__b, d__b left
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
21:41 y0sh11 joined 21:42 p6bannerbot sets mode: +v y0sh11 21:47 drakythe joined 21:48 p6bannerbot sets mode: +v drakythe 21:50 drakythe left, y0sh11 left 21:57 ski_ joined, p6bannerbot sets mode: +v ski_ 22:04 ski_ left 22:28 Syfer joined, p6bannerbot sets mode: +v Syfer 22:29 Syfer left 22:31 ruunyan joined, ruunyan left 22:45 Connecting joined 22:46 p6bannerbot sets mode: +v Connecting 22:48 Connecting left 22:49 janus23 joined 22:50 p6bannerbot sets mode: +v janus23 22:55 janus23 left 22:59 Kaiepi joined, Kaypie left, p6bannerbot sets mode: +v Kaiepi 23:00 Kaiepi left 23:01 Kaiepi joined, p6bannerbot sets mode: +v Kaiepi 23:06 stmuk joined, p6bannerbot sets mode: +v stmuk 23:07 pringlecake joined, p6bannerbot sets mode: +v pringlecake 23:08 stmuk_ left, pringlecake left 23:37 e27 joined, e27 left, mpmc23 joined, p6bannerbot sets mode: +v mpmc23 23:38 mpmc23 left 23:46 hoelzro left

Powered by Cro and the Raku® Programming Language.

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

Thank you!