Re: New CRC algorithm: Slicing by 8
От | Jeremy Drake |
---|---|
Тема | Re: New CRC algorithm: Slicing by 8 |
Дата | |
Msg-id | Pine.BSO.4.64.0610222317060.5201@resin.csoft.net обсуждение исходный текст |
Ответ на | Re: New CRC algorithm: Slicing by 8 (Mark Kirkwood <markir@paradise.net.nz>) |
Ответы |
Re: New CRC algorithm: Slicing by 8
|
Список | pgsql-hackers |
On Mon, 23 Oct 2006, Mark Kirkwood wrote: > Tom Lane wrote: > > > > > > Yah, I checked. Several times... but if anyone else wants to repeat > > the experiment, please do. Or look for bugs in either my test case > > or Gurjeet's. > > Just for fun, I tried it out with both GCC and with Intel's C compiler with some agressive platform-specific flags on my 2.8Ghz Xeon running Gentoo. Std crc Slice-8 crc Intel P4 Xeon 2.8Ghz (Gentoo, gcc-3.4.5, -O2) 8192 bytes 4.697572 9.806341 1024 bytes 0.597429 1.181828 64 bytes 0.046636 0.086984 Intel P4 Xeon 2.8Ghz (Gentoo, icc-9.0.032, -O2 -xN -ipo -parallel) 8192 bytes 0.000004 0.001085 1024 bytes 0.000004 0.001292 64 bytes 0.000003 0.001078 So at this point I realize that intel's compiler is optimizing the loop away, at least for the std crc and probably for both. So I make mycrc an array of 2, and substript mycrc[j&1] in the loop. Std crc Slice-8 crc Intel P4 Xeon 2.8Ghz (Gentoo, gcc-3.4.5, -O2) 8192 bytes 51.397146 9.523182 1024 bytes 6.430986 1.229043 64 bytes 0.400062 0.128579 Intel P4 Xeon 2.8Ghz (Gentoo, icc-9.0.032, -O2 -xN -ipo -parallel) 8192 bytes 29.881708 0.001432 1024 bytes 3.750313 0.001432 64 bytes 0.238583 0.001431 So it looks like something fishy is still going on with the slice-8 with the intel compiler. I have attached my changed testcrc.c file. > FWIW - FreeBSD and Linux results using Tom's test program on almost identical > hardware[1]: > > Std crc Slice-8 crc > > Intel P-III 1.26Ghz (FreeBSD 6.2) > > 8192 bytes 12.975314 14.503810 > 1024 bytes 1.633557 1.852322 > 64 bytes 0.111580 0.206975 > > > Intel P-III 1.26Ghz (Gentoo 2006.1) > > > 8192 bytes 12.967997 28.363876 > 1024 bytes 1.632317 3.626230 > 64 bytes 0.111513 0.326557 > > > Interesting that the slice-8 algorithm seems to work noticeably better on > FreeBSD than Linux - but still not as well as the standard one (for these > tests anyway)... > > > Cheers > > Mark > > [1] Both boxes have identical mobos, memory and CPUs (same sspec nos). > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings > > -- You can tune a piano, but you can't tuna fish.
В списке pgsql-hackers по дате отправления: