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.
Geth MoarVM: MasterDuke17++ created pull request #1822:
Disable the expression jit by default
01:07
06:05 patrickb left, patrickb joined 07:06 nativecallable6 left, nativecallable6 joined
patrickb lizmat: What's your insights from the IRC log server test? Can ^ move ahead? 07:12
07:12 sourceable6 left, sourceable6 joined
Nicholas T̸̮̉̌͛͛̾̄͌͌̔̑́͝ȩ̵͖̰͔̜̪̮̮͎̗͎̞͓̮̓̎͜ͅs̸̨̥̹̞̖͇͙̺̗̘̗͔̱̔͂́̓̆̓̌̆͐̚t̷̡̢̬̰͖̩̪̥͎̰̙̞̠̚̕͠,̵̩͇́ 07:13
:̸̛̪̩͊̐̃̊̔͗̈́͛͑̇̑̔̈́̚p̸̲̝̻̻̝̗̟̪͙̹̀̓̆͋̇͆͑̇͜l̶̛͉̟̬̹̦̭̝̐͗͗̋̀͊̆̂̋͘͠͝͝e̷̪͍̬͎̳̣̪̯̠͉̝̞͚̬̝̻̓̅͌̀̅́̊͐̆̽̄̋̑͘͝a̵̡̢̡͕̺͔̫̞͖̠̯͉̠̒̍͛͛̀̅̇̚̚s̷̢͍͔͔͕̻̀̂͐̓͊͐̐̈́̃̓̂͒͑e̴͇̅̅́̃̓̅͒̔͛
:̶̡͎͎͙͍̳͕̤̳̹̻̋͆͗̑̋͛̌͑̑͝ͅi̵̝̹̊͌́̌̓̊̇͛̾͒̌͘ģ̵̰̩͔̣̝͚͖́̅̅̕ͅn̸̖͕͍̂̾͆o̴̧̡̘̖̺̪͎͙̪̺̹͙̦̹͋̌͒̋͂́́̏͜r̴̩̖̰̳͙̩̅̈́̊͌̾͑̋̐̾̌̉̒͑̀̄͋ȩ̴̛̞̼͔̑͑̓̎̐̓̒̾̀̂̆͌͝͝
Good *, #moarvm 07:14
07:16 linkable6 left 07:17 linkable6 joined
patrickb needed to look very closely to find out this is to be ignored 07:32
o/ Nicholas
07:52 sena_kun joined 08:12 ilogger2 left 08:13 ilogger2 joined
lizmat patrickb: IRC log server looking good 08:29
Geth MoarVM/main: ab56007b4b | MasterDuke17++ (committed using GitHub Web editor) | 4 files
Disable the expression jit by default (#1822)

Per github.com/MoarVM/MoarVM/issues/18...2217676548
08:34
09:02 MasterDuke left 09:17 sena_kun left 11:05 brrt joined
brrt \o 11:14
lizmat brrt o/ Rakudo now was EXPR JIT disabled by default 11:19
brrt I saw it
with sadness
lizmat yeah, sometimes you have to kill your darlings 11:20
brrt *sigh* 11:24
11:28 brrt left 11:40 MasterDuke joined
MasterDuke hopefully at some point the expr jit is tweaked for what moarvm/rakudo are like now and that can be reverted 11:42
timo you know, we could without too much difficulty come up with arbitrary rules where exprjit gets used or not used 11:52
lizmat then, by all means do: I wouldn't have a clue :-)
timo me neither 11:53
but it's not hard to, inside moarvm, put checks whenever we could do an exprjit attempt and just say "oh no it failed!" instead of trying anything
so even inside one function we could turn exprjit on, off, on, off, on, off 11:54
lizmat well, someone would have to put time into that
timo what's a little bit more tricky perhaps is to generate two variants of the jitted code, one with and one without exprjit, and then do something funky like try running it the first 100 times with exprjit on, the next 100 with exprjit off, and compare timings (only works correctly if every call to it does the same kind of work, of course) 11:55
right, just floating a test balloon if anybody thinks there's a use case for this
patrickb The reason the discussion around disabling exprjit started was not performance, but bus factor and reliability. We measured performance to find out if the loss in performance can be tolerated. That ExprJIT turned out to decrease the performance was an unexpected but welcome outcome. 13:27
So I'd say for exprjit to come back we'll need to find a way to get the bus factor back to at least 1 and have a perspective on fixing the reliability issues for good. 13:29
I am sad to see the thing go and do understand it must hurt a lot more for the people that invested time and energy in this. I'm sorry. I really am. But I do believe it's the right thing to do given the circumstances. 13:31
13:50 vrurg left 13:51 vrurg joined
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2024/07/15/2024-...exprjit-5/ 15:48
timo gist.github.com/timo/00097aafe9758...7ac5dfb830 - i desire to be praised :3 16:44
16:51 Woodi joined
lizmat jitcode found yay timo++ 17:30
17:43 rypervenche left, rypervenche joined
timo well, that part was old news :D 17:52
compare this: 0x00007ffff58e80c1 <+193>: call *0x232d(%rip) # 0x7ffff58ea3f4 <parse-thing+9204> 17:53
with this: 0x00007ffff58f40c2 <+194>: call QWORD PTR [rip+0xb72] # (call to 0x7ffff766b6a0 <MVM_gc_write_barrier_hit_by>)
18:01 MasterDuke left
lizmat timo: sorry, that is going *way* over my head :-) 18:48
timo well, the jit generates pointers to functions it calls in a little "data" segment that goes after the end of the bytecode 19:13
and then it refers to them by a relative offset instead of absolute 19:14
this is necessary For Reasons
but just disassembling the bytecode as-is with gdb will show you "it's calling <same function>+98765", since it doesn't know to follow the address and look the result up
so my code fixes that, and you get to see what a call is actually calling
another thing: 19:15
0x00007ffff58f408c <+140>: mov QWORD PTR [rbx+0x18],rcx # (r3 obj)
^- movs into or out of locals now have their index shown 19:16
lizmat I see... that should make debugging a lot easier! 19:23
timo 0x00007ffff58fd594 <+1428>: call QWORD PTR [rip+0x2401] # (call to 0x7ffff76aad00 <MVM_nativeref_read_lex_i>, returns MVMint64 into rax) 20:43
0x00007ffff58fd59a <+1434>: mov QWORD PTR [rbx+0x58],rax
gist.github.com/timo/bdffaecade359...1e5a425b47 hey look at that beautiful line 6 in the middle there! 22:39