Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
00:02 reportable6 left
timo lizmat: i use it like "use MoarVM::Spesh" and from the .report it will say Spesh Log Report of Process #3844344 (2021-09-16T00:18:23Z) and then the -e program i inputted, that's a little odd. was it supposed to like read the currently running program's spesh log on exit or so? 00:23
01:30 bloatable6 left, linkable6 left, unicodable6 left, sourceable6 left, coverable6 left, quotable6 left, greppable6 left, committable6 left, bisectable6 left, nativecallable6 left, notable6 left, tellable6 left, benchable6 left, shareable6 left, statisfiable6 left, evalable6 left, releasable6 left, squashable6 left 01:31 notable6 joined, bisectable6 joined, linkable6 joined 01:32 tellable6 joined, unicodable6 joined, coverable6 joined 01:33 bloatable6 joined
Geth MoarVM/win-vla: a66754871d | Coke++ | build/setup.pm
Turn VLA usage into a compiler error

VLA fails on windows, this allows us to catch it on other platforms first.
Resolves #1537		 01:47
MoarVM: coke++ created pull request #1539:
Turn VLA usage into a compiler error		 01:48
[Coke] Added it to gcc default and clang.
(needed clang for os x)
That PR is off new-disp, not master.
02:30 sourceable6 joined 02:31 nativecallable6 joined, releasable6 joined 02:33 shareable6 joined, benchable6 joined 03:05 reportable6 joined 03:31 squashable6 joined, quotable6 joined, greppable6 joined 03:32 statisfiable6 joined 04:32 quotable6 left, bloatable6 left, unicodable6 left, bisectable6 left, notable6 left, reportable6 left, statisfiable6 left, nativecallable6 left, sourceable6 left, releasable6 left, benchable6 left, greppable6 left, linkable6 left, tellable6 left, coverable6 left, shareable6 left, squashable6 left, evalable6 joined, nativecallable6 joined, linkable6 joined, squashable6 joined 04:33 coverable6 joined 04:34 releasable6 joined, statisfiable6 joined, benchable6 joined, bisectable6 joined 04:35 tellable6 joined, sourceable6 joined 05:32 shareable6 joined 05:34 unicodable6 joined, notable6 joined 06:34 unicodable6 left, shareable6 left, linkable6 left, notable6 left, benchable6 left, releasable6 left, tellable6 left, bisectable6 left, nativecallable6 left, statisfiable6 left, evalable6 left, coverable6 left, sourceable6 left, squashable6 left 06:35 bloatable6 joined, nativecallable6 joined 06:36 linkable6 joined, benchable6 joined 06:37 shareable6 joined, squashable6 joined, notable6 joined, coverable6 joined
Nicholas good UGT, * 06:45
07:00 brrt joined 07:01 brrt joined 07:03 reportable6 joined
Nicholas good *, brrt 07:08
brrt good * Nicholas 07:12
07:32 greppable6 joined 07:33 quotable6 joined 07:36 brrt left 08:31 committable6 joined 08:35 releasable6 joined, bisectable6 joined 08:37 statisfiable6 joined, tellable6 joined, evalable6 joined, unicodable6 joined 09:18 frost joined
Geth MoarVM/MVM_callsite_intern-and-is_common: 1e9b15a5fc | (Nicholas Clark)++ | src/core/callsite.c
Comment that `MVM_callsite_intern` and `is_common` are coupled.

