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: