32 bit applications on 64 bit OS ( windows ) - windows

I need some help understanding how 32 bit applications use memory on a 64 bit OS.
A 32 bit application can use 2 gb of memory on 64 bit OS, correct?
Does this mean that 3 32 bit applications running in parrallel could address 6 gb of memory...
Or do the 3 32 bit applications have to share the 2-4 gb of 32 bit memory that the os has?
Likewise, If I have a webservice that is compiled as 32 bits, running under IIS on a 64 bit machine. As long as a single request to that webservice always stays under 2gb of memory usage, is there any point in recompiling to 64 bit? My theory is that IIS creates a new process for each request, so the whole pool of processes will be able to make use of all the memory the 64bit machine has , 8 or 15 or 20 gig or whatever.
Let me know your thoughts, thanks

Yes, the total usage of all the 32-bit programs can exceed 2 GB. So yes you can have a bunch of 32-bit processes using all the memory in a 64-bit machine.
Actually, there's a compiler option that lets 32-bit programs use up to 3GB in Windows.
If performance isn't important, then there isn't much of a reason to use 64-bit.

Related

32 bit/64 bit Compiling and Application Speed

I just got a new 64 bit computer and I am still trying to understand the differences between 32 bit and 64 bit. I understand that applications built using 64-bit dependencies can only run on a 64 bit, but applications built with 32-bit dependencies can run on both 32 and 64 bit systems.
However, is there any other differences? I know some programs have two different windows versions you can download, one for 64 bit and one for 32 bit. Why do they provide the two different types? Is there a speed increase for compiling a program with 64 bit dependencies for a program to run on a 64 bit system?
Besides from speed some programs do not have a choice. They need to match the bitness of the host operating system exactly.
A good example is TortoiseSVN which installs a shell extension. Shell extensions are DLLs loaded into other processes. So TortoiseSVN must provide a 64 bit DLL on x64 system if it wants to provide a shell extension.
Drivers are a second example of this.
When it comes to speed there is a difference of course. It depends very much on what the program does. If a program does not require high performance providing an x64 executable does not help and is a waste of time for both developers just as for users.
Here is what causes a performance difference for the case 32 bit on 64 bit OS:
Higher kernel-call cost because of the mode switch
More registers, higher code size: For calculation intensive programs this works vastly in favor of native 64 bit apps. For other types of app, or for business style web applications the bigger code and pointer sizes might cause a net loss (so 64 bit slower than 32 bit!)
Access to more than 3GB of memory. This obviously comes into play rarely as of 2012. Think of databases, Photoshop, ...
The speed increase depends on what the application does, as usr said. But fundamentally a 64-bit CPU is able to process twice as much data as a 32-bit one in the same amount of time; but the machine instructions to do so are specific to the 64-bit processor, so existing native programs have to be recompiled (at the very least) to show the benefit.
In the case of x86_64, memory pointers are also now 64 bits wide instead of 32, meaning much more memory can be addressed by programs. However, the code takes up roughly twice as much space in disk and on memory; if you're on a 64-bit system that's starved for memory, swapping can potentially be a lot worse.
Performance will roughly the same for most languages.
The main reason to go for 64 bit is the addressable memory. A32 bit process has only access to 2 GB of data, but a 64 bit process can access 18 quintillion Bytes (that is way more than the amount of RAM you can put in your machine).

32 bit process consuming more memory in 64 bit os?

I have written one process. If Run that process in 32 bit windows OS it is consuming around 100 to 200MB of memory, And the same process if i run on 64 bit Windows OS it is consuming around 1GB of memory. Can anybody explain me Why this is happening.?
Thanks and Regardsm
shahid nx

x86 - x64 porting query

We have an application written in C/C++ code running on 32-bits windows with 32-bit Hardware. My question is that if we upgrade our hardware to 64-bit and keep our OS 32-bit, does my application need a port to 64-bit? If it requires, what benefits will be there on a 32 bit OS?
Hardware doesn't count -- the OS does. Ergo:
32 bit hardware with 32 bit OS will run only 32 bit ports
64 bit hardware with 32 bit OS will run only 32 bit ports
64 bit hardware with 64 bit OS will run both 32 bit and 64 bit ports
The advantage of recompiling for 64 bit is access to more than 3GB ram and a speed increase if you operate on 64 bit datatypes or take advantage of compiler intristics (and a few others, but do not count on a immedate gain).
If you keep the OS 32-bit, you must keep the app 32-bit, for many common values of OS. We, of course, cannot use telepathy to tell which OS you are using.

Simple question: Can x86 apps take advantage of the extra RAM a x64 OS gives?

