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 |