| IRC logs at
Set by AlexDaniel on 12 June 2018.
00:24 ggoebel left 05:28 robertle left 06:15 domidumont joined 06:39 domidumont left 06:44 brrt joined 07:05 domidumont joined 07:10 domidumont left 07:17 domidumont joined 07:44 zakharyas joined 08:00 brrt left
jnthn nine: Yes, I think so 08:53
09:19 sena_kun joined 09:56 domidumont left
nine jnthn: ok, that's included in my PR 10:35
jnthn Cool; I'll take a look at it this afternoon 10:42
MasterDuke nine: have anything you're working on next? 10:48
nine My memoires? 10:50
Guest23744 nine: MasterDuke found another fromspace error 11:00
11:10 zakharyas left 11:12 domidumont joined 11:31 domidumont left 11:43 domidumont joined
MasterDuke nine: if you're tempted, discussion from until about 17:00 11:58
12:23 ggoebel joined 13:09 lucasb joined 13:30 zakharyas joined
Kaiepi jnthn did you have a chance to look at pr 1166? 14:26
15:11 zakharyas left 15:14 zakharyas joined 15:58 zakharyas left 16:07 robertle joined 16:13 domidumont left 16:47 domidumont joined 17:44 Ven`` joined 18:09 greppable6 left
MasterDuke heh, i was just wondering if we had anything like `MVM_free_null`, found it, but it's only used once 18:11 18:12
18:13 greppable6 joined
MasterDuke oh, but code_pair_gc_free_data is what calls it, and that is part of the `MVMContainerSpec code_pair_spec` struct, so i guess a bunch of stuff does end up calling it 18:13
but is there any reason we couldn't/shouldn't use elsewhere?
timotimo it's not always necessary to null a pointer after freeing the memory it's for, because often we end up freeing the memory that has that pointer in it in the next step :) 18:16
or we're currently freeing an object that the GC has declared garbage, which also means we don't have to null the pointer
MasterDuke no, but there are >0 instances of `MVM_free(foo); foo = NULL;` 18:17
nine Probably people (like me) just didn't know of MVM_free_null's existence
MasterDuke i don't know how many exactly, so maybe it's not worth it
but i was just looking at some code of mine and wondered 18:18
fwiw, i count 34 instances of `MVM_free(foo); foo = NULL`, but one of those is in the MVM_VECTOR_DESTROY macro, so i don't know if there really would be more 18:25
timotimo i mean, the compiler would probably generate the exact same result for either version 18:26
MasterDuke sure, i wouldn't expect any change in compilation/runtime, but it might prevent some mistake down the line 18:28
18:55 domidumont left
lizmat and another Perl 6 Weekly hits the Net: 18:58
Geth_ MoarVM: MasterDuke17++ created pull request #1185:
Check if subtracting a successor's exclusive...
MasterDuke does anyone feel like jitting param_on2_o, param_rn2_o, param_rn_o, and param_on_o? they're causing bails 19:29
timotimo they are very difficult 19:42
brrt was meaning to refactor how argument stuff works in order to make that possible
MasterDuke k 19:43
nine The rn versions are actually very simple to refactor. They just need the same treatment as param_rs* in 19:47
MasterDuke nine: fwiw, i'm looking at a profile-compile of that example we were talking about before (thousands of files in lib/) 19:50
nine MasterDuke: oh, anything interesting there? 19:51
MasterDuke nothing that looks like there's a silver bullet to be had to me, but i can pretty much only catch low-hanging fruit 19:53
i can send you a profile if you want
nine I don't think I'll have time to spend on that
MasterDuke k 19:54
top by exclusive time is 19:58
it bails because of param_on2_o 19:59
the deopt log doesn't say why something was deopted. could that be figured out? 20:09
nine FWIW when I work on performance, I go mostly on inclusive time. Exclusive time will usually lead you to micro optimizations while inclusive time can show you where you need to improve your algorithms 20:13
MasterDuke hm, that makes sense. though in this case when the vast majority of the time is in stage parse i assume there's nothing i can do about that and need to look at those micro optimizations 20:15
and honestly, the whole compunit/distro stuff is pretty deep magic to me 20:19
nine `use` will also count in stage parse and is mostly plain normal Perl 6 code 20:21
It's not so magical once you have learned to embrace the SHA :) 20:22
20:36 sena_kun left 22:48 Ven`` left