Thread: x86-64 and PostgreSQL
Hi, Will there be any advantages to running Pg on a 64-bit CPU rather than 32-bit? The recent discussions in the "7.3.1 New install, large queries are slow" thread make me think not, since Pg says that the OS can manage buffers better: <QUOTE From="Tom Lane <tgl@sss.pgh.pa.us>"> Yeah, but isn't that theory a hangover from pre-Unix operating systems? In all modern Unixen, you can expect the kernel to make use of any spare RAM for disk buffer cache --- and that behavior makes it pointless for Postgres to try to do large amounts of its own buffering. Having a page in our own buffer instead of kernel buffer saves a context swap to access the page, but it doesn't save I/O, so the benefit is a lot less than you might think. I think there's seriously diminishing returns in pushing shared_buffers beyond a few thousand, and once you get to the point where it distorts the kernel's ability to manage memory for processes, you're really shooting yourself in the foot. </QUOTE> Also, would int8 then become a more "natural" default integer, rather than the int4 that all of us millions of i386, PPC & Sparc users use? Thanks, Ron -- +------------------------------------------------------------+ | Ron Johnson, Jr. mailto:ron.l.johnson@cox.net | | Jefferson, LA USA http://members.cox.net/ron.l.johnson | | | | "Basically, I got on the plane with a bomb. Basically, I | | tried to ignite it. Basically, yeah, I intended to damage | | the plane." | | RICHARD REID, who tried to blow up American Airlines | | Flight 63 | +------------------------------------------------------------+
On Sat, 2003-01-18 at 00:44, Tom Lane wrote: > Ron Johnson <ron.l.johnson@cox.net> writes: > > Will there be any advantages to running Pg on a 64-bit CPU rather > > than 32-bit? > > Not so's you'd notice. PG is designed to be cross-platform, and at > the moment that means 32-bit-centric. There's been occasional talk > of improving the performance of float8 and int8 types on 64-bit > machines, but so far it's only idle talk; and in any case I think > that performance improvements for those two datatypes wouldn't have > much effect for average applications. That's kinda what I expected. The ability to /relatively/ inexpensively get a box chock full of RAM couldn't hurt, though... Putting a 12GB database on a box with 8GB RAM has to make it run pretty fast. (As long as you aren't joining mismatched types!!!) -- +------------------------------------------------------------+ | Ron Johnson, Jr. mailto:ron.l.johnson@cox.net | | Jefferson, LA USA http://members.cox.net/ron.l.johnson | | | | "Basically, I got on the plane with a bomb. Basically, I | | tried to ignite it. Basically, yeah, I intended to damage | | the plane." | | RICHARD REID, who tried to blow up American Airlines | | Flight 63 | +------------------------------------------------------------+
Ron Johnson <ron.l.johnson@cox.net> writes:
> Will there be any advantages to running Pg on a 64-bit CPU rather
> than 32-bit?
Not so's you'd notice. PG is designed to be cross-platform, and at
the moment that means 32-bit-centric. There's been occasional talk
of improving the performance of float8 and int8 types on 64-bit
machines, but so far it's only idle talk; and in any case I think
that performance improvements for those two datatypes wouldn't have
much effect for average applications.
regards, tom lane
On Fri, Jan 17, 2003 at 11:29:25PM -0600, Ron Johnson wrote:
> Hi,
>
> Will there be any advantages to running Pg on a 64-bit CPU rather
> than 32-bit?
In my experience, not really. We use SPARCs under Solaris 7 and,
now, 8. We haven't found any terribly obvious advantages with the
system compiled as a 64 bit app, but we _did_ find problems with the
64 bit libraries combined with gcc. As a result of that and
pressures to get working on some other things, we stopped testing
Postgres as a 64 bit app on Solaris. We haven't done any work on
Solaris 8 with it, and that system is a little more mature in the
64-bit-support department, so when I have a chance do to more
investigation, I will.
> Also, would int8 then become a more "natural" default integer, rather
> than the int4 that all of us millions of i386, PPC & Sparc users use?
I think the problem with int8s in a lot of cases has more to do with
typer coercion. So at least in systems < 7.4, I'm not sure you'll
see a big win, unless you make sure to cast everything correctly.
A
--
----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M2P 2A8
+1 416 646 3304 x110
On 18 Jan 2003 at 11:39, Andrew Sullivan wrote: > On Fri, Jan 17, 2003 at 11:29:25PM -0600, Ron Johnson wrote: > > Hi, > > > > Will there be any advantages to running Pg on a 64-bit CPU rather > > than 32-bit? > > In my experience, not really. We use SPARCs under Solaris 7 and, > now, 8. We haven't found any terribly obvious advantages with the > system compiled as a 64 bit app, but we _did_ find problems with the > 64 bit libraries combined with gcc. As a result of that and > pressures to get working on some other things, we stopped testing > Postgres as a 64 bit app on Solaris. We haven't done any work on > Solaris 8 with it, and that system is a little more mature in the > 64-bit-support department, so when I have a chance do to more > investigation, I will. I remember reading in one of the HP guides regarding 64 bit that 64 bit is a tool provided for applications. In general no app. should be 64 bit unless required. In fact they advice that fastest performance one can get is by running 32 bit app. on 64 bit machine because registers are wide and can be filled in is less number of fetches. Sounds reasonable to me. Bye Shridhar -- Tip of the Day: Never fry bacon in the nude. [Correction: always fry bacon in the nude; you'll learn not to burn it]
On Mon, 2003-01-20 at 00:29, Shridhar Daithankar wrote: > On 18 Jan 2003 at 11:39, Andrew Sullivan wrote: > > On Fri, Jan 17, 2003 at 11:29:25PM -0600, Ron Johnson wrote: > > > Hi, > > > > > > Will there be any advantages to running Pg on a 64-bit CPU rather > > > than 32-bit? > > > > In my experience, not really. We use SPARCs under Solaris 7 and, > > now, 8. We haven't found any terribly obvious advantages with the > > system compiled as a 64 bit app, but we _did_ find problems with the > > 64 bit libraries combined with gcc. As a result of that and > > pressures to get working on some other things, we stopped testing > > Postgres as a 64 bit app on Solaris. We haven't done any work on > > Solaris 8 with it, and that system is a little more mature in the > > 64-bit-support department, so when I have a chance do to more > > investigation, I will. > > I remember reading in one of the HP guides regarding 64 bit that 64 bit is a > tool provided for applications. In general no app. should be 64 bit unless > required. In fact they advice that fastest performance one can get is by > running 32 bit app. on 64 bit machine because registers are wide and can be > filled in is less number of fetches. > > Sounds reasonable to me. Dou you, the programmer or SysAdmin, always know when 64 bits is needed? Take, for simple example, a memcpy() of 1024 bytes. Most CPUs don't have direct core-core copy instruction. (The RISC philosophy, after all, is load-and-store.) A 32-bit executable would need 1024/32 = 32 pairs of load-store operations, while a 64-bit executable would only need 16. Yes, L1 & L2 caching would help some, but not if you are moving huge amounts of data... -- +------------------------------------------------------------+ | Ron Johnson, Jr. mailto:ron.l.johnson@cox.net | | Jefferson, LA USA http://members.cox.net/ron.l.johnson | | | | "Basically, I got on the plane with a bomb. Basically, I | | tried to ignite it. Basically, yeah, I intended to damage | | the plane." | | RICHARD REID, who tried to blow up American Airlines | | Flight 63 | +------------------------------------------------------------+
On 20 Jan 2003 at 3:52, Ron Johnson wrote: > On Mon, 2003-01-20 at 00:29, Shridhar Daithankar wrote: > > I remember reading in one of the HP guides regarding 64 bit that 64 bit is a > > tool provided for applications. In general no app. should be 64 bit unless > > required. In fact they advice that fastest performance one can get is by > > running 32 bit app. on 64 bit machine because registers are wide and can be > > filled in is less number of fetches. > > > > Sounds reasonable to me. > > Dou you, the programmer or SysAdmin, always know when 64 bits is > needed? > > Take, for simple example, a memcpy() of 1024 bytes. Most CPUs don't > have direct core-core copy instruction. (The RISC philosophy, after > all, is load-and-store.) A 32-bit executable would need 1024/32 = 32 > pairs of load-store operations, while a 64-bit executable would only > need 16. Yes, L1 & L2 caching would help some, but not if you are > moving huge amounts of data... Well, that wasn't intended application aera of that remark. I was more on the line of, I have 16GB data of double precision which I need to shuffle thr. once in a while, should I use 32 bit or 64 bit? Something like that.. bit more macroscopic. I work on an application which is 32 bit on HP-UX 64 bit. It handles more than 15GB of data at some sites pretty gracefully..No need to move to 64 bit as yet.. Bye Shridhar -- Kramer's Law: You can never tell which way the train went by looking at the tracks.
On Mon, 2003-01-20 at 03:59, Shridhar Daithankar wrote:
> On 20 Jan 2003 at 3:52, Ron Johnson wrote:
>
> > On Mon, 2003-01-20 at 00:29, Shridhar Daithankar wrote:
> > > I remember reading in one of the HP guides regarding 64 bit that 64 bit is a
> > > tool provided for applications. In general no app. should be 64 bit unless
> > > required. In fact they advice that fastest performance one can get is by
> > > running 32 bit app. on 64 bit machine because registers are wide and can be
> > > filled in is less number of fetches.
> > >
> > > Sounds reasonable to me.
> >
> > Dou you, the programmer or SysAdmin, always know when 64 bits is
> > needed?
> >
> > Take, for simple example, a memcpy() of 1024 bytes. Most CPUs don't
> > have direct core-core copy instruction. (The RISC philosophy, after
> > all, is load-and-store.) A 32-bit executable would need 1024/32 = 32
> > pairs of load-store operations, while a 64-bit executable would only
> > need 16. Yes, L1 & L2 caching would help some, but not if you are
> > moving huge amounts of data...
>
> Well, that wasn't intended application aera of that remark. I was more on the
> line of, I have 16GB data of double precision which I need to shuffle thr. once
> in a while, should I use 32 bit or 64 bit?
>
> Something like that.. bit more macroscopic.
>
> I work on an application which is 32 bit on HP-UX 64 bit. It handles more than
> 15GB of data at some sites pretty gracefully..No need to move to 64 bit as
> yet..
Maybe you wouldn't get a speed boost on HP-UX, but I bet you would on
x86-64. Why? 64 bit programs get to use the new registers that AMD
created just for 64 bit mode. Thus, the compiler should, hopefully,
be able to generate more efficient code.
Also, since (at least on the gcc-3.2 compiler) a "long" and "int" are
still 32 bits (64 bit scalars are of type "long long"), existing
programs (that all use "long" and "int") will still only fill up 1/2
of each register (attaining the speed that HP alleges), but, as I
mentioned above, would be able to use the extra registers if recompiled
into native 64-bit apps...
$ cat test.c
#include <stdio.h>
#include <stdlib.h>
int main (int argc, char **argv)
{
printf("%d %d %d\n", sizeof(long),
sizeof(int),
sizeof(long long));
};
$ gcc-3.2 test.c && ./a.out
4 4 8
--
+------------------------------------------------------------+
| Ron Johnson, Jr. mailto:ron.l.johnson@cox.net |
| Jefferson, LA USA http://members.cox.net/ron.l.johnson |
| |
| "Basically, I got on the plane with a bomb. Basically, I |
| tried to ignite it. Basically, yeah, I intended to damage |
| the plane." |
| RICHARD REID, who tried to blow up American Airlines |
| Flight 63 |
+------------------------------------------------------------+
On 20 Jan 2003 at 6:06, Ron Johnson wrote: > On Mon, 2003-01-20 at 03:59, Shridhar Daithankar wrote: > > On 20 Jan 2003 at 3:52, Ron Johnson wrote: > > I work on an application which is 32 bit on HP-UX 64 bit. It handles more than > > 15GB of data at some sites pretty gracefully..No need to move to 64 bit as > > yet.. > > Maybe you wouldn't get a speed boost on HP-UX, but I bet you would on > x86-64. Why? 64 bit programs get to use the new registers that AMD > created just for 64 bit mode. Thus, the compiler should, hopefully, > be able to generate more efficient code. Well, that is not the issue exactly. The app. is commercial with oracle under it and it si going nowhere but oracle/HP-UX for its remaining lifecycle.. I was just quoting it as an example. > Also, since (at least on the gcc-3.2 compiler) a "long" and "int" are > still 32 bits (64 bit scalars are of type "long long"), existing > programs (that all use "long" and "int") will still only fill up 1/2 > of each register (attaining the speed that HP alleges), but, as I > mentioned above, would be able to use the extra registers if recompiled > into native 64-bit apps... I am not too sure, but most 64bit migration guides talk of ILP paradigm that is integer/long/pointer with later two going to 8 bits. If gcc puts long at 4 bytes on a 64 bit platform, it is wrong. Bye Shridhar -- Painting, n.: The art of protecting flat surfaces from the weather, and exposing them to the critic. -- Ambrose Bierce
>>>>> "Ron" == Ron Johnson <ron.l.johnson@cox.net> writes: Ron> Also, since (at least on the gcc-3.2 compiler) a "long" and "int" Ron> are still 32 bits (64 bit scalars are of type "long long"), According to the draft x86-64 psABI¹, which is to become the System V psABI for the x86-64 architecture, sizeof(long) == 8. This does seem necessary as most code tends to presume that an unsigned long can hold a pointer.... -JimC ¹ http://www.x86-64.org/abi.pdf