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
Related
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).
I am developing a 32 bit application in .NET that for various reasons cannot be compiled as a 64 bit application.
I need to run many of these concurrently and they use a lot of memory. I want to load up a Windows 7 box with tonnes of memory and consequently would like to use the 64 bit version of Windows 7 so that we can put many gigabytes of RAM on those boxes.
My question is this: The maximum memory used by each instance of my app is ~500mb. In Windows 7 64bit, these 32-bit applications will run (I assume) using the WOW64 emulation layer in Windows. As I begin to run more and more of these instances concurrently, will they all be stuck running in the bottom 2gb of ram, or will Windows allocate memory for them using all of the higher-address range of memory possible within 64-bit Windows? Is the addressable-memory limitation of 32 bit software only a per-instance limitation in this case, or will all the instances be limited to the bottom 2gb of ram?
You are confusing memory (physical address space) with virtual address space. You can put more than 4GB of memory into a 32-bit system; you don't need to move to 64-bit to gain physical address space. Each process gets its own virtual address space, so each one will get its own 2GB of user-mode address space to play with. (Or 3GB if /3GB or 4GB if running on WOW64 with /LARGEADDRESSAWARE.)
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.
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.
Imagine the same hardware running Windows XP 32bit, or Windows XP 64bit..
(being that it's a 64bit processor currently running XP 32bit)
2gigs of ram...
Will the performance of Visual Studio benefit from going to the 64bit OS?
The hardware and ram is currently out of my control... If I could throw more hardware or ram at it I would.
For 2 GB of RAM, most likely not. The biggest advantage of 64-bit is the additional address space. With 2GB of physical RAM, 32-bit OS's can map all of physical memory.
Above 3GB 64-bit OS does give some benefit, since some of your physical memory may be unusable on 32-bit OS's due to devices mapping physical addresses for their own use.
And obviously if you want to use above 4 GB of memory you should absolutely go for a 64-bit OS.
Yes, if you have sufficient physical memory, you will gain some benefits from running Visual Studio in 64-bit Windows as described in Visual Studio: Why is there no 64 bit version? (yet):
Doesn’t being a 64 bit application save you all kinds of page faults and
so forth?
A 64 bit address space for the process
isn’t going to help you with page
faults except in maybe indirect ways,
and it will definitely hurt you in
direct ways because your data is
bigger. In contrast a 64 bit
operating system could help you a lot!
If you’re running as a 32 bit app on a
64 bit OS then you get all of the 4G
address space and all of that could be
backed by physical memory (if you have
the RAM) even without you using 64 bit
pointers yourself. You’ll see
potentially huge improvements related
to the size of the disk cache (not in
your address space) and the fact that
your working set won’t need to be
eroded in favor of other processes as
much. Transient components and data
(like C++ compilers and their big .pch
files) stay cached in physical
memory, but not in your address space.
32 bit processes accrue all these benefits just as surely as 64 bit
ones. (my emphasis added)
not unless you add more RAM.
In fact 64 bits might even slow you down because 64-bits Windows sometimes have to load both 32-bits and 64-bits versions of a same DLL in RAM.
Add more RAM is the way to go because if you are using Windows 7 or Vista they aggressively caches disk files in RAM.