Re: New CRC algorithm: Slicing by 8

Поиск
Список
Период
Сортировка
От Jeremy Drake
Тема Re: New CRC algorithm: Slicing by 8
Дата
Msg-id Pine.BSO.4.64.0610231235490.5201@resin.csoft.net
обсуждение исходный текст
Ответ на Re: New CRC algorithm: Slicing by 8  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Tsearch2 index size
Следующее
От: Zdenek Kotala
Дата:
Сообщение: COPY does not work with regproc and aclitem