Re: 64-bit vs 32-bit performance ... backwards?

From: Leigh Dyer <leigh(at)eclinic(dot)com(dot)au>
To: Alex Turner <armtuk(at)gmail(dot)com>
Cc: Steve Atkins <steve(at)blighty(dot)com>, "Pgsql-Performance ((E-mail))" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: 64-bit vs 32-bit performance ... backwards?
Date: 2006-06-13 02:42:03
Message-ID: 448E25FB.1080902@eclinic.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)blighty(dot)com
> <mailto:steve(at)blighty(dot)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
>
>

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2006-06-13 02:44:01 Re: 64-bit vs 32-bit performance ... backwards?
Previous Message Christopher Browne 2006-06-13 02:31:57 Re: 64-bit vs 32-bit performance ... backwards?