if a 32-bit OS running on dual core 64-bit CPU, are both core performance's are lower?
what is exactly happening inside CPU?
Are the 2 cores still working together, and slower than if equipped with 64-bit OS?
I am using a Win 7 32-bit Professional on Intel P6200.
Thanks
The major advantage of 64-bit CPUs is their ability to address more memory. It generally won't affect speed. An exception might be where a given program can run faster with more RAM, and you actually have that much RAM (more than 4GB on Windows). (And, of course, the program must be a 64 bit application.)
The processors are working together in exactly the same way. They just have smaller address spaces with the 32 bit OS.
From user perspective a 64-bit operating system mostly just allows you to run 64-bit applications. And why would you do that?
If your application has a dedicated 64-bit version, and it is heavy on numerical calculations, which were optimized to use capabilities of x64 platform (mostly more general-purpose registers), or needs a lot of RAM (more than 2GB) at once, then there are chances it will work faster.
Otherwise, most probably it will work at the same speed as 32-bit version.
It makes very little difference but my experience is that a 64 bit OS runs some 32 bit apps very slightly better than a 32 bit OS. But it's marginal at best.
Related
In my computer its running 32bit OS on the 64bit processor. So all the application installed are 32bit and my computer having a 2GB RAM. If I install a 64bit OS while keeping the same 32bit applications, will this improve the performance?? Or is there any disadvantage?
Talking about 32-bit and 64-bit software means that such software was developed in order to take advantage of CPUs with 32-bit or 64-bit registers size.
Registers are tiny portions of memory (NOT the RAM) used directly by a processing unit to temporarily save operations results (kind of variables), e.g. when summing two numbers the ALU reads from two registers, performs the operation and writes the answer in another register. The bigger those registers, the bigger values it can handle. A 32-bit processor has registers than can handle values up to 32 bits of size, as well as 64-bit processors can deal with numbers of a double size than 32-bit-based processors, which
results in 2^32 more values.
A 32-bit OS is an OS than works performing CPU operations on a machine with 32-bit CPU registers; a 64-bit OS works fine on 64-bit processors, but not on 32-bit ones because their registers are too small for such OS.
As a program runs on an OS, 32-bit apps will run (well, most times they do) on a 64-bit OS albeit they will use only half of any CPU register they need, simply because the program was designed not to deal with values bigger than 2^32 bit: this means that a 32-bit app running on a 64-bit OS will run without getting any particular performance improvement. As well, a 64-bit app will never run on a 32-bit OS because it needs more resources than those actually available.
Hope I was clear and correct enough, I studied processor architectures years ago...
This applies for a 64-bit app on x86/x86_64:
The 64-bit system will consume more RAM and most importantly cache because the larger pointers. This may be a performance bottleneck in case there are lots of pointers.
The 64-bit system will give you twice as many registers, twice as large. This makes it possible to store more variables in registers, which will be a performance gain.
So the choice may depend on which application you decide to benchmark.
The point of 64 bit is that apps can use more than 2gb of virtual memory. If you have more than 4gb of ram and your apps need to use more than 2gb of memory (sql server!) then potentially there will be a performance memory (because it can store more pages in memory rather than reading them from disk)
If this isn't the case and you have the same amount of memory then you won't get a performance increase and possibly a slight decrease as (assuming you are on windows here) to handle 32 bit apps working on a 64 bit o/s there is a complex system of redirections that happen (app asks for system32 and is sent to syswow64) - some of these are simple but some like the com registration lookups can cause many reg opens under the hood (do a regopen for a clsid that doesn't exists and see how many kernel32 makes on your behalf using procmon!).
So unless you have a very specific use case, which it sounds like you don't, it won't be faster
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).
Recently, I was surprised by the behavior of the F# compiler when using x64 target compared to x86. The same application works with the following time on different targets:
x86: 68ms
Any CPU/x64: 160ms
For me this results are strange.
The results differ by almost two-fold. I assumed that on 64-bit processor, 64-bit operating system the 64-bit application will work faster than 32-bit one.
So question is: What is wrong? Problem is in compiler or it's my fault somewhere?
Environment: Core 2 Duo and Windows 7 x64.
F# application: FsYacc/FsLex language parser. .Net 4 Framework.
This can happen for programs that use a lot of pointer-heavy data structures, since a pointer is 8 bytes on 64-bit, whereas it's 4 bytes on 32-bit. The bottleneck in pointer chasing code is cache misses. In the limit where 100% of your code is chasing pointers, you'll incur twice as many cache misses on 64-bit as on 32-bit, hence the 2x slowdown.
For other types of programs, though, 64-bit can be faster than 32-bit, at least on x86/x64. x64 has twice as many general purpose registers as 32-bit x86, newer instructions like SSE/SSE2 are guaranteed to be available on x64 but not on 32-bit x86, and with more address space you can make different space-speed tradeoffs, such as storing instead of recomputing values or memory mapping large files.
Have you tried using Int64 instead of Int32 in your app? Have you tried changing out to an 8-bit character set? How do these things affect perf?
Do you run a regular hard drive or SSD?
I was reading about WOW 64 here
http://en.wikipedia.org/wiki/WOW64
and learnt that its a layer in 64 bit Windows OS to run 32 bit programs.
So can I assume that 32 bit programs run relatively slower on 64 bit OS against when they are natively run in 32 bit OS.
I can see the advantages of memory access of over 4 GB in 64 bit OS. But does this advantage necessarily offset the small overhead added by layer of WOW64 ? Are there any other advantages of 64 bit which offset this.
The main advantage of a 64-bit system is that it allows applications in 64-bit mode, which, in turn, is primarily useful if you need to access more than 4GB memory. If you have that requirement, using a 64-bit system is your only choice. Your application would be using 64-bit code, so WOW64 would not be used, and thus not cause problems.
If you don't really have the requirement to use more than 4GB of memory in a single process, it becomes debatable whether 64-bit Windows is really an improvement. You might need 64-bit Windows if you want to use more than 4GB of main memory at all (although you can also use PAE for that, which has its own disadvantages). Still, on a 64-bit system, you can run 64-bit applications. With AMD64 processors, 64-bit mode might be faster than native 32-bit mode, because the processor has more registers. Whether this slight gain outweighs the slight loss wrt. WOW64 depends on your application mix.
Personally, I think many people install 64-bit Windows because they don't fully understand the consequences of doing so, but feel they are on the safe side (which they may not, due to the lack of drivers).
I have some matlab code that will only run on 32 bit windows, but I need atleast 6 gb of ram to run it. In my lab the only machine that has 6gb ram is running 64 bit windows, is there some way to run this code on here?
I am thinking of emulating a 32 bit windows and running it on that, will that work?
Your 32 bit application will only be able to address 4 GB when running as a 32 bit process on Windows 64 bit. In order to address more memory you need a 64 bit application.
I've recently been engaged in moving several of our large Matlab codes from 32-bit Windows XP to 64-bit Windows XP. Unlike one or two of the other answerers here, I think 6GB is a perfectly reasonable memory requirement these days; the largest desktop we use here has dual quad-core processors and 32GB RAM. Some of my scientist colleagues want more, but then they always want more.
I'd go further and advise against trying to rewrite your application to use less RAM; that would be heading in the wrong direction. It will be cheaper and quicker and generate fewer errors if you port your code to the 64-bit machine. To those who would argue for refactoring to use less RAM I would say At what point in the near future will you face up to the realities of the market and recognise that 64-bit computing is here to stay and that RAM is quite cheap, especially compared to the expense of developers time ?
Forget trying to use 6GB RAM on a 32-bit machine; as others have told you, Matlab and Windows won't do it. But, as others have remarked, Matlab is indifferent to the number of bits, so a pure Matlab code which works on a 32-bit release will work on the 64-bit version of the same release. If you move from an older 32-bit release to a newer 64-bit release you may find some Matlab functions have been retired, but you'd have the same issues moving to the newer 32-bit release anyway.
If you have a code which will only run on 32-bit Windows then I suspect you are using MEX files. These will have to be recompiled for execution on a 64-bit machine. Again, be careful to watch out for functionality which has been retired if you are moving between Matlab releases as you port. The other chief gotcha, in my experience, is false assumptions that you might make about the sizes of certain fundamental data types. Neither the Fortran nor the C standards (no C++ experience to speak of) actually specify the size in bytes of default INTEGER (for Fortran) or int (for C -- I think, not much of a C programmer). Pointer sizes are probably only vaguely specified too. What this means is that you may have to either (a) change a lot of variable declarations in your code or (b) use compiler directives/flags to specify default sizes for INTEGERS, REALS, ints and possibly others. (b) is easier, (a) is probably preferable for future maintainability.
You cannot access 6GB of RAM from a 32-bit application. This leaves you two options:
Either you optimize your code to use less RAM, or you make your Matlab program 64-bit compatible.
For the first option, the fine folks at stackoverflow can help you.
For the second option: No part of Matlab that I'm aware of is 32-bit only - unless you have a 32-bit Matlab version. However, if you have an active maintenance contract, you can download and install the 64-bit version of Matlab.
If your code calls mex-functions that are compiled for 32-bit Windows, you can try and recompile them for 64-bit Windows.
64 bit Windows will run 32 bit Windows programs just fine. But the 32 bit programs won't be able to access 6 Gb or memory, so I'm not sure that help you.
I'm pretty sure most versions of 32 bit Windows(as in, everything but Server editions) limit a single process to 2GB by default and to 3GB by changing a setting... though it is technically possible to access 16G of RAM from a Pentium Pro(and higher) CPU in 32 bit mode, I don't think anything but Windows Server takes advantage of it
and for your Matlab program to take advantage of it, you'd have to do some interesting multi-process work to manually page between 3G memory banks
You can not use 6 GB with 32Bit addresses. A 32 Bit address can only contain values from
0 to 0xffffffff (== 4294967295 == 4GB)
Such addresses are used by and are essential for every 32 Bit program, regardless if you explicitly use pointers or not.
(Although there were/are some very exotic exceptions - but those dont apply here).