Message-ID: <448E25FB.1080902@eclinic.com.au>
Date: Tue, 13 Jun 2006 12:42:03 +1000
From: Leigh Dyer <leigh@eclinic.com.au>
User-Agent: Thunderbird 1.5.0.2 (X11/20060521)
MIME-Version: 1.0
To: Alex Turner <armtuk@gmail.com>
Cc: Steve Atkins <steve@blighty.com>,
	"Pgsql-Performance ((E-mail))" <pgsql-performance@postgresql.org>
Subject: Re: 64-bit vs 32-bit performance ... backwards?
References: <1150151282.14661.42.camel@tigger>	
	<54CA6A16-AB42-440D-B5DB-BC43AE283ED8@blighty.com>	
	<448E11B1.20309@commandprompt.com>	
	<1BAED8DB-01CE-4D10-A509-91FB4DF1F04D@blighty.com>
	<33c6269f0606121926p15107d2fq9d395460269e2e53@mail.gmail.com>
In-Reply-To: <33c6269f0606121926p15107d2fq9d395460269e2e53@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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