If you change one you need to change the other.		 09:56
MoarVM: nwc10++ created pull request #1540:
Comment that `MVM_callsite_intern` and `is_common` are coupled.		 09:57
10:11 lizmat_ joined 10:12 TempIRCLogger left, Geth left 10:13 RakuIRCLogger left, lizmat left 11:13 linkable6 left, evalable6 left 11:21 timo left 11:41 lizmat_ left 11:42 lizmat joined 12:02 reportable6 left
jnthnwrthngtn moarning o/ 12:03
Nicholas \o 12:04
jnthnwrthngtn Hm, missing Geth. I just merged a PR ayways. 12:07
*anyways
lizmat oooh 12:08
lemme check
12:08 Geth joined, RakuIRCLogger joined
lizmat jnthnwrthngtn: I don't have rights to re-send a webhook notification 12:09
on moarvm/moarvm 12:10
if you resend it, it should work again now
jnthnwrthngtn Don't know it's needed. It was the merge of github.com/MoarVM/MoarVM/pull/1540 for anyone curious. :)
12:11 TempIRCLogger joined
lizmat seems we lost connectivity for about 3 mins 12:11
jnthnwrthngtn hopes to feel up to continue hunting the deopt bug a bit later this afternoon 12:14
dogbert17 wonders if there's more inlining stuff which has not yet been enabled on new-disp 12:21
some code is still noticeably slower on new-disp hence the question 12:25
Nicholas jnthnwrthngtn: "up to" - you're feeling a bit under the weather? 12:26
dogbert17 or is the coffee machine broken?
jnthnwrthngtn Another round of dental work this morning. Nothing so dramatic as the last time, thankfully, but I'm not keen to eat until the anaesthetic wears off, and am feeling a bit week due to not eating. 12:42
uh, weak
dogbert17: Yes, the very deopt bug I'm hunting (and the one already fixed yesterday) come up when I stop introducing guards for already proven types. Some of those guards are in the parameter binding section of the code, and their presence inhibits inlining 12:46
In some microbenchmarks I've looked at, loads of important inlining is missed out for this reason.
13:05 reportable6 joined
Nicholas so it's an ice cream day? Are you allowed coffee ice cream? 13:05
jnthnwrthngtn I've no restrictions on hot things this time, even, so coffee itself is fine :) 13:09
(Except wanting to be able to feel how hot it is :))
13:13 linkable6 joined 13:15 evalable6 joined
jnthnwrthngtn OK, so let's see where the deopt annotations are a) going, b) should go 14:06
14:31 evalable6 left, linkable6 left 14:32 evalable6 joined 14:35 sourceable6 joined
jnthnwrthngtn Hurrah, seems I've got a fix 14:57
Nicholas \o/
jnthnwrthngtn Well, and better, understand what was happening, and why, and why master got it right, and also found a spot where master was probably a bit too conservative 14:58
Spectesting with the fix + just one kind of guard elided in the dispatch program translation
That goes already get a lot more inlining 14:59
an inline ASSIGN-POS (6884) with bytecode size 334 into postcircumfix:<[ ]> (6570) 15:00
Can inline postcircumfix:<[ ]> (6570) with bytecode size 132 into (1)
That's what I like to see
dogbert17 yay :)
jnthnwrthngtn From 2.874 to 0.897 for that script :) 15:01
dogbert17 wow 15:02
soon lizmat will show up ...
jnthnwrthngtn (The one in question was just an array setup benchmark, fwiw) 15:06
(nothing so exciting as test-t)
dogbert17 so, will the eliding process continue? 15:09
Geth MoarVM/new-disp: 73656f0890 | (Jonathan Worthington)++ | 3 files
Better choice if proxy deopt index on inline

This is used to make sure we don't do changes that would impact our ability to deoptimize inside of the inline and reconstruct the caller. Prior to new-disp, we used the deopt index on the prepargs, and did recreate that - well, sort of; in fact we produced a new index, and achieved nothing at all. This fixes it by using a real deopt index with ... (6 more lines)		 15:12
MoarVM/new-disp: a4853302b9 | (Jonathan Worthington)++ | src/spesh/optimize.c
Correct deopt handling in runbytecode opts

