Re: What exactly is our CRC algorithm? - Mailing list pgsql-hackers

From Abhijit Menon-Sen
Subject Re: What exactly is our CRC algorithm?
Date
Msg-id 20150211142013.GA23587@toroid.org
Whole thread Raw
In response to Re: What exactly is our CRC algorithm?  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: What exactly is our CRC algorithm?  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List 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 by date:

Previous
From: Albe Laurenz
Date:
Subject: Re: SSL renegotiation and other related woes
Next
From: Robert Haas
Date:
Subject: Re: reducing our reliance on MD5