Re: New CRC algorithm: Slicing by 8 - Mailing list pgsql-hackers

From Jeremy Drake
Subject Re: New CRC algorithm: Slicing by 8
Date
Msg-id Pine.BSO.4.64.0610231235490.5201@resin.csoft.net
Whole thread Raw
In response to Re: New CRC algorithm: Slicing by 8  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, 23 Oct 2006, Tom Lane wrote:

> Hmm.  Maybe store the CRCs into a global array somewhere?
>
>     uint32 results[NTESTS];
>
>     for ...
>     {
>         INIT/COMP/FIN_CRC32...
>         results[j] = mycrc;
>     }
>
> This still adds a bit of overhead to the outer loop, but not much.
>

That seems to have worked.
           Std crc     Slice-8 crc

Intel P4 Xeon 2.8Ghz (Gentoo, gcc-3.4.5, -O2)

8192 bytes  26.765317   10.511143
1024 bytes  3.357843    1.280890
64 bytes    0.223213    0.103767

Intel P4 Xeon 2.8Ghz (Gentoo, icc-9.0.032, -O2 -xN -ipo -parallel)

8192 bytes  29.495836   0.007107
1024 bytes  3.708665    0.012183
64 bytes    0.242579    0.008700


So the gcc times are reasonable, but the icc times for the slice-by-8 are
still too fast to be believed.  I will have to take a look at the
generated assembly later and see what gives.

My changed testcrc.c is attached, again.


-- 
"I'd love to go out with you, but I did my own thing and now I've got
to undo it."

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Tsearch2 index size
Next
From: Zdenek Kotala
Date:
Subject: COPY does not work with regproc and aclitem