When we stack up guards in front of a runbytecode so we can spesh link or inline it, they need to have a deopt index allocated, and it needs to be a predeopt point (so we deopt to before the original dispatch op and run the dispatch afresh). This much we got correct. However, it is also important the deopt usages of registers are preserved. In the case that ... (6 more lines)
jnthnwrthngtn Yes, now I'll try adding more guard elliding
Those two commits don't speed anything up; they're the fixes needed to be able to 15:14
15:19 squashable6 left
dogbert17 exciting times ahead :) 15:20
Nicholas hopefully not in the ASAN sense 15:23
jnthnwrthngtn Indeed :P
Well, so far eliding guards for arg guard dispatch ops hasn't broken the build 15:24
Doing a spectest now
Then can add the same but on temporaries 15:25
Probably not that much win on those but we'll see
oh, the arg literals also
Hm, one spectest isn't happy 15:28
oh, passes on its own
ugh, passes with nodelay and blocking too 15:29
Odd
Nicholas IIRC the harness sets up some (extra) environment 15:30
jnthnwrthngtn OK, guess since I can repro it I'll see if any of the rest of you can :)
uh, can't repro it
Nicholas there's also the possiblity of weird behaviour due to stdin/stdout/stderr being/not being ttys/pipes
dogbert17 perhaps we can :) 15:32
15:34 linkable6 joined 15:35 frost left
Geth MoarVM/new-disp: e3c6d39dcd | (Jonathan Worthington)++ | src/spesh/disp.c
Elide proven arg type guards in DP translation

If we already know that the property asserted by the guard is true - either through type analysis or an existing guard - we can avoid inserting it at all. This is quite a lot cheaper than adding it and having it removed later (although that doesn't seem to actually take place at present, even if in principle it should), since we avoid doing the whole SSA version split dance.		 15:36
jnthnwrthngtn That restores quite a bit of inlining
15:38 timo joined
dogbert17 I got two failures, t/spec/S12-construction/destruction.t and t/spec/S32-str/sprintf-x.t 15:43
jnthnwrthngtn I only saw the second of those 15:44
timo where do i currently go to see what i missed in the couple hours i was offline? 15:45
dogbert17 the first file failed one test the second crashed
elems requires a concrete object (got a VMNull type object instead)
in block at t/spec/S32-str/sprintf-x.t line 299
jnthnwrthngtn dogbert17: It's quite a huge file, any chance of a golf? 15:49
timo: hm, the logs link ain't in the topic? 15:50
timo it is not, the other two channels also don't have one
something something log inspection something
jnthnwrthngtn I thought there was collabti or something and then liz's one 15:51
timo we might have opted out of colabti for some reason or other?
Geth MoarVM/new-disp: 7592cc0724 | (Jonathan Worthington)++ | src/spesh/disp.c
Elide arg literal guards in DP translation
timo ok colabti does still have it
jdv colabti.org/irclogger/irclogger_lo...2021-09-16 and logs.liz.nl/moarvm/2021-09-16.html both work for me 15:52
dogbert17 jnthnwrthngtn: let me see what I can do
timo i don't know where i would have had to look to find liz' logs :P 15:57
Geth MoarVM/new-disp: 80ae107010 | (Jonathan Worthington)++ | src/spesh/disp.c
Elide temp guards in DP translation
 16:10
jnthnwrthngtn OK, that's the latest round of breaking things. :) 16:11
I've blown up S03-buf/write-int.t too apparently; investigating 16:12
huh, managed to spesh bissect it but get an empty log 16:17
16:21 squashable6 joined
jnthnwrthngtn Sigh, it'll reliably segv until I run it under gdb, and then it never will 16:25
timo sounds like you want rr? :) 16:27
jnthnwrthngtn Will reach for that if ASAN doesn't have anything to say 16:31
I'm wondering if it's segfaulting in spesh itself
I can't think why else I'd get no spesh logs
Nicholas valgrind would also validate the spesh thread (and even JIT generated code) ? 16:32
timo strace could help figure out why no spesh log 16:33
jnthnwrthngtn It could but also didn't fail
Oh
On the 3rd attempt, ASAN finds it
It is a segv in spesh 16:34
What silly have I done...
oh. duh.
timo i'm putting something in spesh that puts lines that look like "skip:123456789" in between pieces of log output 16:36
Geth MoarVM/new-disp: e0dfe3d583 | (Jonathan Worthington)++ | src/spesh/disp.c
Elide temp guards in DP translation
 16:38
