Lorenzo

Hi Jirka, well done! A factor 3x in speed with respect to a very fast generator such as xoshiro256 is very probably more than acceptable in the vast majority of applications. Some of the original considerations made for RanLux++, although they are not at all damning, still apply: the implementation of the generator is fairly complex and the generator is not blazing fast. In any case, it's obviously good to have a fast implementation of such a famous generator. BTW, Vigna added on his page a couple...

I wanted to report that a new C++ implementation of Ranlux++ has been very recently presented by Jonas Hahnfeld, Lorenzo Moneta, see https://arxiv.org/abs/2106.02504 From what I can see from the paper their optimized C++ implementation is portable and can be about as fast as the x86 assembly one. They report a performance of about 9 ns/number both on an AMD Ryzen 9 3900 and on the Apple M1 using the Clang compiler (if I understand correctly "number" is a 64bit and they use only one core on each CPUs....

I can tell you my opinion on Ranlux++, although please note that I'm not at all an expert in the field. From a practical point of view, I think Ranlux++ has quite a few good things going for it. You already listed them, but to re-iterate: 1) It is a LCG generator using a very large 576-bit constant and a lot of decimation (skipping) to get rid of short-range correlations. The theory behind it is well-studied, both in general terms and for the specific RANLUX choice of constants. 2) It has been used...

Only Chris can answer for sure. While waiting for his feedback I can give some general considerations. I've never used Visual Studio, but it may just be that you compiled with 'debug' compiler flags on, which triggered a lot of warnings. In your file there are 70 lines labelled as 'messages' (which I think we can ignore), and 397 'warnings'. Of the warnings, about half (196) are of this type: warning C4244: 'return': conversion from 'PractRand::Uint64' to 'PractRand::Uint32', possible loss of data...

I would like to bring to attention the following recent paper: Lama Sleem and Raphaël Couturier, TestU01 and Practrand: Tools for a randomness evaluation for famous multimedia ciphers, Multimedia Tools and Applications (2020)79:24075–24088 https://link.springer.com/article/10.1007/s11042-020-09108-w (unfortunately behind paywall) The authors use TestU01 and Practrand to test the implementations of several ciphers (block and stream). The ciphers analysed are the following (the library they come from,...

BTW, I confirm that byte6 does fail PractRand at 256GB: rng=RNG_stdin, seed=unknown length= 256 gigabytes (2^38 bytes), time= 3601 seconds Test Name Raw Processed Evaluation BCFN(2+2,13-0,T) R= +37.5 p = 1.4e-19 FAIL ! [Low1/8]BCFN(2+0,13-0,T) R= +39.6 p = 1.0e-20 FAIL !! ...and 370 test result(s) without anomalies

Hello, I had a look, but please note that I'm no expect in such things and I may be doing something trivially wrong. First, I used prng_streamer with options -m from 0 to 2, and the otput stream I got is clearly non-random (it's sufficient to open, say, the first megabyte as a raw greyscale image to see lots of patterns in the data). Consequently, PractRand fails instantly for these streams. I haven't checked your source code, but it seems that you're extracting the random bits incorrectly. I wrote...

Thanks! I'll have a look at it during the weekend.