Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 25 Mar 2019 01:14:30 GMT
From:   George Spelvin <lkml@sdf.org>
Message-Id: <201903250114.x2P1EUQG004384@sdf.org>
To:     Jason@zx2c4.com, lkml@sdf.org
Subject: Re: [RFC PATCH] random: add get_random_max() function
Cc:     linux-kernel@vger.kernel.org, tytso@mit.edu
In-Reply-To: <CAHmME9p3TR6ESekKRQxFsfQe3rZp7T4-4WLOn-SL98zUnAo2DQ@mail.gmail.com>
References: <201903241244.x2OCiL8P011277@sdf.org>,
    <CAHmME9p3TR6ESekKRQxFsfQe3rZp7T4-4WLOn-SL98zUnAo2DQ@mail.gmail.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

P.S. The cited paper calls your algorithm the "OpenBSD algorithm"
and has a bunch of benchmarks comparing it to others in Fisher-Yates
shuffles of sizes 1e3..1e9.

Including all overhead (base PRNG, shuffle), it's 3x slower for
32-bit operations and 8x slower for 64-bit up to arrays of size
1e6, after which cache misses slow all algorithms, reducing the
ratio.

If you want a faster division-based agorithm, the "Java algorithm"
does 1+retries divides:

unsigned long java(unsigned long s)
{
	unsigned long x, r;

	do {
		x = random_integer();
		r = x % s;
	} while (x - r > -s);
	return r;
}