Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group