Hi,
I guess there will be no change in the coding but when creating the installer u need to set the target system as 64-bit.
Hope it helps,
Vasu Natari.
If there is no change in the coding and the only thing that matters is the Add-on Installer, would the add-on so created be able to page memory beyond the conventional 4GB boundary in RAM?
The add-on, in a 64-bit machine, run in 32-bit compatibility mode because DI API and UI API are 32-bit COM Component.
I don't think there are any benefit for the addon.
Regards,
Roberto Montenovo
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?
Regards,
Frank
Dear Frank,
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...
Regards,
Kamesh
Hi Kamesh,
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.
Hi
I also think there would not be any affect on the Add-on on 64 bit system
Thanks
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.
