Re: New CRC algorithm: Slicing by 8

From: Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Benny Amorsen <benny+usenet(at)amorsen(dot)dk>, pgsql-hackers(at)postgresql(dot)org, ktm(at)it(dot)is(dot)rice(dot)edu
Subject: Re: New CRC algorithm: Slicing by 8
Date: 2006-10-23 23:06:26
Message-ID: 453D4AF2.1000308@paradise.net.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> writes:
>> Right - I think the regression is caused by libc and kernel being built
>> with gcc 3.4.6 and the test program being built with gcc 4.1.2.
>
> Why do you think that? The performance of the CRC loop shouldn't depend
> at all on either libc or the kernel, because they're not invoked inside
> the loop.
>
>

Just come to the same conclusion myself... I've got gcc 3.4.6 on Gentoo,
so tried using that, and observed no regression at all there for the
std case - which pretty much rules out any issues connected with "what
did I build kernel + libc with vs what compiler am I using now":

Intel P-III 1.26Ghz (Gentoo 2006.1)

Std crc Slice-8 crc

8192 bytes 12.967997 28.363876 (gcc 4.1.1)
8192 bytes 12.956765 13.978495 (gcc 3.4.6)

So Gentoo using gcc 3.4.6 looks like FreeBSD using 3.4.6, so the std vs
slice-8 performance seems to be all about compiler version.

Now the regression on FreeBSD for the std case might be (as Kenneth
pointed out) due to 4.1.1 being built by 3.4.6.... but I guess it is
just a nit at this point.

Cheers

Mark

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim C. Nasby 2006-10-23 23:08:55 Re: [PATCHES] smartvacuum() instead of autovacuum
Previous Message Matthew O'Connor 2006-10-23 22:39:23 Re: [PATCHES] smartvacuum() instead of autovacuum