| 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-01-09 08:32:03 |
| Message-ID: | 20150109083203.GA13128@toroid.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Heikki.
I've attached two regenerated CRC patches, split up as before.
1. The slicing-by-8 patch contains numerous changes:
a. A configure test for __builtin_bswap32
b. A comment referencing the slicing-by-8 paper (which is behind a
paywall, unfortunately, so I haven't even read it). Are more
comments needed? If so, where/what kind?
c. A byte-reversed big-endian version of the 8*256 table. In Linux,
there's only one table that uses __constant_swab32, but for us
it's simpler to have two tables.
d. Thanks to (c), we can avoid the bswap32 in the hot loop.
e. On big-endian systems, FIN_CRC32C now bswap32()s the CRC before
finalising it. (We don't need to do this in INIT_CRC32C only
because the initialiser is 0xFFFFFFFF.)
2. The sse4.2 patch has only some minor compile fixes.
I have built and tested both patches individually on little-endian
(amd64) and big-endian (ppc) systems. I verified that the _sse is
chosen at startup on the former, and _sb8 on the latter, and that
both implementations function correctly with respect to HEAD.
Please let me know if there's anything else I need to do.
-- Abhijit
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Implement-slicing-by-8-CRC-calculation.patch | text/x-diff | 63.2 KB |
| 0002-Use-the-SSE4.2-CRC-instructions-where-available.patch | text/x-diff | 7.3 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dean Rasheed | 2015-01-09 08:38:05 | Re: Possible typo in create_policy.sgml |
| Previous Message | Kyotaro HORIGUCHI | 2015-01-09 08:30:03 | Re: Async execution of postgres_fdw. |