jnthnwrthngtn I just ammended the last commit, to save us a fix in post :)
timo so that a script that analyzes the spesh log can get an overview of the contents very fast
lizmat timo: that would be the amount to seek onward from after that line? or from that lne? 16:41
and I assume that would be bytes to seek, right?
timo that's the absolute byte position to seek to to get to the previous skip line, which is always before something interesting
lizmat ah, absolute position.... hmmm 16:42
timo so you'd start at the end and search backwards for the last skip line that was printed, since the end of the file could be in the middle of something if you ctrl-c'd or so
vim also has a command to go to an absolute byte position :)
lizmat ah, ok, gotcha 16:43
timo currently it puts a line after each specialization, after the specialization plan, and after the statistics update
if you just use grep to go through the whole file and get all "^skip:" lines, you can get all of that in like a second for 4.3k entries, which is 1.3 gigabytes of speshlog from an incomplete core setting compilation 16:46
i should write a quick raku script to see how fast i can go backwards through the file 16:50
jnthnwrthngtn Hm, and got a clean sepctest, but that doesn't really make me think the bugs are totally gone, just that the sprintf one didn't fail this time around 17:01
lizmat: There's likely further test-t improvement now on new-disp 17:02
lizmat oki, will test in a mo
timo 2.7 seconds with a naive implementation to skip through that whole file from the end 17:08
this implementation uses regexes :) 17:12
lizmat wow
timo the power of reading only a little bit every couple hundred kilobytes ;)
lizmat test-t results of today compared to yesterday: 1.954 -> 1.651, .870 -> .842 17:13
jnthnwrthngtn++ # getting quite a bit faster again 17:14
jnthnwrthngtn Remind me of the master numbers again?
lizmat test-t: 1.372 , test-t --race: .634 17:15
jnthnwrthngtn m: say 1.651 / 1.372
camelia 1.203353
jnthnwrthngtn Hm, quite a bit to go still
timo aww 17:16
jnthnwrthngtn Wonder if it's more missing inlines or something else
OK, got a spesh bissect of sprintf-c.t and it's to a sensibly sized frame 17:18
lizmat I can past a list of unsuccessful inlines for test-t :-) 17:19
*post
gist.github.com/lizmat/5c3ec7c2829...466a51229a 17:20
jnthnwrthngtn: I see a lot of sp_assertparamcheck in that list 17:21
jnthnwrthngtn Hmmm, you're on MoarVM HEAD, yes?
Hm, yes, or why'd you see an improvement... :)
There's those but "a deopt may happen before arguments are processed" is also present in some quantities
lizmat yeah, this is on new-disp
yup 17:22
jnthnwrthngtn 6x infix:<eq> BB(4783, 146 bytes) -> BB(340):
a deopt may happen before arguments are processed
Failing to inline eq for example is ungood
And yeah, sp_assertparamcheck too
lizmat reminder: just run your script with -MSIL to produce such a report
timo lizmat: one good thing about having the file split into sections like this from the very beginning is that it opens you up to the possibility of multithreaded processing of the pieces 17:23
jnthnwrthngtn ah, that's why it looks different from MVM_SPESH_INLINE_LOG=1 :)
lizmat timo: indeed, that would be great!
jnthnwrthngtn Yeah, there's still a load of missed inlines in there.
lizmat yeah, it's post-processing of that log
also I find this one intriguing: target has a :useshll instruction and HLLs are different - ins: hllbool 17:24
jnthnwrthngtn Yes, that shows up quite a lot
Not sure where that's coming from
Anyway, glad to have plenty of leads :) 17:25
timo we can't just turn that into a wval during inlining?
jnthnwrthngtn Rather than "it's slower but we've no idea where to look"
timo ah, hllbool does not only the type but also the value i guess
but hllboolfor could be a thing
as an sp_ op if we prefer 17:26
jnthnwrthngtn Probably I'd put the bool values into spesh slots and have an op like sp_truefalse w(obj) r(int64) sslot sslot
At first guess
timo target has a :useshll instruction and HLLs are different - ins: return_i <- if we inline something that has return_i into something that has some kind of invoke_i this would be okay to ignore at least
jnthnwrthngtn Indeed, not sure how smart we are about that 17:27
There was a deopt in the frame that the sprintf failure bissects to, which makes it very likely to be a further deopt bug (given I've fixed a bunch of issues there, I can imagine there's another more subtle one left) 17:31
const_i64 r5(1), liti64(0) 17:33
unless_i r5(1), BB(7)
Uh :)
That's a curiously missed opportunity
timo jnthnwrthngtn: fine to commit and push the skip lines change? it adds a function to src/spesh/debug.h and .c (to tell the position of the debug filehandle) and src/spesh/worker.c to do all the telling and outputting 17:34
jnthnwrthngtn timo: Seems harmless 17:35
OK, this is at least seemingly a different kind of deopt bug... 17:36
The target PC clearly matches up with an inline, but I see no uninlining happen 17:37
Geth MoarVM/new-disp: a6e7b00047 | (Timo Paulssen)++ | 3 files
put "skip:1234" lines in spesh log to allow fast segmentation

