svn commit: r300956 - head/lib/libc/stdlib

[Andrey Chernov]

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