Re: Cost of XLogInsert CRC calculations

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Mark Cave-Ayland <m(dot)cave-ayland(at)webbased(dot)co(dot)uk>
Cc: 'Christopher Kings-Lynne' <chriskl(at)familyhealth(dot)com(dot)au>, 'Tom Lane' <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 'Bruce Momjian' <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Cost of XLogInsert CRC calculations
Date: 2005-05-16 18:51:48
Message-ID: 1116269508.3830.519.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 2005-05-16 at 12:12 +0100, Mark Cave-Ayland wrote:
> This now gives the following (correct) result on both platforms:
> Win32: 1.8GHz P4, WinXP
> Linux: 2.8GHz Xeon, FC1
>
>
> Win32 UINT64: 0x782104059a01660 (crc0)
> ~158us
> Win32 UINT32: 0x78210405 (crc1), 0x59a01660 (crc0) ~58us
>
> FC1 UINT64: 0x782104059a01660 (crc0)
> ~76us
> FC1 UINT32: 0x78210405 (crc1), 0x59a01660 (crc0)
> ~29us
>
>
> Note that we still find that using the INT64_IS_BUSTED code is over 100%
> quicker than the UINT64 code for CRC64 calculation, and I believe it is not
> being used by default under Linux or Win32 for 32 bit platforms. Of course
> Tom's suggestion of going for CRC32 across the board would hopefully solve
> this entirely and bring the times down a little further too.

I think perhaps that the difference in hardware is the reason for the
difference in elapsed time, not the OS.

The performance gain is disturbing. I think its supposed to be the other
way around isn't it? Like having INT64 is supposed to be good...

Perhaps the BIOS on your systems don't correctly support 64-bit, so
mimicking it costs more.

Best Regards, Simon Riggs

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2005-05-16 20:16:59 Re: bitmap scans, btree scans, and tid order
Previous Message Tom Lane 2005-05-16 18:49:03 Re: Returning the name of a primary key