There are many bold claims on this website. But you don't screw around with RNGs: they need to be right. Until this author's claims have been verified, I would not use this algorithm.
There are many bold claims on this website. But you don't screw around with RNGs: they need to be right. Until this author's claims have been verified, I would not use this algorithm.
> In effect, Romu generators are infinitely fast when inlined.
What the hell does "infinitely fast" even MEAN in this context? They can be parallelized easily? The computational cost amortizes well? That it literally requires zero operations to generate output?
This may be something interesting if it packs a lot of the features claimed. But there are a LOT of ill-defined claims on the website, and a fair bit of time spent pointing to the state of current research in OTHER algorithms/proposals as if open questions are an automatic disqualification ("[H]ow can you know whether such a generator has enough capacity for your large job? You don’t know.").
I don't think the guy is a crank, per se-- just excited. But this is the sort of stuff that makes me think that he hasn't done the requisite level of research required before claiming a breakthrough.
It's nonsense, but their argument seems to be that instruction level parallelism allows the RNG's user to keep executing simultaneously while the RNG pre-computes its next output. So the application doesn't have to delay execution to wait for the RNG to spit something out.
It doesn't mean that it is infinitely fast. It does however mean that in this particular case it adds no latency for adding random number generation; an infinitely fast algorithm would also add no latency for random number generation. Doesn't mean one implies the other.