github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
nwc10 good *, #moarvm 07:54
nine good new week! 08:03
sena_kun Noting we have nqp tests failing when moarvm is compiled with mingw compiler and it would be really great to fix them so that we could add this setup to our CI. More at github.com/MoarVM/MoarVM/pull/1385 10:29
timotimo MasterDuke: were you able to get any measurements for that change? 13:33
lizmat And yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2020/11/30/2020-...on-fosdem/ 17:46
jnthn lizmat++ 18:10
nine jnthn: I don't understand this: github.com/rakudo/rakudo/blob/mast...r.nqp#L176 18:28
Isn't this mixing in the herestop role into the same object over and over?
MasterDuke timotimo: i was pondering on that yesterday and today, but haven't been able to think of something that would show a change, but not be so artificial as to be useless. any suggestions? 19:49
timotimo no suggestions, except maybe using valgrind for the job? 19:54
nwc10 cachegrind can count instructions dispatched (and also cache misses, but likely that's less important here) 19:57
I found that about 10 runs was enough to even out hash randomisation reliably
I forget whether I'd disabled spesh
(because I forget what I was trying to test)
oh, I think I had spesh disabled, but was running "before" and "after" 19:58
timotimo spesh can reduce the amount of empty hashes being created
nwc10 (ie master, and various branches)
timotimo but most of these are trashed very quickly, so wouldn't get to gc_mark anyway
nwc10 that I didn't know. But I'm not sure if that matters if the initial goal is to measure whether the effect of the change is even measuable :-)
to be clear, I like the change. The element count is already needed and available, so putting into an if is (pretty much) free. Even if all it is is to jump past the body of the function to the "return" code. (I don't enough about enough CPU ABIs to know if "return right now" is cheap in void functions) 20:00
MasterDuke yeah, i was thinking cachegrind would be the tool, but it's good test raku code that i'm not sure of 20:03
timotimo core setting compilation is, of course, a very lengthy test for this :)
MasterDuke especially under cachegrind 20:04
nwc10 NQP compilation was fast enough under cachegrind. I have no idea how representative it is
MasterDuke hm, compiling CORE.d it only hits those returns 6k times, probably not enough to notice 20:13
timotimo well, core.d is tiny, isn't it?
MasterDuke yeah. hoped it be just big enough though 20:14
jnthn nine: No, the object it mixes in to is shifted off @herequeue_stub 20:47
nine: And it's seemingly pushing here: github.com/rakudo/rakudo/blob/mast...r.nqp#L214
And the herelang is from github.com/rakudo/rakudo/blob/mast....nqp#L5498 20:51
That in turn carries the lang to parse the heredoc *body* with; after `:to` we then switch the language of the quote we'll immediately parse now (for the delimeter) back to plain Q 20:52
Geth MoarVM: 5a21247e9f | (Jonathan Worthington)++ | src/6model/reprs/VMArray.c
Improve performance of repeated `unshift`ing

Prior to this, we always created a fixed amount of extra space (8 elements) at the start of the array, regardless of array size. With this change we start accounting for the number of elements in the array. This will make no difference for steady state unshift/pop, but for situations where we repeatedly unshift will bring the performance in line with that of push. Fixes #1382.
21:01
linkable6 MOARVM#1382 [closed]: github.com/MoarVM/MoarVM/issues/1382 Unshift performs very badly compared to push
Geth MoarVM: d0d6088afc | (Jonathan Worthington)++ | src/6model/reprs/VMArray.c
Remove duplicated word in comment
MoarVM: 31899fd374 | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/6model/reprs/VMArray.c
Merge pull request #1392 from MoarVM/faster-repeated-unshift

Improve performance of repeated `unshift`ing
jnthn nwc10: github.com/MoarVM/MoarVM/pull/1360 is still marked as a draft, but maybe it's already due a review now? 21:09
nine jnthn: but it doesn't mix into the $herestub it gets off that queue but into $herestub.grammar - which is always the same 21:10
jnthn Is it?
nine it's building nice +{herestop}+{herestop}+{herestop} chains 21:11
jnthn hah :) 21:12
I guess we cache quote languages somewhere 21:13
nine Came across it because of: Incompatible MROs in P6opaque rebless for types Perl6::QGrammar+{q}+{herestop}+{herestop}+{herestop} mixin and Perl6::QGrammar+{q}+{herestop}+{herestop} mixin
When running: rakudo-m --ll-exception -e '(^10000).race.map({EVAL "q:to/END/;\nEND\n"}).sink'
jnthn Which is good for parse performance...but here our bluff is called 21:14
It won't always be the same thing, for example it'll be different for q:to/foo/, qq:to/foo/, qq:!s:to/foo/, etc.
nine Hm....caching quote languages. Like in my %quote_lang_cache? 21:15
jnthn Yes, sounds familiar
So if we re-use a quote language involving a heredoc, we mix the herestop thing into it each time
Since the mixin is always the same, then it'd be safe to do it just once. 21:16
So far as I can tell
At first I thought the stopper was part of some parametric role we mixed in, but it isn't
raku-bridge <JackFly26> lmao when you said "No, the object it mixes in to is shifted off @​here queue_stub" it pinged on discord 21:25
timotimo d'oh :) 21:37
raku-bridge <Rogue> I haven't given the bot permission to do that ping but for some reason it did anyway... 22:39
MasterDuke timotimo, nwc10: i just tried 10 runs before/after of a somewhat random script that hits those return 6m times. avg instructions before is 4605054973, avg instructions after is 4594950376. avg I1 misses before is 20298523, avg I1 misses after is 19425487. avg LLi misses before is 91034, avg LLi misses after is 87616 23:38
the code is `use Physics::UnitAffixQ; use Physics::Measure; my $l = 1nm; say ~$l;`
m: say 4605054973 - 4594950376 23:41
camelia 10104597