github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
01:03 squashable6 left 01:04 squashable6 joined 02:58 rba left 02:59 Kaiepi left, Kaiepi joined, rba_ joined, rba_ is now known as rba 03:18 leont left 04:51 linkable6 left, squashable6 left, greppable6 left, coverable6 left, nativecallable6 left, evalable6 left, releasable6 left, unicodable6 left, committable6 left, sourceable6 left, statisfiable6 left, quotable6 left, benchable6 left, tellable6 left, notable6 left, bisectable6 left, shareable6 left, bloatable6 left 04:52 shareable6 joined, releasable6 joined, committable6 joined, squashable6 joined, nativecallable6 joined 04:53 benchable6 joined, evalable6 joined, coverable6 joined, sourceable6 joined, bloatable6 joined, quotable6 joined, notable6 joined, statisfiable6 joined 04:54 greppable6 joined, bisectable6 joined, linkable6 joined, tellable6 joined, unicodable6 joined 08:20 patrickb joined 08:23 klapperl left 08:24 klapperl joined
nwc10 good *, #moarvm 08:30
good news - I have a cup of coffee
and I still have enough for one more
and I have an FFP2 mask...
and shops are open
(there is a bit of a bootstrapping problem if you have no FFP2 mask) 08:31
MasterDuke do you have a requirement on type of mask? 08:43
nwc10 yes. As of about a month ago
MasterDuke interesting. pretty much anything goes here (except pythons, live animals don't count as masks) 08:45
08:53 zakharyas joined 08:58 sena_kun left 09:01 sena_kun joined 09:35 zakharyas left 10:10 leont joined 10:21 Geth joined
jnthn morning o/ 10:22
lizmat morn!
jnthn There's no FFP2 requirement here yet in shops, transport, etc. (and only essential shops are open), but given they've recommended them and cut VAT on them, it seems they're trying to get ahead of the bootstrapping issue so they could require them... 10:23
nwc10 \o
jnthn Bootstrapping is always a total hack... :)
Also: all snow melted :( 10:24
Surprisingly quickly
nwc10 bootstrapping here was at least partly "masks given out for free at supermarkets for a few days"
I guess that the snow is urgently needed in Texas :-(
jnthn oh, that's pretty smart
I think Texas woulda preferred we keep it here...
nwc10 I think we would too :-)
MasterDuke good morning/timing, i just confirmed the same difference between first and last optimization of reify-at-least (sp_guardconc+sp_guardsf -> just sp_guardsf) with the latest commit (loop through the plan again and destroy stats for frame that had discarded candidates)
jnthn Hm, and that's not the one that's deopting. Did you conclusively figure out which stats lead to the guard? 10:27
MasterDuke i'm 90% sure it's `126: 4 x type Iterator (TypeObj)` 10:30
jnthn 4 is...rather little evidence 10:31
What is it guarding? A return value?
MasterDuke gist.github.com/MasterDuke17/3d829...18f401e48c has the stats right before the optimization and the "after"
jnthn ah, getting an attribute 10:32
Ohh 10:33
MasterDuke i think gist.github.com/MasterDuke17/3d829...t-log-L133 is the deopting sp_guardtype
jnthn Look at this
112: 10:34
128 x type Rakudo::Iterator::Gather (Conc)
257 x type List::Todo (Conc)
4 x type Scalar (Conc)
This happens:
[Annotation: Logged (bytecode offset 112)]
sp_getvc_o r11(2), r0(2), liti16(40), sslot(8) # [001] getattr_o of '$!current-iter' in List::Reifier
[Annotation: Logged (bytecode offset 126)]
sp_decont r10(41), r11(2)
[Annotation: INS Deopt One (idx 2 -> pc 132; line 41)]
sp_guardtype r10(3), r10(41), sslot(1), litui32(2)
I'm wondering if sp_decont only logs in the case it actaully deconts something
MasterDuke logs? 10:35
jnthn And the answer seems to be yes
github.com/MoarVM/MoarVM/blob/mast...rp.c#L3071 10:36
Logs type stats 10:37
Since so many things are in Scalar containers, we log the type that comes out of them, as a source of guards to insert
However, it seems we only log them in situations where we do a decont operation. This usually doesn't hurt because: 10:38
MasterDuke ah. so in this case most of the time it's not actually deconting, but we optimize for the decont case since that's what's logged?
jnthn 1. In many places we either always have a container or never have a container
2. In places where we always don't and we know that in spesh, we throw out the decont op
But in this case there's a mix (occassional container).
The decont stats only tell us about the container case 10:39
100% of the 4 times we deceont it's a consistent type 10:40
*decont
But yeah, that's a pretty dumb guard to insert
I think there's two things we could do
1. Always log the type coming out of a decont so the stats make more sense
MasterDuke yeah. so the example i'm using is a good example because of the very bad behavior (e.g., the 688k deopts). but it's a bad example because i think there's something wrong at a more basic level. removing an optimization is sort of a bandaid (though a capability to have in general) 10:41
jnthn 2. Have a minimum threshold for when we pay attention to stats (though this gets a bit interesting in rarely taken branches)
Yes, both the GC-able spesh candidate *and* being able to remove candidates that deopt too much are both *really* useful 10:42
But it turns out that here it will only go and make the same bad assumption again
MasterDuke heh, yep. thrown me for a loop for a bit 10:43
jnthn On the upside, this seems potentially easier to fix
If the "always log" approach works, for example
MasterDuke just move that `if (MVM_spesh_log_is_logging(tc)) MVM_spesh_log_decont(tc, prev_op, r->o);` after the if/else? 10:45
jnthn I think that will do it, yes 10:47
MasterDuke deopts gone 10:48
jnthn Nice, and faster_ 10:50
?
MasterDuke yes, but haven't yet compared to master (i think it's pretty similar if i'm remembering those numbers correctly) 10:51
though i did just get a segv when profiling...
`MVM_spesh_log_decont (tc=0x55555555a0b0, prev_op=0x7ffff64827d8 "\017", value=0x0) at src/spesh/log.c:195` 10:52
jnthn o.O
MasterDuke heh. the `entry` doesn't look good 10:53
$2 = {kind = 0, id = 0, {entry = {sf = 0x0, cs = 0x0}, param = {type = 0x0, flags = 0, arg_idx = 0}, type = {type = 0x0, flags = 0, bytecode_offset = 0}, value = {value = 0x0, bytecode_offset = 0}, invoke = {sf = 0x0, caller_is_outer = 0,
      was_multi = 0, bytecode_offset = 0}, osr = {bytecode_offset = 0}, plugin = {bytecode_offset = 0, guard_index = 0}, deopt = {sf = 0x0, spesh_cand = 0x0}}}
jnthn oh, value=0x0 10:54
That means a real null showed up somewhere
MasterDuke yeah, from that moved `if (MVM_spesh_log_is_logging(tc)) MVM_spesh_log_decont(tc, prev_op, r->o);`
i just stuck it here github.com/MoarVM/MoarVM/blob/mast...rp.c#L3079
10:55 zakharyas joined
MasterDuke should i stick a VMNull if `!r->o` ? 10:56
10:56 linkable6 left
jnthn Or just don't log in that case 10:57
But I'm curious where they're coming from; we should never get a real NULL in a register
10:57 linkable6 joined
MasterDuke gist.github.com/MasterDuke17/1e77c...979c317e69 backtrace and bytecode 10:59
`if (r->o && MVM_spesh_log_is_logging(tc))` and a profile is created just fine 11:04
though if that isn't supposed to happen i should switch their order 11:06
jnthn Yes 11:15
MasterDuke github.com/Raku/nqp/blob/master/sr...#L251-L257 is where that null register comes from btw 11:19
jnthn Guess getobjsc and getscdesc are worth auditing 11:21
They're rare enough we could have missed it before now
releasable6: status 11:25
releasable6 jnthn, Next release in ≈2 days and ≈7 hours. 2 blockers. 22 out of 131 commits logged
jnthn, Details: gist.github.com/d1fbf3b53b009a0e68...cc619671df
jnthn Hm, was gonna say maybe the deopt logging change could go in separately so it makes the release as it would wrrant rather less testing, but that still feels a bit risk 2 days away
MasterDuke well, not sure a release is going to happen regardless 11:27
lizmat MasterDuke: why ? 11:28
MasterDuke think those blockers are going to be cleared by then?
huh. the inlining tests are now consistently failing... 11:32
even when run by themselves
jnthn Looks like one of the blockers is a fixed issue only waiting CI coverage, which I guess means it needn't block the release 11:33
lizmat and the inlining tests can be removed
I mean, *that* should not be a blocker
MasterDuke `sp_fastinvoke_o   r4(6),   r9(2), sslot(6)  # [005] could not inline 'AT-POS' (4875) candidate 139866774879360: bytecode is too large to inline`
lizmat *although* I wonder how it can be that inlining happens less when a machine is under load
wouldn't that imply that there is some sort of starvation on the spesh thread? 11:34
MasterDuke it isn't changing for me based on the load, it's on my branch that it's happening
lizmat aaah then maybe the failure is legit ?
MasterDuke i just changed how/what stats are collected, so could be 11:36
heh. that number after "candidate" used to be the index into spesh_candidates, now it's formatting the actual pointer as a number 11:39
i don't think it makes sense to put the pointer's address (even formatted correctly) or the spesh slot. i'm probably going to just remove that number entirely unless someone has an idea/opinion? 11:41
jnthn yeah, the pointer is meaningless 11:42
The number wasn't actually that meaningful either
MasterDuke just did a quick check. when compiling CORE.c, a candidate is removed 70 times 11:52
Deopt specialization of 'statement' (cuid: 111, file: gen/moar/Grammar.nqp:957) 11:58
Removing a spesh candidate because it was deopted too many times (35833)
12:00 zakharyas left
MasterDuke hmmmmmm. using this example `my $r := "a" .. "za"; my @a = $r[^$r.elems]; say now - INIT now`, master has ~688k deopts and takes ~2.6s. my branch has ~660 deopts and takes ~2.8s 12:03
and stage parse for CORE.c is ~2s slower on my branch 12:04
it seems to be because of more time spent in MVM_frame_invoke, but i'm not sure why 12:53
whereas master with that change to decont logging cherry-picked is ~2.5s (and also only has ~660 deopts) 12:57
but also fails the inlining tests 14:00
14:09 zakharyas joined 14:19 zakharyas1 joined, zakharyas left 14:25 squashable6 left 14:28 squashable6 joined 14:34 linkable6 left 14:36 linkable6 joined
nwc10 Two for one on coffee! 15:33
16:11 domidumont joined
dogbert11 wonders if his rakudobrew install is broken 16:21
if not there's a gc related bug lurking about. The first I've seen in quite some time. 16:23
perhaps this is something for nine, gist.github.com/dogbert17/5c6a632a...e2bfed97fa 16:28
17:42 linkable6 left 17:45 linkable6 joined 18:15 domidumont left 18:46 zakharyas1 left
nine Good evening! So....which stream are you watching? :D 19:50
nwc10 Texas? Or Mars? 19:51
nine I expect even the LabPadre people to watch Mars right now :) 19:54
lizmat is there an SN10 launch then planned ? 20:31
nine not today
lizmat seems friday at the earliest 20:33
nwc10 The bit that I liked (and I wound the stream back and transcribed it) was: 21:15
We've landed about 35m from the nearest rocks that we could identify from orbit from their shadow
I remember this spot - it looks good.
nine :) 21:16
MasterDuke huh. the "after" of AT-POS is pretty similar with that decont logging change and without 21:44
bytecode size is the same
21:46 vrurg_ joined, vrurg left
MasterDuke doh, the failed test was postcircumfix:<[ ]>... 21:47
but the spesh log says AT-POS isn't inlined, doesn't say that about [] 21:49
oh, but that's in the after of []
uh, it's after looks pretty similar also. both show AT-POS not being inlined? 21:52
this isn't great. i'm using an unmodified master and getting the occasional `free(): corrupted unsorted chunks` 21:55
everything stock. `MVM_SPESH_LOG=inline.spesh.log ./rakudo-m -I lib/ t/09-moar/10-inline-array-pos.t` sometimes gives `free(): corrupted unsorted chunks`. asan says `Direct leak of 8192 byte(s) in 1 object(s) allocated from: 22:02
    #0 0x7f4008562459 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
    #1 0x7f4006a617a4 in _IO_file_doallocate (/usr/lib/libc.so.6+0x747a4)`
not getting anything in valgrind 22:04
22:12 patrickb left 23:22 dogbert11 left 23:23 dogbert11 joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!