From: | Jeremy Drake <pgsql(at)jdrake(dot)com> |
---|---|
To: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, mark(at)mark(dot)mielke(dot)cc, Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>, PGSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: New CRC algorithm: Slicing by 8 |
Date: | 2006-10-23 06:47:02 |
Message-ID: | Pine.BSO.4.64.0610222317060.5201@resin.csoft.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
Attachment | Content-Type | Size |
---|---|---|
testcrc.c | text/plain | 832 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Zeugswetter Andreas ADI SD | 2006-10-23 07:38:08 | Re: [SPAM?] Re: Asynchronous I/O Support |
Previous Message | Heikki Linnakangas | 2006-10-23 06:46:40 | Re: New CRC algorithm: Slicing by 8 |