every skip line leads to the previous skip line, and the lines occur between individual specializations, and between stats updates and spesh plans		 17:38
MoarVM/new-disp: c2e8eb19bb | (Timo Paulssen)++ | tools/backskip_spesh_log.raku
quick script to segment spesh log by skip lines
 17:40
timo lizmat: you can steal this code to segment the spesh log and do whatever you like with the result :)
jnthnwrthngtn Hmmm 17:41
dogbert17 jnthnwrthngtn: I have failed in my golf attempts 17:42
Geth MoarVM/new-disp: e4ab24e1ed | (Timo Paulssen)++ | tools/backskip_spesh_log.raku
make script less debugspammy, give it a MAIN sub
 17:43
jnthnwrthngtn Argh. github.com/MoarVM/MoarVM/commit/2a...8920c703df
timo 963 megabytes big spesh log, the script runs in 2.14s of which about 1s is sys time
jnthnwrthngtn dogbert17: I didn't golf it, but I did figure out (sort of) what's going on
In the commit I linked...I fixed something...but it turns out it's wrong anyway 17:44
dogbert17 argh
jnthnwrthngtn Thanks to nine++ I think a proper fix as suggested in the commit message is now possible 17:48
18:02 reportable6 left
lizmat timo: I have a spesh log with 149 skip: lines in it, yet your script only produces 2 locations? 18:03
timo oh can i see? 18:04
18:04 reportable6 joined
lizmat jnthnwrthngtn: at HEAD on new-disp, test-t with MVM_SPESH_LOG segfaults 18:04
timo oh yikes, did i break that, then? 18:05
lizmat I guess the -MSIL ignores the segfault
I should probably do something about that 18:06
timo is this -MSIL part of Text::CSV? 18:37
oh, no, its in rakudo 18:38
Geth MoarVM/new-disp: 04f00e18b8 | (Jonathan Worthington)++ | 2 files
Account for pre-vs-post deopt in uninlining

