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:03 reportable6 joined
[Coke] drinks a cherry coke zero 00:32
02:03 Kaiepi left, Kaiepi joined 03:29 shareable6 left, bisectable6 left, statisfiable6 left, linkable6 left, reportable6 left, quotable6 left, greppable6 left, notable6 left, squashable6 left, evalable6 left, releasable6 left, unicodable6 left, committable6 left, bloatable6 left, nativecallable6 left, benchable6 left, sourceable6 left, coverable6 left, tellable6 left, greppable6 joined 03:30 benchable6 joined, tellable6 joined, committable6 joined, squashable6 joined, reportable6 joined, bloatable6 joined 03:31 sourceable6 joined, linkable6 joined, notable6 joined 03:32 nativecallable6 joined, statisfiable6 joined, bisectable6 joined, evalable6 joined, quotable6 joined, unicodable6 joined, coverable6 joined, releasable6 joined, shareable6 joined 04:32 reportable6 left, bloatable6 left, nativecallable6 left, notable6 left, benchable6 left, coverable6 left, bisectable6 left, releasable6 left, evalable6 left, greppable6 left, statisfiable6 left, sourceable6 left, shareable6 left, linkable6 left, committable6 left, quotable6 left, squashable6 left, unicodable6 left, tellable6 left 04:33 evalable6 joined, quotable6 joined, squashable6 joined, bloatable6 joined, coverable6 joined, shareable6 joined, benchable6 joined 04:34 greppable6 joined, statisfiable6 joined, releasable6 joined, unicodable6 joined, linkable6 joined, reportable6 joined, sourceable6 joined 04:35 notable6 joined, tellable6 joined, committable6 joined 05:35 quotable6 left, bloatable6 left, shareable6 left, evalable6 left, statisfiable6 left, sourceable6 left, linkable6 left, releasable6 left, reportable6 left, notable6 left, greppable6 left, squashable6 left, committable6 left, unicodable6 left, tellable6 left, coverable6 left, benchable6 left 05:36 nativecallable6 joined, releasable6 joined, benchable6 joined, evalable6 joined 05:37 bloatable6 joined, squashable6 joined, greppable6 joined, coverable6 joined, unicodable6 joined 05:38 linkable6 joined, reportable6 joined, quotable6 joined, statisfiable6 joined, sourceable6 joined, shareable6 joined, committable6 joined 05:39 notable6 joined, tellable6 joined 06:03 reportable6 left 06:04 reportable6 joined 06:51 frost joined 07:08 dogbert17 joined 07:11 dogbert12 left
Nicholas jnthnwrthngtn: woohoo! That's an excellent reason for bonus dry days 07:44
Geth MoarVM/set_sc_idx_during_deserialization: 0d63ddadf3 | (Stefan Seifert)++ | src/6model/serialization.c
Set sc.idx during deserialization to avoid costly lookup later

When we deserialize a collectable, we actually already know which SC it belongs to and the index in this SC. So far we've already told the the collectable about the SC, but not about the index. So the first call to MVM_sc_find_object_idx had to do a linear search of the SC to find the index. Fix by setting the idx field in the collectable header on deserialization.
This brings installation of rakudo core modules down from 7.89s to 7.21s and reduces CPU time of rakudo make test from 138.98s to 134.27s.
nine MasterDuke: looking at git push --set-upstream origin set_sc_idx_during_deserialization
MasterDuke: looking at MVM_sc_find_object_idx _was_ productive after all :)
08:17 squashable6 left, bisectable6 joined 08:18 squashable6 joined 08:59 patrickb joined 11:50 Kaiepi left 11:51 frost left 12:02 Kaiepi joined, reportable6 left
jnthnwrthngtn nine++, that's a nice spot 12:48
13:13 reportable6 joined
MasterDuke nice. i'll see what perf says with that and the rakudo branch also 14:07
with the moarvm branch, MVM_sc_find_object_idx is almost zero in perf 14:18
Nicholas So, for: dumbbench -i 100 -- ~/Sandpit/moar-O/bin/rakudo-m -e ""
master is 1.8948e-01 +/- 1.1e-04 (0.1%)
that branch is 1.85249e-01 +/- 8.6e-05 (0.0%)
m: say 1.85249e-01/ 1.8948e-01
camelia 0.9776704665400041
Nicholas 2% starup win
MasterDuke it's about 1.1s faster for `raku -I . 2Ry.rakumod` (where 2Ry.rakumod is the original script, but with only 100 of the subs) 14:20
7.3s before, 6.2s after
Nicholas nine++ # optimising hello world 14:21
jnthnwrthngtn Happily the rakuast startup time advantage has stuck around even with filling out the grammar, actions, AST nodes, etc. quite a bit more. 14:25
MasterDuke on moarvm master, but rakudo speed_up_native_call_setup, MVM_sc_find_object_idx is still at the top of the perf report at 11%, but total time decreased to 4.6s
jnthnwrthngtn Of course, getting compilation itself competitive is another matter. 14:26
MasterDuke and on moarvm set_sc_idx_during_deserialization + rakudo set_sc_idx_during_deserialization, total time drops to 4.0s (and MVM_sc_find_object_idx is out of the picture again) 14:27
so master/master is 7.3s, set_sc_idx_during_deserialization/speed_up_native_call_setup is 4.0s. nine++ 14:28
nine MasterDuke: I'm at my parents' for the weekend. Care to have a look at what dakudo's profiler says about where we're spending tkme now? I don't really have an idea 15:15
17:33 linkable6 left 17:36 linkable6 joined 18:02 reportable6 left 18:04 reportable6 joined 19:05 patrickb left 19:28 patrickb joined
MasterDuke nine: imgur.com/a/JBHH08n some screenshots of a --profile-compile output. the vast majority of the BOOT(Int|Str)s are from sift_down 19:56
[Coke] sift_down is the heap sort when sorting hash keys, aye? 20:02
MasterDuke github.com/Raku/nqp/blob/master/sr...qp#L16-L38 20:03
gist.github.com/MasterDuke17/4c010...526922f98a added a print in sorted_keys 20:06
adding an early exit when nqp::elems(@keys) < 2 seems to be a minor help 20:08
[Coke] wonder if all those sorts are on the same slowly growing hash
also wonder if there are any cases where we sorted but didn't need to. 20:10
MasterDuke i doubt it. iirc, we didn't used to sort (most? all?) things and nine only added them in where needed to get reproducible builds 20:11
[Coke] commented out #nqp::splice(@existing, $_.value, 0, 0); in src/NQP/Optimizer.nqp
MasterDuke but those growing numbers are interesting
looks like that commented out splice was in the original commit, github.com/Raku/nqp/commit/d062aa3...ef0aa27ea3 would have to ask jnthnwrthngtn 20:14
[Coke] Seems reasonable to remove it. 20:19
20:44 patrickb left
nine Or the other way round? If that loop still ezists, it could be replaced with the splice 20:54
MasterDuke it does, that code has been pretty much untouched since its introduction 20:56
spectest passes with the slice instead of the loop+push 21:19