Our client is going to be on a x64 Intel architecture and use a 64 Bit OS for terminal servers. The client is going to be installed on the terminal server. Though 64 Bit OS can access RAM beyond the conventional 4 GB limit, would the Add-ons need to be coded using some special 64 Bit UI/DI APIs? I am basically concerned about being to use the 64 Bit programming capabilities in SAP Add-ons.
I know, that we can install the client on a 64 Bit operating system going forward from 200A PL47, but can we really have the rewards of a 64 Bit architecture, in terms of paging more memory than 4 GB?
While what you said is certainly true - I wonder whether compiling the add-on with /LARGEADDRESSAWARE would not bring any advantages?
At least this article on Microsoft's support seems to indicate that handling of virtual memory might be improved:
Article ID: 294418 - Last Review: April 29, 2008 - Revision: 6.1
"Comparison of 32-bit and 64-bit memory architecture for 64-bit editions of Windows XP and Windows Server 2003"
So, you are saying that doesn't have any impact?
As you might understand, vitual memory is a seconday concept of memory mapping...I was primarily concerned about sap APIs being able to map into 64 bit RAM, which means the first 32 BIT are the address space as against the 32 bit add-ons in which the first 16 bit form the address space. so the addressable memory locations in RAM would be drastically reduced. As a result, if you are running a 32 bit API it can't map into memory space beyond 4GB, in which case, it will push some of the data from the first 4GB of RAM into virtual memory and load into the RAM, but not completely. Only the active part of the add-on using a 32 bit API would load into the 4GB memory space and the rest would load into Virtual memory, which is nothing but a swap file sitting on the HDD. Now the HDD retrieval and write speeds are highly cripled as compared to those of RAM. Hence, my question. So, with Roberto answering the required part of my question, it would be of no good use to have a 64 bit H/W and a 64 Bit OS if my APIs don't support 64 Bit execution as they will not load beyond 4 GB memory space.
This is a bit of murky concept as this is a tradeoff between speed and possiblity...LIke you said, even if a 64 bit OS loads a 32 Bit API it will still load it into the virtual memory if the first 4GB of RAM are occupied by other processes, but this is a compromise of possible RAM speed if the API could access all the RAM space, which would have been possible only if it were a 64 BIT API....
I was only hoping for a better world out there...
Each 32 bit windows process uses a unique virtual address space to access OS memory. The 64 bit OS uses a paging table to translate a 32 bit virtual address to a 64 bit physical address. So each individual 32 bit (user-mode) process is capable of addressing up to 2GB of memory (excluding processes compiled with the /LARGEADDRESSAWARE linker option). OS memory management dictates where exactly in physical memory the virtual addresses are mapped to. I hope that makes sense.
"The rewards of a 64 bit architecture" is the ability to run more terminal sessions. We generally allocate 500mb of memory per session that has frequent use of SAP and one partner SAP DI+UI add-on. So we tend to have terminal servers with 8-10GB of memory.
Personally, I'm looking forward to the memory usage and performance enhancements made to the DI API in the 8.8 release. Add-ons consume a lot of memory and run a little sluggish for my liking. Especially so with UI add-ons that manipulate a system matrix.
Thank you everybody, this solves my quest. In particular special thanks to Roberto, as i have read earlier in some of the blogs that the UI and DI API of SAP B1 are 32 bit. While i was wondering if there is any better way, your answer has put and end to my dreams. Ha ha. It is high time SAP B1 does some research and release 64 Bit APIs to take full advantage of the address space, without this, 64 Bit systems are just like body without a soul.