#raku-dev on 19 August 2021 - Raku Programming Language Log

🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | log inspection situation still under development | For MoarVM see #moarvm
Set by lizmat on 22 May 2021.

00:30 linkable6 left, unicodable6 left, tellable6 left, evalable6 left, benchable6 left, greppable6 left, evalable6 joined 00:31 unicodable6 joined 00:33 greppable6 joined, tellable6 joined 01:31 benchable6 joined 01:32 linkable6 joined 02:29 japhb left 02:36 melezhik left 02:56 squashable6 left 02:58 squashable6 joined 03:28 MasterDuke left 03:58 japhb joined 04:03 reportable6 joined

japhb

m: use nqp; my int $t0 = my int $prev = nqp::time; my int $long = 0; my $t; for ^10_000_000 { $t = nqp::time; $long++ if nqp::isgt_i(nqp::sub_i($t, $prev), 10_000_000); $prev = $t; }; say (nqp::time() - $t0)/1_000_000_000; say $long;

04:06

camelia

4.632589257
1

japhb

m: use nqp; my int $t0 = my int $prev = nqp::time; my int $long = 0; my $t; for ^20_000_000 { $t = nqp::time; $long++ if nqp::isgt_i(nqp::sub_i($t, $prev), 10_000_000); $prev = $t; }; say (nqp::time() - $t0)/1_000_000_000; say $long;

camelia

9.152689692
1

04:07

japhb

m: use nqp; my int $t0 = my int $prev = nqp::time; my int $long = 0; my $t; for ^10_000_000 { $t = nqp::time; $long++ if $t - $prev > 10_000_000; $prev = $t; }; say (nqp::time() - $t0)/1_000_000_000; say $long;

camelia

7.823173845
0

04:08

japhb

m: use nqp; my int $t0 = my int $prev = nqp::time; my int $long = 0; my $t; for ^10_000_000 { $t = nqp::time; $long++ if $t - $prev > 5_000_000; $prev = $t; }; say (nqp::time() - $t0)/1_000_000_000; say $long;

camelia

7.715262905
2

japhb

m: use nqp; my int $t0 = my int $prev = nqp::time; my int $long = 0; my $t; for ^10_000_000 { $t = nqp::time; $long++ if nqp::isgt_i(nqp::sub_i($t, $prev), 5_000_000); $prev = $t; }; say (nqp::time() - $t0)/1_000_000_000; say $long;

04:09

camelia

4.323051041
52

japhb

OK, you can see it clearly in that last pair. I've been looking at this for a bit, and I'm mystified as to why it's happening.

I was trying to determine whether getting high-res time was stable performance-wise, so I started checking for "long" intervals (greater than N milliseconds between consecutive time reads).

04:11

I was stripping off extra layers of overlying code one piece at a time, until I was mostly just doing nqp:: ops and assignments within the loop.

04:12

That's when I noticed that turning the "long interval" check into nqp:: ops made the loop quite a bit faster, as expected ... but the number of long intervals per test went WAY up.

On my local laptop, I see that scale of difference with 10 ms long intervals; obviously whatever system camelia works on is faster, but accounting for the speed difference by dropping down to 5 ms as the "long" threshold shows it again.

04:14

Normally an nqp::time read is less than a microsecond. But sometimes it appears to be thousands of times slower. At first I assumed preemption problems, so I quiesced my system. And then checked against camelia.

04:15

The effect is still there -- the faster loop body appears to have much spikier latency.

WTH is going on here?

(FWIW, you can see the same effect with 'now' instead of 'nqp::time' as long as you fix the variable types and account for the factor of 1_000_000_000 conversion.)

04:16

moon-child

I wonder if it has to do with vdso latency

04:17

are you running linux?

japhb

Yes. 'vdso'?

04:18

Oh this? en.wikipedia.org/wiki/VDSO

04:19

moon-child

hmm, on further thought, that doesn't make much sense. The kernel maps a page into every process containing things like the current time, so to get the time, you can just read it from that page without having ot do a ctx switch. So maybe, if you're faster, you're more likely to read a stale value from there

but that doesn't seem likely, the more I think about it

04:22 mattil joined

japhb

That's kindof a cool hack -- does it map the *same* page into every process? Meaning that there is just 1 of these special pages *physically*, it's just memory mapped separately into every process?

04:23

moon-child

I think so. Don't know too much about it

japhb

Huh. I wonder what happens when you enable large pages

04:24

I suppose since all the copies are probably virtual, it doesn't really matter much.

05:10 mattil left 06:02 reportable6 left 06:41 MasterDuke joined

MasterDuke

japhb: do you get the same results if you disable spesh? or might it be gc pauses?

06:44

nine

GC pauses may actually be the explanation.

06:45

MasterDuke

nqp: my int $i := 0; my int $t0 := my int $prev := nqp::time; my int $long := 0; my $t; while $i++ < 10_000_000 { $t := nqp::time; $long++ if nqp::isgt_i(nqp::sub_i($t, $prev), 5_000_000); $prev := $t; }; say(nqp::div_n((nqp::time() - $t0), 1_000_000_000)); say($long);

06:46

camelia

0.510087937
0

MasterDuke

nqp: my int $i := 0; my int $t0 := my int $prev := nqp::time; my int $long := 0; my $t; while $i++ < 10_000_000 { $t := nqp::time; $long++ if nqp::isgt_i(nqp::sub_i($t, $prev), 1_000_000); $prev := $t; }; say(nqp::div_n((nqp::time() - $t0), 1_000_000_000)); say($long);

camelia

0.536608651
2

releasable6

Next release in ≈2 days and ≈11 hours. 1 blocker. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft