Re: New CRC algorithm: Slicing by 8

From: "Gurjeet Singh" <singh(dot)gurjeet(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "PGSQL Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: New CRC algorithm: Slicing by 8
Date: 2006-10-24 18:10:09
Message-ID: 65937bea0610241110m5666ce82i994543af99215fd8@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Sorry for getting into the conversation so late... It was a long weekend in
India.

On 10/23/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us > wrote:
>
> I didn't particularly trust the timing calculations in your benchmark
> program,

Any particular reason? (why and what did you doubt in it?).

I designed the prog. to be flexible to test different sized blocks (to
cost single/less INIT/COMP/FIN iterations), and different size lists of data
(to control the number of iterations). Please share you wisdom.

When I first saw your results, I had a strong feeling that function-call
overhead was going against SB8. And then, Jeremy's trials, and subsequent
success, on disabling loop optimizations also pointed to this possibility.

So, I have taken your tests and converted the SB8 function calls into
macros. And the results are (please note that crc = 0 is explained later):

std_8192_noprintcrc.out
crc = 0, bufsize = 8192, loops = 1000000, elapsed = 8.471994

sb8_8192_noprintcrc.out
crc = 0, bufsize = 8192, loops = 1000000, elapsed = 0.000006

std_8192_printcrc.out
crc = 8228BB0E, bufsize = 8192, loops = 1000000, elapsed = 32.490704

sb8_8192_printcrc.out
crc = 7E67A22A, bufsize = 8192, loops = 1000000, elapsed = 22.349156

std_64_noprintcrc.out
crc = 0, bufsize = 64, loops = 1000000, elapsed = 0.151354

sb8_64_noprintcrc.out
crc = 0, bufsize = 64, loops = 1000000, elapsed = 0.000005

std_64_printcrc.out
crc = 9C9FBE2E, bufsize = 64, loops = 1000000, elapsed = 0.559315

sb8_64_printcrc.out
crc = F70BC6AE, bufsize = 64, loops = 1000000, elapsed = 0.357382

The result names are in the format:
<algo_type>_<test_size>_<was_mycrc_referenced_in_printf>.out

crc = 0 in the result means that the mycrc variable was not refereced
anywhere after the for-loop. As can be seen, if mycrc is not refrenced in
the printf, that is, it's usage is limited to just inside the 'for' loop,
then GCC (4.1) seems to be optimizing the loop heavily. In the case of SB8,
if mycrc is not referenced later, it seems to have totally removed the
loop!!!

The only difference between the <x>_noprintcrc and the <x>_printcrc
tests was that in the printf() call, the first parameter after the format
string was either a zero or mycrc variable, respectively.

I am highly apprehensive that I might have made some mistake while
converting function calls to macros; though, I have not besen able to prove
it thus far. Please check it's validity as compared to the function-call
version.

If there's no mistake, then I think SB8 is back in the performance game
now. These results were obtained with gcc 4.1 on FC5 running on Intel
Pentium M 1.86 GHz, and OS starteted and running in runlevel 3.

Please dump the .c and .h files from the attachment on top of Tom's
package, and test it as earlier.

Best regards,

--
gurjeet[(dot)singh](at)EnterpriseDB(dot)com
singh(dot)gurjeet(at){ gmail | hotmail | yahoo }.com

Attachment Content-Type Size
my-crctest.tar.gz application/x-gzip 2.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Teodor Sigaev 2006-10-24 18:13:21 Re: Conference materials (Was: [HACKERS] pdfs of
Previous Message Tom Lane 2006-10-24 18:07:29 Re: New CRC algorithm: Slicing by 8