Suggestion: 'force_le' feature flag?

[dhardy]

For the sake of portable results, we force the use of LE on byte-int and int-byte conversions. This isn't always desired, but to avoid multiple code-paths we do it anyway.

However, by using a feature flag, we don't need multiple compiled code paths (and the multiple code versions exist anyway, where this is a significant optimisation on LE). We could add a force_le feature flag to cause current behaviour on BE platforms, using NE by default.

This would be a breaking change (target 0.9; #1165).

[vks]

What's the motivation for this? Better performance on big-endian platforms?

[newpavlov]

I don't think it's a good idea. If force_le is enabled by default, it will be virtually impossible to disable it in any sizable project, and if not, it certainly will be a portability headache. Also enabling it for a whole rand looks like overly coarse-grained to me.

[dhardy]

Motivation? I'm looking at #1170, specifically fill_via_chunks, and notice that using a simple copy_nonoverlapping on little-endian is around 50% faster than the copy-by-word-sized-chunks variant (after a pretty significant optimisation to that), for the gen_bytes_chacha* benchmarks. But BE platforms aren't exactly popular, so maybe we just don't care.

[vks]

Ok, so the goal is to offer big-endian platforms better performance at the cost of losing reproducibility with respect to little-endian platforms. I think this is fair, but I would be hesitant to add this without knowing whether anyone will use it, because it increases complexity by adding another feature, and it's a potential footgun for people upgrading rand_core with no-default-features = true.

[dhardy]

It's also less of a performance boost now (see #1180). Agreed, we don't appear to need this.