Re: pgbench - add pseudo-random permutation function

Fabien COELHO <coelho@cri.ensmp.fr>

From: Fabien COELHO <coelho@cri.ensmp.fr>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: 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-03-13T08:49:53Z
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.

Attachments

Hello Alvaro,

>> That doesn't sound like a bad option to me, if it makes this much
>> simpler.  The main modern system without it seems to be MSVC.  The
>> Linux, BSD, Apple, illumos, AIX systems using Clang/GCC with
>> Intel/AMD/ARM/PowerPC CPUs have it, and the Windows systems using open
>> source compilers have it.
>
> Hmm.  Can we go a bit further, and say that if you don't have 128-bit
> ints, then you can use pr_perm but only to a maximum of 32-bit ints?
> Then you can do the calculations in 64-bit ints.  That's much less bad
> than desupporting the feature altogether.

This looks like a good compromise, which can even be a little better 
because we still have 64 bits ints.

As there is already a performance shortcut in the code relying on the fact 
that x is 24 bits and that no overflow occurs if y & m are up to 48 bits 
(we are using unsigned int), the simplification is just to abort if int128 
is not available, because we would have called the function only if it was 
really needed.

Attached a simplified patch which does that, removing 1/3 of the code. 
What do you think?

Note that this creates one issue though: tests now fail if 128 bits ints 
are not available. I'm not sure how to detect & skip that from the tap 
tests. I'm not keen on removing the tests either. Will give it some 
thoughts if you want to proceed in that direction.

-- 
Fabien.