Re: CRC32C Parallel Computation Optimization on ARM - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: CRC32C Parallel Computation Optimization on ARM
Date
Msg-id 4ceb7c74-b188-471d-b3bf-a11ec411fe46@iki.fi
Whole thread Raw
In response to Re: CRC32C Parallel Computation Optimization on ARM  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: CRC32C Parallel Computation Optimization on ARM
List pgsql-hackers
On 25/10/2023 00:18, Nathan Bossart wrote:
> On Tue, Oct 24, 2023 at 04:09:54PM -0500, Nathan Bossart wrote:
>> I'm able to reproduce the speedup with the provided benchmark on an Apple
>> M1 Pro (which appears to have the required instructions).  There was almost
>> no change for the 512-byte case, but there was a ~60% speedup for the
>> 4096-byte case.
>>
>> However, I couldn't produce any noticeable speedup with Heikki's pg_waldump
>> benchmark [0].  I haven't had a chance to dig further, unfortunately.
>> Assuming I'm not doing something wrong, I don't think such a result should
>> necessarily disqualify this optimization, though.
> 
> Actually, since the pg_waldump benchmark likely only involves very small
> WAL records, it would make sense that there isn't much difference.
> *facepalm*

No need to guess, pg_waldump -z will tell you what the record size is. 
And you can vary it by changing the checkpoint interval and/or pgbench 
scale factor: if you checkpoint frequently or if the database is larger, 
you get more full-page images which makes the records larger on average, 
and vice versa.

-- 
Heikki Linnakangas
Neon (https://neon.tech)




pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Add new for_each macros for iterating over a List that do not require ListCell pointer
Next
From: Michael Paquier
Date:
Subject: Re: CRC32C Parallel Computation Optimization on ARM