From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <9front-bounces@9front.inri.net>
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED,
	HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI autolearn=ham
	autolearn_force=no version=3.4.4
Received: from 9front.inri.net (9front.inri.net [168.235.81.73])
	by inbox.vuxu.org (Postfix) with ESMTP id 3CF672140F
	for <ml@inbox.vuxu.org>; Mon,  1 Apr 2024 17:48:40 +0200 (CEST)
Received: from wopr.sciops.net ([216.126.196.60]) by 9front; Mon Apr  1 11:47:15 -0400 2024
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sciops.net; s=20210706;
	t=1711986430;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:  in-reply-to:in-reply-to;
	bh=1ysIvAjhe83rcQQy0DkWizwjFxrWwwkpd0jWAbHTojc=;
	b=v6d6BlsNq8v8ywC2Kbehu3Rc7kDzRIRZASgGtAVgX98neb6NIqSYGSQwGBW2PC2m1uZBg7
	Fp1JBCnJA4OEyFbu6Ph/dHU9NDsHAfPvyd9sRamIMoWCrPqkOwtybF6wX+cuidurMy7Jl1
	vIgw0ONzsliJaWzjD9XoBE6+am4Jgsk=
Received: 
	by wopr.sciops.net (OpenSMTPD) with ESMTPSA id 3c37e99f (TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256:NO)
	for <9front@9front.org>;
	Mon, 1 Apr 2024 08:47:10 -0700 (PDT)
Message-ID: <838AEB3E87F0C2AA5B1CC301A5930F88@wopr.sciops.net>
Date: Mon, 01 Apr 2024 17:47:07 +0200
From: qwx@sciops.net
To: 9front@9front.org
In-Reply-To: <32D57IH2WC1B8.2D6VU4LLQOX0C@e55-lap.my.domain>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: basic decentralized XMPP singleton firewall 
Subject: Re: [9front] [PATCH] libc: replace lrand's algorithm
Reply-To: 9front@9front.org
Precedence: bulk

On Fri Mar 29 17:02:32 +0100 2024, eolien55@disroot.org wrote:
> > lrand is used by rand(2) itself and is used throughout the system
> > and elsewhere, and who knows what impact changing it might have.
> 
> I looked through every usage of lrand-related functions in the codebase,
> and it seems that all programs use it simply as "a uniform pseudo-random
> number generator", without other expectations on the output (things
> that would vary from algorithm to algorithm). However the manpage should
> be changed to reflect the algorithm change.

I agree, it doesn't hurt to at least mention this in the manpage.


> However, through looking at the full source tree, it appears there
> are at least 3 lrand duplicates in the source tree, each with its
> own algorithm: one for the kernel, in /sys/src/9/port/random.c, which
> uses xoroshiro128+, which is quite good; one for normal userspace in
> /sys/src/libc/lrand.c, which uses the aforementioned ALFG, which is
> quite suboptimal; and one for ape in /sys/src/lib/v/rand.c, which
> seemingly points to this[1] article. The algorithm is not in common
> use, so maybe it should be changed to one whose properties are
> better-known?
> 
> Given that kernel's lrand is xoroshiro128+, it would make sense to
> either change kernel's lrand to PCG too, or change the proposed
> algorithm to xoroshiro128+.

I like the idea of simplifying the tree and deleting some code,
but keep in mind that the xoroshiro128+ variant is what is
exposed by /dev/random via truerand(2).  It's of little use to
touch the APE code at all at this point.  Most people are
uninsterested in a change here because of the dichotomy between
rand and truerand, the negligeable performance impact, etc.,
and beyond this, it gets into "this is like, my opinion man"
territory.  I wouldn't mind replacing libc's lrand with a PCG
variant also exposing a 64bit version, which we don't have, if
it indeed also improves the statistical properties of the prng.
But that's like, my opinion man.


> > Applications which need guarantees about distribution or
> > performance are not supposed to use rand(2) to begin with.
> 
> Well in that case, some code in /sys/src/cmd needs to be changed
> to not use rand, like spin and venti.

I agree, though again, I don't know what the impact of such
a change would be.

> Cheers,
> Elie Le Vaillant


Cheers,
qwx