Re: What exactly is our CRC algorithm?

Поиск
Список
Период
Сортировка
От Abhijit Menon-Sen
Тема Re: What exactly is our CRC algorithm?
Дата
Msg-id 20150211142013.GA23587@toroid.org
обсуждение исходный текст
Ответ на Re: What exactly is our CRC algorithm?  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Ответы Re: What exactly is our CRC algorithm?  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Список pgsql-hackers
At 2015-02-11 13:20:29 +0200, hlinnakangas@vmware.com wrote:
>
> I don't follow. I didn't change configure at all, compared to your
> patch.

OK, I extrapolated a little too much. Your patch didn't actually include
crc_instructions.h; from the name of the #define, I imagined you planned
to move the check to configure. But now I guess from your response that
PG_HAVE_CRC32C_INSTRUCTIONS would be #defined by the header (as you did
say it would be). So let's forget that part.

> As a case in point, with your patch pg_xlogdump would not have used
> the CRC instruction, because it never called pg_choose_crc_impl().
> "Choose on first use" is much more convenient than requiring every
> program to call a function.

I can see your point. I'm not fond of the code, but I guess it's not a
huge deal in the larger scheme of things.

> I think what you're suggesting is that we'd instead have two mutually
> exclusive #defines, something like "USE_CRC_SSE_ALWAYS" and
> "USE_CRC_SSE_WITH_RUNTIME_CHECK".

I was thinking of only one knob: USE_CRC_SSE would (try to) build the
code to use the SSE instructions without any test. If it (or another
USE_CRC_XXX flag) isn't set, we'd build all applicable variants and
test at runtime to decide what to use.

Just give me a little while to think through what that would look like,
I'll post a patch.

-- Abhijit



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Albe Laurenz
Дата:
Сообщение: Re: SSL renegotiation and other related woes
Следующее
От: Robert Haas
Дата:
Сообщение: Re: reducing our reliance on MD5