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?
|
Список | 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 по дате отправления: