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:03 reportable6 left 00:04 reportable6 joined 00:53 evalable6 joined 00:55 linkable6 joined 01:53 benchable6 joined 03:52 benchable6 left, nativecallable6 left, sourceable6 left, unicodable6 left, greppable6 left, shareable6 left, bloatable6 left, tellable6 left, coverable6 left, reportable6 left, quotable6 left, bisectable6 left, statisfiable6 left, notable6 left, evalable6 left, linkable6 left, committable6 left, releasable6 left, tellable6 joined 03:53 releasable6 joined, notable6 joined, benchable6 joined, greppable6 joined, bisectable6 joined 03:54 reportable6 joined 03:55 quotable6 joined, shareable6 joined 04:53 statisfiable6 joined, committable6 joined, linkable6 joined 04:54 coverable6 joined 04:55 bloatable6 joined, sourceable6 joined 05:13 squashable6 joined 05:52 nativecallable6 joined 05:53 unicodable6 joined 05:55 evalable6 joined 06:03 reportable6 left 06:29 squashable6 left 07:39 squashable6 joined
nine eCerhs 08:12
08:25 lizmat_ joined 08:26 RakuIRCLogger left, TempIRCLogger left, Geth left 08:28 lizmat left 09:05 reportable6 joined 09:13 lizmat_ left, lizmat joined, RakuIRCLogger joined 09:14 Geth joined 09:15 TempIRCLogger joined 10:55 reportable6 left, sourceable6 left, evalable6 left, greppable6 left, coverable6 left, bisectable6 left, benchable6 left, bloatable6 left, releasable6 left, committable6 left, shareable6 left, tellable6 left, quotable6 left, linkable6 left, squashable6 left, unicodable6 left, statisfiable6 left, notable6 left, nativecallable6 left 10:56 shareable6 joined, notable6 joined, statisfiable6 joined 10:57 reportable6 joined, bisectable6 joined 10:58 quotable6 joined, committable6 joined, coverable6 joined 11:56 greppable6 joined, squashable6 joined, linkable6 joined 11:58 tellable6 joined, unicodable6 joined 12:02 reportable6 left 12:56 benchable6 joined, bloatable6 joined, releasable6 joined 13:04 reportable6 joined
MasterDuke hm, i get an insta-segv with gist.github.com/MasterDuke17/42081...348cc66f73 (asm implementation of scsetobj), anybody see something obvious? 13:24
annoying more difficult to debug the jit. i almost instinctively started gdb with MVM_JIT_DISABLE=1 to get better backtraces, but realized how silly that would be before actually doing so 13:27
nine Where exactly is it segfaulting? 13:50
MasterDuke: fun fact: ARG1 and TMP1 are exactly the same register: rcx. So you're overwriting sc in mov ARG1, TC; 13:53
TMP5 and TMP6 are the only safe work registers once you start setting up args 13:54
13:57 sourceable6 joined 14:57 nativecallable6 joined 14:58 evalable6 joined 16:33 quotable6 left, linkable6 left, coverable6 left, reportable6 left, squashable6 left, statisfiable6 left, committable6 left, shareable6 left, bisectable6 left, notable6 left, benchable6 left, tellable6 left, greppable6 left, unicodable6 left, sourceable6 left, nativecallable6 left, evalable6 left, bloatable6 left, releasable6 left, nativecallable6 joined, greppable6 joined, committable6 joined, benchable6 joined 16:34 squashable6 joined, tellable6 joined, releasable6 joined 16:35 statisfiable6 joined 16:36 bisectable6 joined
MasterDuke huh. well, luckily i was only using two, so s/TMP1/TMP5/ and s/TMP2/TMP6/ was easy, but i still get what appears to be the same segfault 16:55
which means the segfault must be pretty early? it looks like it's right at getting the first register, but why would that segv? 16:59
added gdb's printout of the assembly where it happens 17:03
17:34 shareable6 joined 17:35 notable6 joined, coverable6 joined, linkable6 joined
timo are the TMP registers saved or perhaps overwritten by the call? 17:52
MasterDuke yeah, was wondering that 18:01
timo have you been able to rr this? 18:02
and do you know the gdb "gui" mode where you can have the assembly always open in a little subwindow, as well as the registers?
MasterDuke i haven't tried. i've sort of assumed it was me just doing something really obviously wrong to someone who actually knows assembly 18:03
timo ha
yeah, i don't have all the details in my head at the same time 18:04
MasterDuke yeah, i was just experimenting with it, but don't like how i don't seem to be able to scroll back up after scrolling down in the disassembly listing
timo oh? well that's certainly strange
i do know that i have to use different keybinds to recall older comands when it's up
maybe there's something similar to the assembly view as well
or maybe the problem is not having the start sybol available, since you can't trivially go backwards in assembly since it's variable-width 18:05
MasterDuke according to wikipedia "If the callee wishes to use registers RBX, RSP, RBP, and R12–R15, it must restore their original values before returning control to the caller. All other registers must be saved by the caller if it wishes to preserve their values." 18:07
i had read that but remembered it backwards 18:08
so yeah, that's probably it
timo maybe we'll want a little section at the top of the file with comments, like a summary "for dummies" which registers are the same with different names (tmp vs arg) and what's caller vs callee saved, and stuff like that 18:12
i could certainly use that whenever i'm in that file 18:13
18:35 evalable6 joined, quotable6 joined, unicodable6 joined 19:03 reportable6 joined 19:34 sourceable6 joined 19:37 brrt joined
Nicholas good *, brrt 19:37
brrt ohai Nicholas
good *
lizmat brrt: in latest news: test-t runs faster with the expression JIT disabled 19:45
lizmat is tired and calls it a day 19:46
brrt :-( 20:02
lizmat: on new-disp, or in general
20:04 brrt left 20:05 ggoebel joined
ggoebel brrt: it runs faster with expression jit disabled on both master and disp... colabti.org/irclogger/irclogger_lo...09-24#l272 20:08
tellable6 ggoebel, I'll pass your message to brrt
ggoebel brrt: maybe backtrack from this point in the logs: colabti.org/irclogger/irclogger_lo...09-23#l468 20:10
tellable6 ggoebel, I'll pass your message to brrt
20:22 brrt joined
brrt \o 20:22
tellable6 2021-09-26T20:08:57Z #moarvm <ggoebel> brrt: it runs faster with expression jit disabled on both master and disp... colabti.org/irclogger/irclogger_lo...09-24#l272
2021-09-26T20:10:23Z #moarvm <ggoebel> brrt: maybe backtrack from this point in the logs: colabti.org/irclogger/irclogger_lo...09-23#l468
brrt sorry, magit crashed emacs
thanks ggoebel 20:23
jnthnwrthngtn brrt: Dunno if you noticed, but I did a patch for the expr JIT that prevented it from blocking JIT compilation from happening at all (by creating labels that never made it into the JIT graph and didn't get fixed up); I've not done that much with the expr JIT impl before, so a check I didn't do anything too terrible might be wise. 20:26
brrt jnthnwrthngtn: on new-disp, or on master? 20:35
jnthnwrthngtn new-disp 20:36
Although I think master might have been vulnerable to the same style of issue 20:37
Even if we didn't actually observe it yet
brrt hmm.... 20:41
honest truth is that I've forgotten why I did it exactly like that.
timo i wonder what the effect would be if we checked if there's already another spesh log in the queue when we've finished updating stats for the first one, perhaps even up to three at a time 20:42
more stats going in the specializations we do have
OTOH, more waiting for specializations to appear in the code-running threads
jnthnwrthngtn new-disp seems to consistently produce much smaller profiler output 20:50
I know a reason is that unlike spesh plugins, new-disp can decide some things without any invocation, thus less call records
I didn't expect it to make this much difference 20:51
Example: I profiled Agrammon to see why it's a little slower under new-disp. The new-disp profile output is ~30MB. The master one is ~87MB. 20:52
Thing is that profiling of CORE.setting also became feasible without running out of memory (on a box with a lot of memory) 20:53
*compilation of CORE.setting
And this isn't so conveniently explained.
(I have looked over profile results we see on new-disp. So far as I can tell, they are as legit as the master ones.) 20:54
(Also, those output sizes are for the .sql)
timo the thing you mean with "less call records", is that like before most frames had one (or a couple) calls to a proto (or similar) and then a couple hundred or thousand or whatever to the actually "chosen" target 20:56
brrt so... I probably need to debug expr jit, and in the meantime maybe disable it? 21:16
21:22 evalable6 left, linkable6 left 21:24 evalable6 joined
japhb Speaking of the JIT(s) -- has anyone started looking at porting the JIT to AArch64 (ARMv8-A and above, ~2014+ in the wild)? 21:42
jnthnwrthngtn timo: I think the fact that every scalar assignment and return type check used a spesh plugin, and called a (tiny) function that would later be inlined away 21:45
timo: That can add up fast.
The idea being that at peak performance they're inlined away so it "didn't matter"; as we can see, while it in some senses didn't matter, in others it did. 21:46
Well, also: the scalar assignment case still *is* a small call to inline. But return type checks usually aren't. 21:47
In new-disp they are usually just a dispatch program with a value result 21:48
lizmat does that imply we should get rid of them in the core ?
jnthnwrthngtn Moreover, sinking often elides the method call to .sink now too 21:49
lizmat: I mentioned so many things I'm not sure which "them" you mean :)
lizmat the return type checks
jnthnwrthngtn lizmat: No; in master we could often elide them entirely but only after spesh + inlining; with new-disp that is still true but *also* they carry far less cost even before the specializer kicks in. 21:51
lizmat ok *phew*
jnthnwrthngtn lizmat: So their value is high (for tooling), and their cost - at least for the nominal common case - is in new-disp lower than it's ever been. 21:52
lizmat understood 21:53
sleep&
jnthnwrthngtn 'night o/ 21:54
japhb o/
brrt 'night
japhb: some people have mentioned it to me, none have volunteered
japhb I'm going to assume the answer to my previous question was "No, nobody's started looking at AArch64 JIT" ... are there any people here *experienced* with AArch64?
brrt: OK, gotcha 21:55
brrt I've only looked at it very, very superficially
it didn't exactly look hard
it maybe the case that some of my more devious tricks don't work
jnthnwrthngtn brrt: Was the hope that we'd largely move completely to the expression JIT, and then such a port is easier?
brrt yes 21:56
japhb brrt: If I wanted to understand the level of pain required, what would I need to study within MoarVM? Meaning, which parts need to be understood to begin the work, given how big MoarVM is now?
brrt japhb: there's a couple things really dependent on architecture 21:57
japhb listening
brrt so the old template JIT; it has a file `emit_x64.dasc`, this has x64 assembly 22:00
I don't.. really even know if dynasm has aarch64 support. I don't really think it does 22:02
japhb Well crap, that's quite a yak shave
brrt yup 22:03
japhb Oooh, github.com/zenkj/dasm-a64
brrt neat
we're using a branched version anyway, so we might integrate it
ok, yak apparantly shaven 22:04
anyway, there's two downsides of the template JIT relevant here;
japhb Interesting, looks like Dynasm 2.1 has some support as well: github.com/LuaJIT/LuaJIT/tree/v2.1/dynasm 22:05
brrt it sure does...
well, that means that we'd better integrate our own changes back as well...
downside one; it means you have to write a bunch of assembly code 22:06
downside two; the author didn't take portability into account at all
it might be much easier than I imagine, it might not be
then for the expression JIT, you in theory have a somewhat easier time:
you'd write a bunch of tiles (as in, the 'tile_pattern.tile' file) and then you implement them (in a `tiles.dasc`) file 22:08
and then you'd write a register ABI defition similar to `src/jit/x64/arch.h` and `arch.c` 22:09
and... you should be good... but all of this is untested in practice 22:10
japhb OK, that gives me a start. Will probably have more questions as I figure out what I don't know. :-) 22:11
(Note to folks watching: I am *not* volunteering to do this work, or at least, not at present. I'm just trying to scope it and estimate the work involved.) 22:12
brrt who's the intern under your control? :-P
japhb Interns are never under control. That's the exciting bit. :-) 22:14
brrt I think the biggest thing that I didn't talk about yet, is the register allocator; it supposedly works in an ABI agnostic way, I suspect that's really not as true as I'd like 22:15
well, this is true, I should've said 'the intern you will point at things'
japhb brrt: "Pay no attention to that man behind the curtain! I am the great and powerful ... uh ..." 22:18
brrt night & 22:36
22:36 bloatable6 joined, brrt left
japhb o/ 22:40
23:24 linkable6 joined
jnthnwrthngtn fwiw, were I planning to work on a port to another architecture, I'd probably start by greatly increasing the amount of instructions the template JIT can cover, hoping to learn lots about it along the way that would be useful for the architecture addition 23:50
(I'm sorta interested to get into figuring out how to get us spitting out better machine code, but so far it's always been more stategic for me to spend my time getting us throwing better things into the JIT) 23:53
On that topic, I just enjoyed reading through travisdowns.github.io/blog/2019/06...imits.html and learned no small amount :) 23:55

Powered by Cro and the Raku® Programming Language.

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

Thank you!