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=-4.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A 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 9517228C75 for ; Wed, 3 Apr 2024 21:55:37 +0200 (CEST) Received: from mimir.eigenstate.org ([206.124.132.107]) by 9front; Wed Apr 3 15:54:45 -0400 2024 Received: from mimir.eigenstate.org (localhost [127.0.0.1]) by mimir.eigenstate.org (OpenSMTPD) with ESMTP id 5fecf34c; Wed, 3 Apr 2024 12:54:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=eigenstate.org; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=jEryMVwH0DDRXwN0b68zf2W0p4E=; b=WffPhs4qmXxL0jnSTSzgnyZZPDge CS8xXLJ/nCBb3wvuNl+c2KPB0RMsidIeHmOxsNEDfrRxZ4AE+20w3rMP9iUw9tTw QapYs9FuTCoPq5Npmmjr+D7T49R9Ij/rIreYTVa0WEbcfZ66szSNNstxxq7PXbhs XJ3HsoXHudmd9vo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=eigenstate.org; h=date:from :to:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=mail; b=NNhnzR uaQubsOkLddYvzToZhX/hiW1Ocg3JuCp2Bw+ybV4+tH3CRN+GOejcvXG6O+GC1NI A0z3huB36mhMUftmOnTUH3mfNMPlEBU/jykfiqG0XPxy7/J889xlrsJiU+vDktSv I77LxnVSxwgRx1bKsjVaMVzQxQYJyesFQnr5U= Received: from nixos (mail.rmefpc.com [167.206.66.211]) by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id d1b1282e (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO); Wed, 3 Apr 2024 12:54:44 -0700 (PDT) Date: Wed, 3 Apr 2024 15:54:43 -0400 From: Ori Bernstein To: 9front@9front.org Cc: qwx@sciops.net Message-Id: <20240403155443.a7ab061ca8b53fd500abc550@eigenstate.org> In-Reply-To: References: <24YLTYTO4Q79Z.243QVQUY1V3P5@e55-lap.my.domain> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: virtual TOR scripting STM locator Subject: Re: [9front] [PATCH] libc: replace lrand's algorithm Reply-To: 9front@9front.org Precedence: bulk On Wed, 03 Apr 2024 11:07:22 +0200 qwx@sciops.net wrote: > I think at this point it would be better to look at a patch, with the > changes mentioned after the first post, and a sweep through the other > implementations. There are some odd occurrences as you found; libc's > frand() is also somewhat suspect but will likely need to change if > lrand() does. We need a 16bit, 32bit, floating point, and possibly > 64bit variant; this will clean up some code and remove some > redundancies which is always nice. Perhaps take the extreme route and > do *all* of the changes you'd like to see, so we could more easily > discuss each case. We then need to check if there's a performance > impact on non-amd64 arches. For xoroshiro128+ vs. pcg I'd be > interested to know if there's any significant difference between the > two in statistical properties and performance; if we make a change, > it'd be nice to pick the best alternative and make it once and for > all. Code size and simplicity also counts. Is there any other > variant that should be assessed? Performance for this RNG is, tbh, pretty uninteresting, at least for any of the options under consideration. All of them are good. Better statistical properties, smaller and cleaner code, are both good reasons to change this, and I'd be happy to take a correct patch to improve that. It's not an urgent need -- anything that strongly depends on the statistical properties of a random stream should possibly consider a CSPRNG -- but it's nice to have. Another question here: Would it be sensible to just ditch all of this tomfoolery with "good enough" randomness, and just move to a seedable CSPRNG?