9front - general discussion about 9front
 help / color / mirror / Atom feed
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

  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).