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