|
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
00:42
vrurg left
01:05
reportable6 joined,
vrurg joined
02:07
SmokeMachine left
02:08
SmokeMachine joined,
tbrowder left
02:09
tbrowder joined
02:36
frost joined
03:36
linkable6 left,
evalable6 left
03:37
evalable6 joined
05:45
committable6 left,
releasable6 left,
benchable6 left,
coverable6 left,
squashable6 left,
tellable6 left,
shareable6 left,
bisectable6 left,
reportable6 left,
sourceable6 left,
notable6 left,
nativecallable6 left,
evalable6 left,
quotable6 left,
unicodable6 left,
greppable6 left,
statisfiable6 left,
bloatable6 left,
squashable6 joined
05:46
bloatable6 joined,
statisfiable6 joined,
tellable6 joined,
bisectable6 joined
05:47
unicodable6 joined,
sourceable6 joined
05:48
committable6 joined,
reportable6 joined,
coverable6 joined
06:02
reportable6 left
06:05
reportable6 joined
06:39
linkable6 joined
06:46
releasable6 joined
|
|||
| Mondenkind | ix.io/3BTg this seems to have gotten much slower in new-disp (2s -> 50s, iirc) | 06:46 | |
|
06:47
notable6 joined
|
|||
| Mondenkind | interestingly, changing \x, \y to $x, $y makes it slower still (I heard the latter was faster now). I thought it might have something to do with the objects being type objects, but instantiating them has no effect on performance | 06:53 | |
|
07:23
frost left
07:46
quotable6 joined
07:47
evalable6 joined
07:48
greppable6 joined
|
|||
| Nicholas | docs.google.com/document/d/18CXhDb...n1vcxkfwqi -- Additionally, mimalloc’s layout of objects in the heap allows for finding all GC-tracked objects without maintaining an explicit list, which isn’t possible to do efficiently with pymalloc or other allocators built on top of malloc. | 07:52 | |
| I wonder if that property could be useful to us? | |||
|
08:34
frost joined
08:46
benchable6 joined
|
|||
| MasterDuke | wow, running the mqtt test with LD_PRELOAD=/usr/lib/libmimalloc.so dropped the time from ~5.8s to ~5.5s | 09:01 | |
| and takes ~3s off of compiling CORE.c, ~2.5s of that from stage parse | 09:10 | ||
| for Mondenkind's example, top three according to perf are: | 09:38 | ||
| 11.14% raku [JIT] tid 297337 [.] raku-multi-plan(gen/moar/BOOTSTRAP/v6c.nqp:5852) | 09:39 | ||
| 8.87% raku libmoar.so [.] MVM_disp_program_run | |||
| 6.93% raku libmoar.so [.] MVMHash_at_key | |||
| a profile says only 55% of the frames are jitted, 1289 GCs | 09:43 | ||
| lizmat | timo: selecting / deselecting for gist is now easier: just click on the message :-) | 10:42 | |
| tellable6 | lizmat, I'll pass your message to timo | ||
|
10:47
nativecallable6 joined,
shareable6 joined
11:04
timo joined
|
|||
| timo | thanks liz :) | 11:07 | |
| tellable6 | 2021-10-16T10:42:22Z #moarvm <lizmat> timo: selecting / deselecting for gist is now easier: just click on the message :-) | ||
| lizmat | now to get the gist menu on the mobile version :-) | ||
| timo | i haven't read much about mimalloc yet but at first glance it looks like gc managed objects are just in a separate "arena", which might in effect be equivalent to moar's nursery and gen2 | 11:10 | |
|
12:02
reportable6 left
|
|||
| jnthnwrthngtn | ix.io/3BTg is pretty much that we don't have any strategy for handling megamorphic cases of multi dispatch yet. | 12:03 | |
| And the example is very well written to exploit that. :) | 12:04 | ||
|
12:28
frost left
|
|||
| Geth | MoarVM: MasterDuke17++ created pull request #1566: Add some context to capture arg exceptions |
12:44 | |
| MoarVM: MasterDuke17++ created pull request #1567: Add JIT templates causing bails in a spesh log of a megamorphic multi dispatch example |
12:57 | ||
| MasterDuke | is it just me, or has the time for a spectest recently doubled? i'm pretty sure before new-disp was ~135s, sometime on new-disp it was ~175s (don't remember what it was immediately after the merge), and now it's ~355s | 13:33 | |
| jnthnwrthngtn | Don't recall it being slower than the new-disp usual yesterday, at least. That sounds like the difference between an optimized and unoptimized MoarVM | 13:46 | |
|
14:03
reportable6 joined
|
|||
| MasterDuke | my bash history would suggest it was *not* built with --optimize=0, but did a make clean and will rebuild everything to try again | 14:15 | |
| nope, still slow | 14:30 | ||
| compiling rakudo was normal speed, but test and spectest were definitely slower | 14:31 | ||
| dogbert17 | MasterDuke: I agree with you, there's been a recent regression | 15:02 | |
| MasterDuke | interesting... | 15:03 | |
| dogbert17 | I'm looking ... | 15:09 | |
|
15:18
evalable6 left,
linkable6 left
|
|||
| dogbert17 | MasterDuke: do you see any difference if you revert github.com/rakudo/rakudo/commit/33...da9c1bc934 ? | 15:22 | |
| MasterDuke | dogbert17++!! | 15:28 | |
| yep. would not have thought that one to be the cause | 15:29 | ||
|
16:21
evalable6 joined
17:21
evalable6 left,
linkable6 joined
|
|||
| lizmat | fwiw, I think we need to revert that commit to figure out why it is causing slowdown, so it won't be in the 2021.10 release | 17:40 | |
|
18:02
reportable6 left
18:03
reportable6 joined
19:23
linkable6 left
21:25
linkable6 joined
22:23
evalable6 joined
|
|||