Re: Optimize Arm64 crc32c implementation in Postgresql

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Optimize Arm64 crc32c implementation in Postgresql
Дата
Msg-id 31251.1525320257@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Optimize Arm64 crc32c implementation in Postgresql  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Optimize Arm64 crc32c implementation in Postgresql  (Thomas Munro <thomas.munro@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Charles Cui
Дата:
Сообщение: Re: GSoC 2018: thrift encoding format
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: Optimize Arm64 crc32c implementation in Postgresql