Messages in this thread | | | From | (bill davidsen) | Subject | Re: [RFC] frandom - fast random generator module | Date | 21 Oct 2003 19:46:24 GMT |
| |
In article <20031016144205.I7000@schatzie.adilger.int>, Andreas Dilger <adilger@clusterfs.com> wrote: | On Oct 16, 2003 21:28 +0200, Eli Billauer wrote: | > Allow me to supply a couple facts about frandom: | > | > * It's not a "crappy" RNG. Its RC4 origins and the fact, that it has | > passed tests indicate the opposite. A fast RNG doesn't necessarily mean | > a bad one. I doubt if any test will tell the difference between frandom | > and any other good RNG. You're most welcome to try. | | The "crappy RNG" being referred to is just some code we implemented to | give us somewhat unique numbers instead of sucking CPU. | | > * Frandom is written completely in C. On an i686, gcc compiles the | > critical part to 26 assembly instructions per byte, and I doubt if any | > hand assembly would help significantly. The algorithms is clean and | > simple, and the compiler performs well with it. | | This is still more expensive than a hw RNG (which will be about 1 ins | per 4 bytes), so it would be nice to make this arch-specific if possible | (runtime and compile time).
Clearly that's true inside the kernel. Although the speed will be somewhat less because you may not always need four bytes, no?
The benefit of a random number source user programs can use, which is going to avoid giving the same number to multiple processes or threads is significant for simulations and sampling. It doesn't matter if this is done with frandom or speeding urandom to similar speed, other than that some people will protest a change in urandom, even a change for the better.
-- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |