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

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.

Alex.

On 6/12/06, Steve Atkins <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
>