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.
[Coke] drinks a cherry coke zero 00:32
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.
08:08
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 :)
jnthnwrthngtn nine++, that's a nice spot 12:48
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
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
yep
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
fair
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
afk
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