From owner-svn-src-head@freebsd.org Tue May 31 07:53:22 2016 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7063CB55DAF for ; Tue, 31 May 2016 07:53:22 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f66.google.com (mail-lf0-f66.google.com [209.85.215.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 040BD1EFB for ; Tue, 31 May 2016 07:53:21 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f66.google.com with SMTP id h68so9043964lfh.3 for ; Tue, 31 May 2016 00:53:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:cc:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=i3HXDPLH0AGwsEvAknWZwSYB4KkY/QtS4fsH6X0msJM=; b=Y0jHh3T2+Y39HV++9vGzS5vNmPzvZh6XEKRyKAPT5d1PaWZRBD8Df7wNflzYWqrXHD sNQ+PNHlNYWtPsgk+mLrSIOrGiw3ntbgcZVwKLAYjBQEdU6OLLO2oxyKkQaAZjG7sNBZ 9ds7RX6VedVFtBm8LTVGXSEhBH76F9jU/HF5VgJliRShiRkhY/J4dKfnKRNnXQi+KSj4 IfU9osCEocpxDVUNHzMx27cn7H+ceqg+zhUCrZyU0WVzi+dHk10g+3YrEeiEtIFdEwph uQ7m/5EyCWIALJjnJs8yUD7s2n6sd/7N4seHL76OygYZPKz+G4VdFtwbo3dDfOc1/YS0 32sw== X-Gm-Message-State: ALyK8tK90/DZtcCrgKdSksDxyRXj64FrNlvfSIxueLXdnijmOQX9haBdEQoXNxaT0PMJcA== X-Received: by 10.25.150.129 with SMTP id y123mr10522528lfd.168.1464681199758; Tue, 31 May 2016 00:53:19 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id yf9sm5077404lbb.34.2016.05.31.00.53.18 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 May 2016 00:53:19 -0700 (PDT) Subject: Re: svn commit: r300956 - head/lib/libc/stdlib References: <201605291357.u4TDv6No071840@repo.freebsd.org> <20160530110541.I924@besplex.bde.org> <20160531155327.I1534@besplex.bde.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org To: Bruce Evans , pfg@freebsd.org From: Andrey Chernov Message-ID: Date: Tue, 31 May 2016 10:53:17 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160531155327.I1534@besplex.bde.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 07:53:22 -0000 On 31.05.2016 9:48, Bruce Evans wrote: >> Perhaps you can find some ideas, answers and PRNG comparison in the >> original paper: >> http://www.firstpr.com.au/dsp/rand31/p1192-park.pdf > > The ones with Mersenne primes and tweaked Mersenne primes in the reference > (lanl?) given by pfg@ seem OK. It should be again correctly implemented to not overflow 64bit (as any other 64bit generator too). Moreover, it have visible patterns in the low order bits. This one from the same site is better http://nuclear.llnl.gov/CNP/rng/rngman/node7.html but still have some pattern too and 61-bit. Next one does not suffer from the pattern at all http://nuclear.llnl.gov/CNP/rng/rngman/node8.html but is 2^64-2^10+1. You can download SPRNG library implementing all of them here: http://www.sprng.org/RNG/ For me it is overcomplicated. >> clang -O uses single "idivl" calculating both quotient and reminder for >> current code, but for ldiv(3) case call/storage/additional calcs >> overhead will be added. ldiv(3) does not reduce anything, see >> stdlib/ldiv.c > > The extern functions give lots of overhead. Sometimes they get replaced > automatically by builtins, so it is unclear when the extern functions are > actually used. ldiv.c compiles to idivl for the division part but has > lots of extras for the fixups. The fixups do nothing except waste time > on most hardware/cstd combinations. IIRC, C99 requires direct division > to have the same poor rounding rules as idiv(), so idiv() is not really > needed in C99 and the fixups in it are negatively needed. The builtins > know what is needed so they don't do the fixups in the usual case that > the hardware follows the poor rounding rules. We don't have ldiv() builtin in any cae. For fixups, see full explanation in the comment of stdlib/div.c