github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:17 evalable6 left, linkable6 left 00:18 linkable6 joined 00:19 evalable6 joined 00:27 Kaiepi left 00:47 Kaiepi joined 01:59 lucasb left 06:27 Altai-man joined 07:28 tib left 07:29 tib joined 07:34 domidumont joined
nwc10 good *, #moarvm 07:54
nine good new week! 08:03
08:07 domidumont left 08:08 domidumont joined 08:12 sena_kun joined 08:13 Altai-man left 08:39 zakharyas joined 08:43 domidumont left 08:52 patrickb joined 08:56 domidumont joined 09:44 zakharyas left 09:57 zakharyas joined 10:04 lizmat_ joined 10:08 lizmat left, lizmat_ left 10:14 lizmat joined
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
12:11 Altai-man joined 12:14 sena_kun left 13:12 zakharyas left
timotimo MasterDuke: were you able to get any measurements for that change? 13:33
14:04 lucasb joined 14:25 leont joined 14:44 zakharyas joined 15:55 vrurg_ joined 15:56 vrurg left 15:58 vrurg_ left 16:00 vrurg joined 16:01 patrickb36 joined 16:02 patrickb left 16:12 sena_kun joined 16:13 Altai-man left 16:18 patrickb36 left 16:23 patrickb joined
lizmat And yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2020/11/30/2020-...on-fosdem/ 17:46
jnthn lizmat++ 18:10
18:25 domidumont left
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?
18:36 zakharyas left
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
19:49 zakharyas joined
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
20:12 Altai-man joined
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?
20:13 sena_kun left
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
21:01 vesper11 left
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
21:33 lucasb left
timotimo d'oh :) 21:37
21:37 zakharyas left 21:48 Altai-man left 22:13 patrickb left
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