Convince me to go to 64bit

[EML]

I am just wondering what are the benefits of going to 64bit? Currently all our binaries are on 32-bit and the only thing we know of the good thing going to 64 is with a large memory addressing. We are already activating the 3rd and 4th quadrants for the data segments, and I've seen on this forum that going to 64 would be better.

But aside from that, what are the benefits?

Any HP documentations telling more on this comparison?

And by this time, is it still better to port to 64bit on PA-RISC, or its time to think of IA64?

[Steven E. Protter]

I'd stick with PA-RISC, more bang for the buck, more stable than Itanium.

The bottom line on 64 bit is that the new hardware is all 64 bit only. The industry has decided that is where its going. In a few years you won't be able to obtain HP hardware in any kind of decent condition that runs 32 bit.

64 bit instructions are bigger, but the processors have the muscle to handle that.

You have a choice with regards to your binaries now, but in the years ahead, if you want to stay current and supported, you're going 64 bit.

So, nobody needs to convice you, eventually its going to get hard to run your operatoin 32 bit.

SEP

[Robert-Jan Goossens]

Hi,

One other thing is the end off support for hardware and OS on 32 bit. For 11.0 12/31/06, 11.i will run a few years more on 32 bits, but will be "I think" the last 32bits OS.

server overview.
http://devrsrc1.external.hp.com/STK/serversupport.html

os overview
http://www.software.hp.com/RELEASES-MEDIA/history/slide2.html

Hope it helps,

Robert-Jan.

[Tim D Fulford · Accepted solution]

The problem of going from 32 to 64 bit is that some code seems to run slower, when in theory it should run faster!! The reason for this is simply 64bit requires more resource.

There is a heirachy of speed with CPU at the top (& CPU cache), RAM in the middle (~100 times slower than CPU) and disk at the bottom (~1,000,000 times slower than CPU). If you move to 64 bit, then on a particular chipset you effectively 1/2 the [instruction] cache. thus more of your code will live in RAM. This then may then cascade to the disk. In theory 64-bit is twice as fast as 32 (OK app dependant). So if stuff starts to cascade down the performance penalty could be 10 times or MORE worse.

Whilst this may seem like a reason to stick with 32-bit, you also need to look at the chipsets available. If you look at the PA-RISC 550MHz (I've forgitten the PA8500 or what ever) it had something like 1.5 MB (chip) cache, the 750MHz (& 850MHz I think) has 2.25 MB cache, 50% more. The Itanium2 1GHz has 4MB cache & the Itanium2 1.5GHz has something like 6MB cache (check out www.tpc.org for OLTP TPM & chipsets etc)

This gain in CPU cache vastly out strips the 32/64 bit conversion. So in summary, & this is just a CONSERVATIVE rule of thumb, & generally in an ideal world too.. (yeh, like you live there!)

1 - Most preferable try to double your CPU cache, probably a 50% increase is suffice. (OK I know you want to run on same HW & Chipset)
2 - Next preferable, add more memory, this should help reduce the worst effects
3 - Make sure you have enough swap space (add more disk!)

Most of "De Management" belive a simple re-compile will do the job. This may, if you are lucky, give you everything you need, but you will still probably need to tweak your hardware.

I'm sorry this is not a straight "go 64bit it is lightning fast" more of a "well planned port will help!"

Regards

Tim

[Caesar_3]

Hello!

Don't think about the IA64 it's not worth,
for my opinion the itanium is mistake.
HP leave the development of as also intel.
Intel as the developer of the itanium processor
look on the other 64bit production that she
made as HP also not see the feature there.

The idea of go to 64bit OS is depend on how
you see the feature, the development.
If you see lot of new development then
you should check the option to upgrate.
The new hardware produce for 64bit operations.
But if no new changes needed and the system
works good i don't think you should change.

Caesar

[Mike Stroyan]

Some of the earlier replies seem to confuse the transition to 64 bit addresses and the move to IA64. Both PA-RISC and IA64 have 32-bit and 64-bit execution modes for HP-UX.
There is an overview of 32-bit to 64-bit transitions at
http://h21007.www2.hp.com/dspp/files/unprotected/64bitAppDev.pdf
It notes a few additional benefits on PA-RISC related to calling convention improvements made when the 64-bit implementation gave the developers a chance to 'redo' some designs.
The choice of 64-bit mode is usually about address space. If you have already needed to enable +q4p, then it sounds like you may need that extra address space soon.
There can be other benefits from 64-bit mode, but they are less common. If you work with large files, then 64-bit mode can use large files without any of the changes to file related functions required by 32-bit mode.
A performance penalty for 64-bit can come from increasing the size of pointers and size_t related data types. Another, less expected, issue can be the use of int and long. If code uses a mixture of int and long types then frequent conversion between 32-bit int and 64-bit long can add alot of instructions. If code does a lot of integer math on longs, then 64-bit divides and modulo operations can be slower than the same operations on 32-bit longs. In some cases long is used when int would be adequate.

It may be time to think about moving to IA64. It can give much better performance than PA-RISC. You can make that move independent of moving to 64-bit. One caution is that the q3p and q4p modes are not supported in 11.20, (11iV1.6). An upcoming release will add a new mode that allows about 3.7GB of data in a 32-bit process on IA64. Another consideration is the availability of all the libraries that your programs need. If you recompile for either 64-bit or IA64 32-bit you will need source or ported versions of any libraries your
code depends on.
I am going to drift a bit from your questions. If you are using big data and looking for performance improvements, then you should consider using large pages. That is independent of 32 or 64 bit, PA-RISC or IA64. You can link with +Wl,+pd1M to request 1MB pages. That increases the size represented by each TLB entry. It can dramatically improve performance of code that accesses far-flung addresses. To get large pages you should configure the dbc_min_pct and dbd_max_pct kernel tunables to the same value. A really dynamic file system buffer cache tends to fragment physical RAM and get in the way of allocating large pages. (If the kernel can't find contiguous RAM for a large page then it just allocates several smaller pages to do the job.)

[Mike Stroyan]

Oops. I typed 11.20 and 11i v1.6. I meant to type 11.22, still 11i v1.6.

[Ian Dennison_1]

Because if you have a memory intensive application and need to address higher portions of memory for your apps, you will need to use Shared Memory Magic to allow 32 bit applications to use more memory (Anyone remember the Upper Memory Bracket in DOS 3.3?)

Not a pleasureable experience. Share and Enjoy! Ian

[R. Allan Hicks]

My choice between 32 and 64 bit was easy. Oracle said 'If you want us to support your database, you have to go to 64 bit'

Thanks Larry, I hope Oracle's move helped HP sales when I had to buy new servers.

[John Bolene]

IA64 is great if you have the Itanium 2. The new processors coming out later this year (August I think) will be even better.

Don't go to 64 bit unless you need to as most 64 processes are a bit slower than the 32 bit versions.

Needing to is normally with Oracle databases or the newer machines that only run on 64 bit.