Re: Optimize Arm64 crc32c implementation in Postgresql - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Optimize Arm64 crc32c implementation in Postgresql
Date
Msg-id 31251.1525320257@sss.pgh.pa.us
Whole thread Raw
In response to Re: Optimize Arm64 crc32c implementation in Postgresql  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Optimize Arm64 crc32c implementation in Postgresql
List pgsql-hackers
I wrote:
> Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
>> Isn't there a hidden assumption about endianness there?

> Yeah, I was wondering about that too, but does anyone actually run
> ARMs big-endian?

After a bit more thought ... we could remove the magic constant,
along with any assumptions about endianness, by doing it like this:

    result = (pg_comp_crc32c_armv8(0, &data, sizeof(data)) ==
              pg_comp_crc32c_sb8(0, &data, sizeof(data)));

Of course we'd eat a few more cycles during the test, but it's hard
to see that mattering.

It strikes me also that, at least for debugging purposes, it's seriously
awful that you can't tell from outside what result this function got.
Certainly the outcome that "pg_comp_crc32c_armv8 executed but returned
the wrong answer" is not something that ought to go unremarked.
We could elog the results, but I'm not very sure what log level is
appropriate --- also, I doubt we want another log entry from every
launched process, so how to prevent that?

            regards, tom lane


pgsql-hackers by date:

Previous
From: Charles Cui
Date:
Subject: Re: GSoC 2018: thrift encoding format
Next
From: Thomas Munro
Date:
Subject: Re: Optimize Arm64 crc32c implementation in Postgresql