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.
Mondenkind ix.io/3BTg this seems to have gotten much slower in new-disp (2s -> 50s, iirc) 06:46
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
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?
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
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
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
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
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
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
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