>>>> 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.