When we have a pre-deopt point, we want exclusive; when it's a post deopt point, it should instead be considered inclusive.		 18:39
jnthnwrthngtn OK, that gets the spectest regressions I caused sorted out 18:40
timo wheee
jnthnwrthngtn So now I think we're back to me needing to break more things^W^W^Wget us inlining more
Although probably not today :) 18:41
timo Thread 2 "spesh optimizer" received signal SIGSEGV, Segmentation fault. 18:55
[Switching to Thread 0x7ffff6e36640 (LWP 4073841)]
MVM_spesh_graph_add_comment (tc=tc@entry=0x4c0330, g=g@entry=0x7ffff01e1750, ins=ins@entry=0x0,
ah, first_inserted is null when trying to put the "start of dispatch program translation" comment in 18:56
easy enough to fix
but then we return null from translate_dispatch_program, which the caller will interpret as failure, and it will rewrite the dispatch to sp_dispatch_* instead of inlining 18:58
i guess when ins->next is null, that means we put nothing after the dispatch op in terms of guards and such, and aren't even outputting like a return value? must be a dispatch_v in that case i guess 19:01
lizmat is in rubber duck mode 19:02
timo looks like it was a BB that had only dispatch_v for raku-sink in it 19:06
this is ThreadPoolScheduler's run-one
"catastrophic success" :) 19:09
so optimize_disp called from spesh's main optimization loop would set the "ins" pointer to the result of optimize_disp, which would usually be the first thing it inserted, so we can resume optimization with the next op immediately ... though it might be a better idea to set that as the next step's instruction, so we don't always skip one 19:17
19:20 vrurg left
timo i wonder if it'd be a good time to look into a different structure for this. like perhaps a little "iterator" struct that optimization functions can attach some signalling data to 19:48
lizmat is not sure what "this" is 20:01
dogbert17 the last test in t/spec/S06-advanced/callframe.t fails from time to time 20:03
jnthnwrthngtn At least for the "did this translation succeed" bit an out parameter for the first instruction produced and turning the return value into a predicate would be decently need 20:24
It is nice when dispatch programs translate to nothing :) 20:25
timo aye 20:26
[Coke] looking at VLA in src/jit/expr.c - changing the init to MVM_malloc is easy. Trying to find the scope where we'd free it. 20:44
jnthnwrthngtn [Coke]: It'll probably be a bit costly to malloc/free it for every single op we JIT; perhaps a malloc out of the loop with some initial size, keep a variable with that size, and realloc it if it's ever too small, would work 20:55
[Coke] ok. That's definitely above my pay grade. :) 20:58
Having re-read it; it's definitely *slightly* above my pay grade, I might be able to do it. 21:02
if we move to a pointer outside the loop, how do I clear it each loop? If the size changes, I can free/alloc then; if it doesn't need to grow, how do I empty it? 21:11
Geth MoarVM/jit-vla: ec66008dca | Coke++ | src/jit/expr.c
Avoid VLA usage.

Instead of allocating each time through the loop, keep a small array to reuse each time through the loop. Expand the size of the array when necessary.		 21:23
timo [Coke]: can always memset it 21:33
21:39 [Coke] left
jnthnwrthngtn I don't think it needs to be cleared, fwiw 21:56
timo sorry i didn't even look at the code yet :) 21:59
dogbert17 const_iX NYI 22:01
in block <unit> at t/spec/S09-typed-arrays/native-shape1-num.rakudo.moar line 159
what might this be?
timo bytecode / memory corruption 22:03
const_iX are some of the lowest bytecode values
could be a register number being interpreted as an opcode for example 22:04
dogbert17 aha 22:05
doesn't happen very often, running with a 16k nursery. At least I got with --ll-exception 22:21
gist.github.com/dogbert17/662422c7...60e117e141
jnthnwrthngtn Could well be deopt related, if it puts control back in the wrong place 22:22
Geth MoarVM/new-disp: 4624e74755 | (Timo Paulssen)++ | 3 files
properly signal success from disp optimization

we can end up generating no ops at all, for example when a dispatch_v calls raku-sink and neither guards nor calls are generated, we would return NULL here, but that was also the signal to emit an sp_dispatch op instead, believing we were unsuccessful in generating.		 22:40
timo i think this will also give the very first instruction generated from every disp program the chance to be optimized, which may have been missed before 22:47
making stresstest now to make sure i didn't futz it up 22:48
japhb
.oO( World's most tame drill sergeant: "DO YOU HEAR ME PRIVATE? DO! NOT! FUTZ! IT! UP!" )
 22:51
timo not ok 21 - did we get the right callframe each time? 23:07
# at t/spec/S06-advanced/callframe.rakudo.moar line 99
# expected: '300'
# got: '205'
did i break this? :o
23:47 linkable6 left, evalable6 left 23:50 linkable6 joined, squashable6 left 23:51 squashable6 joined
dogbert17 timo: no, you didn't break it 23:57
timo \o/
dogbert17 at least I don't think so 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!