Date: Tue, 31 May 2016 07:50:04 +0300 From: Andrey Chernov <ache@freebsd.org> To: Bruce Evans <brde@optusnet.com.au> Cc: Conrad Meyer <cem@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r300965 - head/lib/libc/stdlib Message-ID: <b1a51307-ffd8-66bb-367b-b7bb1a0ab36d@freebsd.org> In-Reply-To: <20160531130326.G1052@besplex.bde.org> References: <201605291639.u4TGdSwq032144@repo.freebsd.org> <CAG6CVpXuoetY2GvV7Zonueb0TvQfRcMAHQYLXhd6yab5Mi%2BR0Q@mail.gmail.com> <20160530122100.X924@besplex.bde.org> <5985bdc1-b821-f352-0bc5-c45c600c5318@freebsd.org> <20160531130326.G1052@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 31.05.2016 6:42, Bruce Evans wrote: > > Er, I already said which types are better -- [u]int_fast32_t here. [u]int_fast32_t have _at_least_ 32 bits. int32_t in the initial PRNG can be changed since does not overflow and involve several calculations, but uint_fast32_t is needed just for two operations: *f += *r; i = (*f >> 1) & 0x7fffffff; We need to assign values from uint32_t to uint_fast32_t (since array size can't be changed), do this single operation fast and store them back into array of uint32_t. I doubt that much gain can comes from it and even pessimization in some cases. Better let compiler do its job here.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b1a51307-ffd8-66bb-367b-b7bb1a0ab36d>