Think about Isaac{,64}Rng

[nagisa]

Currently we provide two versions of Isaac RNG, namely a 32-bit and 64-bit version. One fitting the machine word size was previously (before #14) chosen automagically by StdRng. This means currently using a matching IsaacRng version needs to use #[cfg] conditional comments in the client code.

We need to decide whether we want to remove Isaac*Rng from the rand crate or rename current IsaacRng to Isaac32Rng and add IsaacRng which selects the best implementation.

[huonw]

These names are chosen to reflect the names of the algorithms, which are ISAAC and ISAAC64 respectively. (That's not to say we can't deviate, but it is a bit of weight toward the status quo.)

[pitdicker]

An update an the oldest open issue in rand:

#14 was merged in a next branch, which is not the direction rand is going (b.t.w. @dhardy, is there any use in keeping that branch?).

Interestingly ISAAC-64 is faster than ISAAC on 32-bit, see dhardy#53. The only advantage of ISAAC over the 64-bit version is that it uses half the memory. We still have IsaacWordRng to select the version native to the architecture though.

We need to decide whether we want to remove Isaac*Rng from the rand crate or rename current IsaacRng to Isaac32Rng and add IsaacRng which selects the best implementation.

• I don't think renaming is a good idea, but we may want to drop IsaacWordRng.
• In Replace ISAAC with HC-128 dhardy/rand#53 I proposed to replace ISAAC with HC-128 in StdRng.
• About whether we should drop ISAAC from rand: in To provide (or not) specific PRNGs? dhardy/rand#58 we ended up with the idea to only keep the wrapper types StdRng and SmallRng exposed in rand. Then ISAAC can move to an external crate.

[dhardy]

Interestingly ISAAC-64 is faster than ISAAC on 32-bit, see dhardy#53

You're probably benchmarking only modern Intel CPUs? ARMv7 for one might be quite different.

No, we probably don't want that branch; the point of thread_rng is to be a good compromise between security and speed. (So probably we also want something like StrongRng in rand if we don't expose the algorithms by name.)

Lets close this; the current names are good enough and we may well remove them from rand.