Re: x86-64 and PostgreSQL - Mailing list pgsql-performance

From Shridhar Daithankar
Subject Re: x86-64 and PostgreSQL
Date
Msg-id 3E2C34E7.25952.E6C1A58@localhost
Whole thread Raw
In response to Re: x86-64 and PostgreSQL  (Ron Johnson <ron.l.johnson@cox.net>)
List pgsql-performance
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


pgsql-performance by date:

Previous
From: Ron Johnson
Date:
Subject: Re: x86-64 and PostgreSQL
Next
From: Tom Lane
Date:
Subject: Re: Very large caches (was Re: 7.3.1 New install, large queries are slow)