Re: What exactly is our CRC algorithm?

From: Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)com>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Andres Freund <andres(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: What exactly is our CRC algorithm?
Date: 2015-02-11 14:20:13
Message-ID: 20150211142013.GA23587@toroid.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At 2015-02-11 13:20:29 +0200, hlinnakangas(at)vmware(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-02-11 14:26:23 Re: reducing our reliance on MD5
Previous Message Albe Laurenz 2015-02-11 14:16:47 Re: SSL renegotiation and other related woes