Re: 64-bit vs 32-bit performance ... backwards? - Mailing list pgsql-performance

From Leigh Dyer
Subject Re: 64-bit vs 32-bit performance ... backwards?
Date
Msg-id 448E25FB.1080902@eclinic.com.au
Whole thread Raw
In response to Re: 64-bit vs 32-bit performance ... backwards?  ("Alex Turner" <armtuk@gmail.com>)
Responses Re: 64-bit vs 32-bit performance ... backwards?
List pgsql-performance
Alex Turner wrote:
> Anyone who has tried x86-64 linux knows what a royal pain in the ass it
> is.   They didn't do anything sensible, like just make the whole OS 64
> bit, no, they had to split it up, and put 64-bit libs in a new directory
> /lib64.  This means that a great many applications don't know to check
> in there for libs, and don't compile pleasantly, php is one among them.
> I forget what others, it's been awhile now.  Of course if you actualy
> want to use more than 4gig RAM in a pleasant way, it's pretty much
> essential.
>
That depends entirely on what AMD64 distribution you use -- on a Debian
or Ubuntu 64-bit system, the main system is pre 64-bit, with some
(optional) add-on libraries in separate directories to provide some
32-bit compatibility.

On the performance stuff, my own testing of AMD64 on AMD's chips (not
with PostgreSQL, but with various other things) has shown it to be about
10% faster on average. As Luke mentioned, this isn't because of any
inherent advantage in 64-bit -- it's because AMD did some tweaking while
they had the hood open, adding extra registers among other things.

I remember reading an article some time back comparing AMD's
implementation to Intel's that showed that EM64T Xeons ran 64-bit code
about 5-10% more slowly than they ran 32-bit code. I can't find the link
now, but it may explain why some people are getting better performance
with 64-bit (on Opterons), while others are finding it slower (on Xeons).

Thanks
Leigh

> Alex.
>
> On 6/12/06, *Steve Atkins* <steve@blighty.com
> <mailto:steve@blighty.com>> wrote:
>
>
>     On Jun 12, 2006, at 6:15 PM, Joshua D. Drake wrote:
>
>      >
>      >> Empirically... postgresql built for 64 bits is marginally slower
>      >> than that built
>      >> for a 32 bit api on sparc. None of my customers have found 64
>     bit x86
>      >> systems to be suitable for production use, yet, so I've not tested
>      >> on any
>      >> of those architectures.
>      >
>      > Really? All of our customers are migrating to Opteron and I have
>      > many that have been using Opteron for over 12 months happily.
>
>     An Opteron is 64 bit capable; that doesn't mean you have to run 64 bit
>     code on it.
>
>     Mine're mostly reasonably conservative users, with hundreds of machines
>     to support. Using 64 bit capable hardware, such as Opterons, is one
>     thing,
>     but using an entirely different linux installation and userspace
>     code, say, is
>     a much bigger change in support terms. In the extreme case it makes no
>     sense to double your OS support overheads to get a single digit
>     percentage
>     performance improvement on one database system.
>
>     That's not to say that linux/x86-64 isn't production ready for some
>     users, just
>     that it's not necessarily a good operational decision for my
>     customers. Given
>     my internal workloads aren't really stressing the hardware they're on
>     I don't
>     have much incentive to benchmark x86-64 yet - by the time the numbers
>     might be useful to me we'll be on a different postgresql, likely a
>     different
>     gcc/icc and so on.
>
>     Cheers,
>        Steve
>
>
>     ---------------------------(end of broadcast)---------------------------
>     TIP 2: Don't 'kill -9' the postmaster
>
>


pgsql-performance by date:

Previous
From: David Wheeler
Date:
Subject: Re: 64-bit vs 32-bit performance ... backwards?
Next
From: Zydoon
Date:
Subject: Re: scaling up postgres