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.#include "postgres.h"
#include <time.h>
#include <sys/time.h>
#include "pg_crc.h"
int
main()
{
char buffer[TESTSIZE];
pg_crc32 mycrc[2];
int j;
struct timeval tstart;
struct timeval tstop;
srand(time(NULL));
for (j = 0; j < TESTSIZE; ++j)
buffer[j] = (char) (255 * (rand() / (RAND_MAX + 1.0)));
gettimeofday(&tstart, NULL);
for (j = 0; j < NTESTS; j++)
{
INIT_CRC32(mycrc[j&1]);
COMP_CRC32(mycrc[j&1], buffer, TESTSIZE);
FIN_CRC32(mycrc[j&1]);
}
gettimeofday(&tstop, NULL);
if (tstop.tv_usec < tstart.tv_usec)
{
tstop.tv_sec--;
tstop.tv_usec += 1000000;
}
printf("bufsize = %d, loops = %d, elapsed = %ld.%06ld\n",
TESTSIZE, NTESTS,
(long) (tstop.tv_sec - tstart.tv_sec),
(long) (tstop.tv_usec - tstart.tv_usec));
return 0;
}
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
