From: qwx@sciops.net
To: 9front@9front.org
Subject: Re: [9front] [PATCH] libc: replace lrand's algorithm
Date: Fri, 29 Mar 2024 13:39:03 +0100 [thread overview]
Message-ID: <505C905934B3CDB74EC21F69ADF03150@wopr.sciops.net> (raw)
In-Reply-To: <3LHKTP1HB4DYE.2X5KUF9RIVGEC@e55-lap.my.domain>
On Fri Mar 29 09:19:39 +0100 2024, eolien55@disroot.org wrote:
> Hello,
>
> The current lrand's algorithm is quite suboptimal.
> After benchmarking, we find:
> Current algorithm:
> repeated srand with different values: 820.740000
> repeated lrand: 643.880000
>
> Proposed algorithm (PCG32-XSH-RR[1]):
> repeated srand with different valudes: 1.920000
> repeated lrand: 600.590000
Hello,
I'm a bit puzzled by both the results and the implementation.
If I look at the site you point to, the download page [1] has
this snippet:
typedef struct { uint64_t state; uint64_t inc; } pcg32_random_t;
uint32_t pcg32_random_r(pcg32_random_t* rng)
{
uint64_t oldstate = rng->state;
// Advance internal state
rng->state = oldstate * 6364136223846793005ULL + (rng->inc|1);
// Calculate output function (XSH RR), uses old state for max ILP
uint32_t xorshifted = ((oldstate >> 18u) ^ oldstate) >> 27u;
uint32_t rot = oldstate >> 59u;
return (xorshifted >> rot) | (xorshifted << ((-rot) & 31));
}
Here `state' is 64-bit, whereas in your code, it's a ulong,
ie. 32-bit, which seems to break everything. Furthermore, your
code seems to have flipped part of the last statement and return
the equivalent of:
return (xorshifted >> ((-rot) & 31)) | (xorshifted << rot);
Is that intentional?
Moreover, for the benchmark itself, while seeding is significantly
faster, actually calling lrand barely is; the new code is only
1.07x faster than the old. The scale is also minuscule, around
42 seconds for circa 4.3 billion calls (you're looping on a signed
long from 0 to -1). Am I misreading?
lrand is used by rand(2) itself and is used throughout the system
and elsewhere, and who knows what impact changing it might have.
Applications which need guarantees about distribution or
performance are not supposed to use rand(2) to begin with.
Therefore, these numbers alone do not justify, in my opinion,
replacing the current implementation.
Cheers,
qwx
[1] https://www.pcg-random.org/download.html
next prev parent reply other threads:[~2024-03-29 12:40 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-29 8:19 Eolien55
2024-03-29 12:39 ` qwx [this message]
2024-03-29 16:02 ` Eolien55
2024-04-01 15:47 ` qwx
2024-04-02 14:37 ` Eolien55
2024-04-02 14:52 ` Stanley Lieber
2024-04-02 20:18 ` Eolien55
2024-04-03 9:07 ` qwx
2024-04-03 19:50 ` Ori Bernstein
2024-04-03 19:54 ` Ori Bernstein
2024-04-04 21:00 ` Eolien55
2024-04-20 12:46 ` cinap_lenrek
2024-04-20 12:58 ` cinap_lenrek
2024-04-20 13:01 ` cinap_lenrek
-- strict thread matches above, loose matches on Subject: below --
2024-03-29 8:15 Eolien55
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=505C905934B3CDB74EC21F69ADF03150@wopr.sciops.net \
--to=qwx@sciops.net \
--cc=9front@9front.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).