github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
01:48 lizmat left 02:03 lizmat joined, p6bannerbot sets mode: +v lizmat
Geth MoarVM: 40d7eb998d | (Timo Paulssen)++ | src/jit/graph.c
Allow JIT To Devirtualize slice, Not Just splice
 03:31
timotimo in case of insomnia: hack on the JIT
Geth MoarVM/devirtualize_vmarray_access: e667a3441a | (Timo Paulssen)++ | 3 files
JIT Devirtualize atpos_o To A Smaller Function

when the jit already knows the type of VMArray, especially the slot kind, it can skip not only the big switch/case for "which slot type do we have?" but also the check for slot and register mismatch that would throw an exception at run time.		 04:04
timotimo could actually also devirtualize delegation of positionals/associatives in p6opaque 04:20
07:50 domidumont joined, p6bannerbot sets mode: +v domidumont 08:58 domidumont left 09:22 lizmat left 12:41 lizmat joined, p6bannerbot sets mode: +v lizmat
Geth MoarVM/jit-expr-float: 6 commits pushed by (Bart Wiegmans)++ 15:13
timotimo the computer i'm at, and the one i can access via ssh aren't stable performance-wise; can somebody build and run a benchmark to see if atpos_o gets any faster with the devirtualize_vmarray_access branch? 16:23
i ran a fannkuch implementation with callgrind which is supposed to eliminate influence of cpu scheduling and other distractions, but it showed more Ir with than without devirtualize, which is, to say the least, not what i had hoped for :) 16:29
but a quick perf record also showed only like 0.2% samples inside the "improved" atpos implementation
so maybe it's far too low in actual usage to register at all
16:36 lizmat left 17:15 TimToady left 17:20 TimToady joined 17:21 p6bannerbot sets mode: +v TimToady 17:28 lizmat joined, p6bannerbot sets mode: +v lizmat
timotimo oh, when's the last time we checked for a new libuv version? 18:00
the version i have in 3rdparty is 4 months old 18:01
hum. when i rely on a fact in the jit, i have no way to signal back to spesh to keep guards around that ensure these flags, so do we actually have a step in spesh that clears flags that weren't relied upon so that the jit doesn't accidentally read a non-guaranteed fact? 19:34
uh oh, i think my last master commit may be wrong 19:42
oh how easy it is to mess up jitting :D 19:43
aha slice and splice are actually different enough to b0rk 19:47
Geth MoarVM: 4c8e842a45 | (Timo Paulssen)++ | src/jit/graph.c
Revert "Allow JIT To Devirtualize slice, Not Just splice"

This reverts commit 40d7eb998d23dcf2246147080e2c79c10327ecce.
The op signatures of splice and slice differ, this devirtualization broke slice.		 19:49
timotimo a job for later when headache is less
timotimo ooh, slice has a repr_alloc_init built-in 19:53
well, i can do that
i can even fastallocate that, i bet!
fastcreate* 19:54
oh, that requires adding another spesh slot. can that still be done in the jit? might be too late perhaps? 19:56
let's try it and see how violently it explodes :) :)
Geth MoarVM: afd8f93706 | (Timo Paulssen)++ | src/jit/graph.c
JIT Devirtualize slice (and the create it implies)

immediately calling into the REPR's slice function is already a nice benefit, but being able to emit a fastcreate if the type is known and benign is a nice extra bonus.		 20:33
MoarVM/devirtualize_vmarray_access: 16b9b79e55 | (Timo Paulssen)++ | 3 files
JIT Devirtualize atpos_o To A Smaller Function

when the jit already knows the type of VMArray, especially the slot kind, it can skip not only the big switch/case for "which slot type do we have?" but also the check for slot and register mismatch that would throw an exception at run time.
MoarVM/devirtualize_vmarray_access: bd43dcc9df | (Timo Paulssen)++ | 2 files
JIT: Double-Devirtualize atpos_i

only limited usefulness, since rakudo code mostly generates atposref rather than atpos instructions.
Spesh will, at some point, know to turn atposref into atpos, though, and atposref can also be double-devirtualized in much the same way atpos currently is.
20:53 travis-ci joined, p6bannerbot sets mode: +v travis-ci
travis-ci MoarVM build failed. Timo Paulssen 'JIT Devirtualize slice (and the create it implies) 20:53
travis-ci.org/MoarVM/MoarVM/builds/472441972 github.com/MoarVM/MoarVM/compare/4...d8f93706c3
20:53 travis-ci left
timotimo wow, that's ... interesting? 21:02
but it's --no-jit, so my commit wouldn't be what breaks things?
oops, the log disappeared immediately when i clicked restart job
so i don't have the exact file that broke
just know we have a flopper, i guess?
timotimo speshes elems on VMArray into a sp_get_i64 21:12
hm. elems is uint, and get_i64 isn't "for" uint 21:15
i think it ought to be fine, though, since it "just" copies the whole 64bits however they are
gotta be a rather big machine that can get 2**63 slots, even in an int8 array 21:18
now here's a fun one: 'symbols' creates a BOOTHash - specialized from having a param_sn - and shortly thereafter the elems of it is checked; spesh doesn't know that it's empty, though, and so the unless_i after it can't be constant-folded away 21:24
fixing that would require proving that nothing is messing with that hash, though
it has a whole bunch of deopt usages, too, the *%attrs argument 21:39
Geth MoarVM: 45d15efe90 | (Timo Paulssen)++ | src/6model/reprs/VMArray.c
Turn elems On VMArray Into Direct Memory Access

replace the full function call, which was far too much overhead just to read an integer at an offset inside the object.		 22:15
22:37 travis-ci joined, p6bannerbot sets mode: +v travis-ci
travis-ci MoarVM build failed. Timo Paulssen 'Turn elems On VMArray Into Direct Memory Access 22:37
travis-ci.org/MoarVM/MoarVM/builds/472466290 github.com/MoarVM/MoarVM/compare/a...d15efe9023
22:37 travis-ci 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!