On Tue, Oct 31, 2023 at 03:38:17PM -0500, Nathan Bossart wrote:
> On Tue, Oct 31, 2023 at 04:12:40PM -0400, Tom Lane wrote:
>> This seems like a reasonable proposal.
>
> Great. I think that leaves us with nothing left to do for this thread, so
> I'll withdraw it from the commitfest and move the d
On Tue, Oct 31, 2023 at 04:12:40PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> Okay. With that in mind, I think the path forward for new instructions is
>> as follows:
>
>> * If the special CRC instructions can be used with the default compiler
>> flags, we can only use newer instructio
Nathan Bossart writes:
> Okay. With that in mind, I think the path forward for new instructions is
> as follows:
> * If the special CRC instructions can be used with the default compiler
> flags, we can only use newer instructions if they can also be used with
> the default compiler flags.
On Tue, Oct 31, 2023 at 03:42:33PM -0400, Tom Lane wrote:
> The one machine using slicing-by-8 where there might be a better
> alternative is arowana, which is CentOS 7 with a pretty ancient gcc
> version. So I reject the idea that slicing-by-8 is an appropriate
> baseline for comparisons. There
On Tue, Oct 31, 2023 at 03:16:16PM -0400, Tom Lane wrote:
> Really this just reinforces my concern that doing a runtime check
> all the time is on the wrong side of history. I grant that we've
> got to do that for anything where the availability of the instruction
> is really in serious question,
I wrote:
> I did a more thorough scrape of the buildfarm results. Of 161 animals
> currently reporting configure output on HEAD, we have
Oh ... take "current" with a grain of salt there, because I just noticed
that I typo'd my search condition so that it collected results from all
systems that re
Nathan Bossart writes:
> On Mon, Oct 30, 2023 at 10:36:01PM -0500, Nathan Bossart wrote:
>> I tested pg_waldump -z with 50M 65-byte records for the following
>> implementations on an ARM system:
>>
>> * slicing-by-8: ~3.08s
>> * proposed patches applied (runtime ch
On Mon, Oct 30, 2023 at 10:36:01PM -0500, Nathan Bossart wrote:
> I tested pg_waldump -z with 50M 65-byte records for the following
> implementations on an ARM system:
>
> * slicing-by-8: ~3.08s
> * proposed patches applied (runtime check): ~2.44s
> * only CR
On Mon, Oct 30, 2023 at 01:48:29PM -0700, Jeff Davis wrote:
> I assume you are concerned about the call going through a function
> pointer? If so, is it possible that setting a flag and then branching
> would be better?
>
> Also, if it's a concern, should we also consider making an inlineable
> ve
On Mon, Oct 30, 2023 at 12:39:23PM -0400, Tom Lane wrote:
> On the one hand, I agree that we need to keep the complexity from
> getting out of hand. On the other hand, I wonder if this approach
> isn't optimizing for the wrong case. How many machines that PG 17
> will ever be run on in production
On Mon, 2023-10-30 at 12:39 -0400, Tom Lane wrote:
> It seems like a shame
> to be burdening these instructions with a subroutine call for the
> benefit of long-obsolete hardware versions.
It's already doing a call to pg_comp_crc32c_sse42() regardless, right?
I assume you are concerned about the
Nathan Bossart writes:
> The aforementioned other thread [0] aims to further optimize this code by
> using another instruction that requires additional configure and/or runtime
> checks. $SUBJECT has been in the back of my mind for a while, but given
> proposals to add further complexity to this
This is an offshoot of the "CRC32C Parallel Computation Optimization on
ARM" thread [0]. I intend for this to be a prerequisite patch set.
Presently, for the SSE 4.2 and ARMv8 CRC instructions used in the CRC32C
code for WAL records, etc., we first check if the intrinsics are available
with the d
13 matches
Mail list logo
