Re: New CRC algorithm: Slicing by 8 - Mailing list pgsql-hackers

From Mark Kirkwood
Subject Re: New CRC algorithm: Slicing by 8
Date
Msg-id 453D4AF2.1000308@paradise.net.nz
Whole thread Raw
In response to Re: New CRC algorithm: Slicing by 8  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Mark Kirkwood <markir@paradise.net.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
regressionat 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


pgsql-hackers by date:

Previous
From: Matthew O'Connor
Date:
Subject: Re: [PATCHES] smartvacuum() instead of autovacuum
Next
From: "Jim C. Nasby"
Date:
Subject: Re: [PATCHES] smartvacuum() instead of autovacuum