I hope someone with a bit of knowledge can clear this up. There's many discussions about the reasons to run a 64-bit OS (e.g. Windows 7 x64), but many people seem to think that their old x86 apps will be able to take advantage of any RAM greater than 3.5GB.
As I understand it, though, x86 apps cannot address memory that high... unless they've been specifically programmed to (which very few will have).
Can someone knowledgeable clear this up for me, once and for all? Can 32-bit apps take advantage of a system running 8GB of RAM?
E.g. If a user decided (for whatever reason) to run several x86 apps at once, filling the RAM as much as possible, would the extra addressable memory available in Windows 7 x64 be used?
Thanks!
On a 64 bit system, 32 bit applications are able to use the full 4GB virtual address space, minus about 64K. A default 32 bit windows system will only allow a 32 bit process to use 2 GB of virtual address space. By specially configuring the OS it's possible to push that limit up to 3 GB, but it's still not as good as what you would get on a 64 bit version of windows.
If you have 8GB of ram, that 8 GB can be divided up between multiple 32 bit processes, and the entire 8 GB will be utilized if necessary. However, no single 32 bit process will be allocated more than 4 GB of memory.
Although i don't have sources to cite, but from my knowledge: 32bit app will not be able to address more than 4GB of memory itself, unless it uses some tricks(that is very unlikely), but if you have some 32bit apps running at the same time, they can all have 4GB each, and thus two 32bit apps should be able to use all 8GB of memory. Though I'm not 100% sure.
Yes. x86 apps cannot use more than 2GB of memory at once without special tricks, but they can use any memory available.
Adding to the other (correct) answers:
Instead of the term "application" the word "process" should be used. Applications often consist of multiple processes whereas the limits discussed here apply to single processes.
Thus applications benefit from x64 that either are linked with the LARGEADDRESSAWARE flag (they can use 4 GB instead of 2 GB) or that share the load between multiple processes.
32-bit processes can work with more than 4 GB RAM even on 32-bit systems by using AWE. But a 32-bit process can only ever use 2 GB at once (4 GB with LARGEADDRESSAWARE on 64 bit respectively). AWE is primarily used by databases where it is essential for performance that the entire database fit into RAM. It works by providing a 2 GB window into a larger chunk of memory.
Here are some articles for further reading:
Windows x64 – All the Same Yet Very Different, Part 1: Virtual Memory
Windows x64 – All the Same Yet Very Different, Part 2: Kernel Memory, /3GB, PTEs, (Non-) Paged Pool
x64? My Terminal Servers Run Just Fine With 32 Bits and 8/12/16 GB RAM!
E.g. If a user decided (for whatever
reason) to run several x86 apps at
once, filling the RAM as much as
possible, would the extra addressable
memory available in Windows 7 x64 be
used?
The answer is yes. That's one of the benefits a virtual address space gives us--the ability for each process to appear (to the process) as though it's executing in a linear address space that starts at 0 and goes up from there.
As far as each of the 32-bit applications is concerned, it has its own address space from 0 to 2 gigabytes (without special tricks). The operating system handles the virtual-to-physical address translation.

How much memory can a 32 bit process access on a 64 bit operating system?

On Windows, under normal circumstances a 32 bit process can only access 2GB of RAM (or 3GB with a special switch in the boot.ini file). When running a 32 bit process on a 64 bit operating system, how much memory is available? Are there any special switches or settings that can change this?
2 GB by default. If the application is large address space aware (linked with /LARGEADDRESSAWARE), it gets 4 GB (not 3 GB, see http://msdn.microsoft.com/en-us/library/aa366778.aspx)
They're still limited to 2 GB since many application depends on the top bit of pointers to be zero.
4 GB minus what is in use by the system if you link with /LARGEADDRESSAWARE.
Of course, you should be even more careful with pointer arithmetic if you set that flag.
Nobody seems to touch upon the fact that if you have many different 32-bit applications, the wow64 subsystem can map them anywhere in memory above 4G, so on a 64-bit windows with sufficient memory, you can run many more 32-bit applications than on a native 32-bit system.
A 32-bit process is still limited to the same constraints in a 64-bit OS. The issue is that memory pointers are only 32-bits wide, so the program can't assign/resolve any memory address larger than 32 bits.
An single 32-bit process under a 64-bit OS is limited to 2Gb. But if it is compiled to an EXE file with IMAGE_FILE_LARGE_ADDRESS_AWARE bit set, it then has a limit of 4 GB, not 2Gb - see https://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx
The things you hear about special boot flags, 3 GB, /3GB switches, or /userva are all about 32-bit operating systems and do not apply on 64-bit Windows.
See https://msdn.microsoft.com/en-us/library/aa366778(v=vs.85).aspx for more details.
As about the 32-bit operating systems, contrary to the belief, there is no physical limit of 4GB for 32-bit operating systems. For example, 32-bit Server Operating Systems like Microsoft Windows Server 2008 32-bit can access up to 64 GB (Windows Server 2008 Enterprise and Datacenter editions) – by means of Physical Address Extension (PAE), which was first introduced by Intel in the Pentium Pro, and later by AMD in the Athlon processor - it defines a page table hierarchy of three levels, with table entries of 64 bits each instead of 32, allowing these CPUs to directly access a physical address space larger than 4 gigabytes – so theoretically, a 32-bit OS can access 2^64 bytes theoretically, or 17,179,869,184 gigabytes, but the segment is limited by 4GB. However, due to marketing reasons, Microsoft have limited maximum accessible memory on non-server operating systems to just 4GB, or, even, 3GB effectively. Thus, a single process can access more than 4GB on a 32-bit OS - and Microsoft SQL server is an example.
32-bit processes under 64-bit Windows do not have any disadvantage comparing to 64-bit processes in using shared kernel's virtual address space (also called system space). All processes, be it 64-bit or 32-bit, under 64-bit Windows share the same 64-bit system space.
Given the fact that the system space is shared across all processes, on 32-bit Windows, processes that create large amount of handles (like threads, semaphores, files, etc.) consume system space by kernel objects and can run out of memory even if you have lot of memory available in total. In contrast, on 64-bit Windows, the kernel space is 64-bit and is not limited by 4 GB. All system calls made by 32-bit applications are converted to native 64-bit calls in the user mode.
You've got the same basic restriction when running a 32bit process under Win64. Your app runs in a 32 but subsystem which does its best to look like Win32, and this will include the memory restrictions for your process (lower 2GB for you, upper 2GB for the OS)
The limit is not 2g or 3gb its 4gb for 32bit.
The reason people think its 3gb is that the OS shows 3gb free when they really have 4gb of system ram.
Its total RAM of 4gb. So if you have a 1 gb video card that counts as part of the total ram viewed by the 32bit OS.
4Gig not 3 not 2 got it?

Resources