Re: x86-64 and PostgreSQL
От | Shridhar Daithankar |
---|---|
Тема | Re: x86-64 and PostgreSQL |
Дата | |
Msg-id | 3E2C34E7.25952.E6C1A58@localhost обсуждение исходный текст |
Ответ на | Re: x86-64 and PostgreSQL (Ron Johnson <ron.l.johnson@cox.net>) |
Список | 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 по дате отправления: