Horton

Re: pgbench - add pseudo-random permutation function

Fabien COELHO <coelho@cri.ensmp.fr>

View thread
From: Fabien COELHO <coelho@cri.ensmp.fr>
To: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, Thomas Munro <thomas.munro@gmail.com>, David Steele <david@pgmasters.net>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, Hironobu SUZUKI <hironobu@interdb.jp>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-04-02T05:38:57Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. pgbench: Function to generate random permutations.

  2. Add basic support for using the POPCNT and SSE4.2s LZCNT opcodes

  3. Further improve code for probing the availability of ARM CRC instructions.

>>   r = (uint64) (pg_erand48(random_state.xseed) * size);
>>
>> I do not understand why the random values are multiplied by anything in
>> the first place…
>
> These are just random integers in the range [0,mask] and [0,size-1],
> formed in exactly the same way as getrand().

Indeed, erand returns a double, this was the part I was missing. I did not 
realize that you had switched to doubles in your approach.

I think that permute should only use integer operations. I'd suggest to 
use one of the integer variants instead of going through a double 
computation and casting back to int. The internal state is based on 
integers, I do not see the added value of going through floats, possibly 
enduring floating point issues (undeflow, rounding, normalization, 
whatever) on the way, whereas from start to finish we just need ints.

See attached v27 proposal.

I still think that *rand48 is a poor (relatively small state) and 
inefficient (the implementation includes packing and unpacking 16 bits 
ints to build a 64 bits int) choice.

-- 
Fabien.