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
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 |