32 or 64 bit application

[Ian Lochray]

We are planning the next release of our application. It will use Oracle 9i so we need to use 64-bit HP-UX. What I am unsure about is whether to build our application 32 or 64 bit. What are the pros and cons of both. My main concern is that we have to integrate with other applications (like CODA) which may be 32 bit only.

[T G Manikandan]

Building application with 64 bit has a big advantage which can solve all the addressing limitations.
The process can use more address space in memory.
The 32 bit process can maximum use only 960MB of memory.These limitations can be overcome with 64 bit application.

The disadv I can see is that the 64 bit applications are not faster as the 32 bit ones.


Thanks

[Ian Lochray]

Can you please expand a bit about the memory limitations of 32-bit applications. Our application runs many independant processes, none of which would use anything like 960Mb of memory. In total, however, they could exceed this amount. Would this be a problem?
Also, if, for instance, there was 4Gb of memory on a server, would a 32-bit application have access to all of this memory i.e. if the first 3Gb of the memory was in use by other applications and the 32-bit application requested a few MB, could it address it?

[T G Manikandan]

If your hpux Os is 64 bit then it would not be a problem accessing memory more than 4GB.

This restriction is only for 32 bit hpux OS.

Regarding the other two queries.

1.Assume that i have a application which is using too much memory.
If that application process is a 32 bit then that individual process cannot cross/use more than 960MB of memory.
It would throw Out of memory errors.

Also I have attached a doc which would help on the performance of 64 and 32 bit programs

http://www1.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000065950687

Thanks

[H.Merijn Brand (procura]

If you plan to use perl with DBI/DBD::Oracle, and also need a lot of other modules, beware that some don't play nice with 64bit perl. Otherwise, it's up to your resource requirements if you want 32 or 64bit apps. For 64bit perl, please use 5.8.0 or higher. There have been a lot of 64bit issues been resolved since 5.6.1

In general, 32 bit apps are faster.

Enjoy, have FUN! H.Merijn

[Ian Lochray]

Let me see if I have got this straight.
If I have a 32-bit application then, provided that none of the individual processes that make up that application use more than 960Mb of memory, a 64-bit O/S will allow the application to use as much memory as it wants.
As my application uses lots of individual processes that need about 200Mb each, I can have lots of these processes and it will be better to keep the application 32-bit as it will be faster than 64-bit.
Finally, if my application was 64-bit, would it have problems interacting with 32-bit applications such as CODA?

[H.Merijn Brand (procura · Accepted solution]

As long as the interaction is based on IPC (inter process communication: shared memory, files, semaphores) 32- and 64- processes are not limited by the restrictions of each process. 32 and 64 bit processes can interact fine.

If part of the app however available only as (shared) labrary, that means that the complete app will have to use the same architecture. You cannot build 64 bit apps using 32 bit shared libs or vise versa.

Enjoy, have FUN! H.Merijn

[Ian Lochray]

The "HP-UX 64-bit Porting and Transition Guide" says ..
Shared Memory

32-bit applications can only attach to shared memory segments which exist in a 32-bit virtual address space. 64-bit applications can attach to shared memory segments in a 32-bit or 64-bit virtual address space.

Does this mean that, if I have a lot of memory on my server that a 32-bit application cannot use all of it?

[Patrick Wallek]

Yes, that is exactly what that means.

If you are running 32-bit applications, more than 4GB of RAM is a waste. Any and ALL 32-bit applications will work within the same memory area.

Now the caveat to this is if you use memory windows. Then each 32-bit application can run in its own memory window which will allow it to have, potentially its own 4GB memory area.

Have a look at the whitepapers:
/usr/share/doc/mem_mgt.txt
/usr/share/doc/mem_wndws.txt

[A. Clay Stephenson]

That's exactly what it means. The maximum addressable space in 32-bit land is 4GB so if you have a box with > 4GB of real or virtual address space, any single 32-bit process can only access at most 4GB - though in practice typically about half that.

What you really need to find out is if your application has to link with ANY 32-bit libraries OR run in any 32-bit environments. If the answer to either question is yes, then your application should be 32-bit. NOTE: Mixed 32-bit and 64-bit is not possible - meaning all libraries and object files need to zig or to zag but not both.

It is perfectly ok for a 32-bit Oracle application to talk to a 64-bit server. You might find yourself in the situation where you only have available 32-bit versions of some needed libraries and 64-bit versions of others; you can still make this work but things now get much more complicated. You basically have to split into multiple processes, some 32-bit, others 64-bit and communicate between then using some for of IPCS.