Or, (3) remove this test? I am not quite sure what there is to gain
with this extra test considering all the other tests with permute()
already present in this script.
Yes, I think removing the test is the best option. It was originally
added because there was a separate code path for larger permutation
sizes that needed testing, but that's no longer the case so the test
really isn't adding anything.
Hmmm…
It is the one test which worked in actually detecting an issue, so I would
not say that it is not adding anything, on the contrary, it did prove its
value! The permute function is expected to be deterministic on different
platforms and architectures, and it is not.
In fact what it demonstrates is that the results from permute(), like
all the other pgbench random functions, will vary by platform for
sufficiently large size parameters.
Indeed, it is the case if the underlying math use doubles & large numbers.
For integer-only computations it should be safe though, and permute should
be in this category.
I'd agree with a two phases approach: drop the test in the short term and
deal with the PRNG later. I'm sooooo unhappy with this 48 bit PRNG that I
may be motivated enough to attempt to replace it, or at least add a better
(faster?? larger state?? same/better quality?) alternative.
I don't necessarily have a problem with that provided the replacement
is well-chosen and has a proven track record (i.e., let's not invent
our own PRNG).
Yes, obviously, I'm not daft enough to reinvent a PRNG. The question is to
chose one, motivate the choice, and build the relevant API for what pg
needs, possibly with some benchmarking.
For now though, I'll go remove the test.
This also removes the reminder…
--
Fabien.
