Multiplication is... decent? I mean, it's fast, on a lot of CPUs, and tends to mix things better than add/xor. The class of CPUs it's fast on smaller than the class of CPUs that the basics (add, xor, shift) are fast on, so a PRNG that uses multiplication is inherently targeting a smaller niche. Not much smaller these days, since fast multiplication is pretty common. And low multiplication alone is never enough, you inherently need shifts, and probably add or xor too, or maybe just decimated output...

What? If a 4 word PRNG shows the (Extended+MaxFold) failures as: 16bit word => 2^36 16 bits is 2 bytes. 4 times 2 bytes is 8 bytes of state. Is that not saying that failures occur after 2^36 bytes with a state size of 8 bytes?

Yeah, performance of high-end CPUs on short loops has been weird ever since... the early to mid 1990s I think? PPros. And these days it's not just high-end CPUs anymore. sfc is sort of optimized for x86. Not much really, but the value of the left-shift was chosen, at least in part, to work well with the LEA instruction on x86.

Probably not. I mean, if there are other PRNGs that seem comparable in most ways but are better quality, I'd tend to recommend the better quality ones for whatever niche they were competing in. And the fact that it fails at 2^36 bytes for an 8 byte state and 2^42 bytes for a 16 byte state would worry me. That implies that even if the 64-bit version passed very large tests, it's might be because the tests couldn't keep track of correlations at the right distances or whatever - and there would be a...

PractRand targets normal integer sizes - 8, 16, 32, 64, and unknown. For a 24 bit source I would recommend either 8 (stdin8 / As8) or unknown (stdin / AsUnknown). Or better running tests twice, once on the lowest 16 bits and then again the highest 16 bits. Eventually the command line will get powerful enough to allow you to specify that, but it's not there yet, so currently you'll have use your own code to drop 8 bits out of every 24.

Going from the output to the internal state looks quite feasible. Running the algorithm backwards should be even easier. The seed is simply the internal state 12 steps before output starts. There's probably some intelligent way to compute the state algebraically from the output, but if I had to do it, I'd just brute force it - guess a random value of 'c', use the output to calculate later values of 'c' from the guessed initial value, use the calculated values of c to calculate what the 3rd & 4th...

I tried some tests on the code you posted. TestU01: 1/1/1 That is, it fails 1 subtest (out of 15) of SmallCrush, 1 (out of 144) of Crush, and 1 (out of 160) of BigCrush. So about 10-15 seconds for first failure. In every case, it was a birthday spacings test that found bias. Also, some people like to run TestU01 on bit-backwards versions of PRNGs (because TestU01 is less stringent on the higher bits, completely skipping the highest IIRC) I also tried both bit-backwards and byte-backwards ; bit-backwards...

No, wait, I'm confused. I hadn't touched PractRand in a while and was accidentally testing with version 0.92. Testing with version 0.95, it does adequately on those files at default settings. rng=RNG_file(d:\inc\out), seed=0 length= 1 gigabyte (2^30 bytes), time= 24.0 seconds Test Name Raw Processed Evaluation mod3n(5):(0,9-0) R= +74.0 p = 1.9e-40 FAIL !!! ...and 222 test result(s) without anomalies rng=RNG_file(d:\inc\out1), seed=0 length= 32 megabytes (2^25 bytes), time= 4.6 seconds Test Name Raw...