|
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 | ||