Why does Windows 7 x64 work faster than an x86 edition on my PC?
Why does Windows 7 x64 work faster than an x86 edition on my PC even though I mostly use x86 things in it? What's wrong with me, and what am I missing?
Majority of the things I use is x86 (e.g. DAWs, games, media players). A considerable amount of them, however, are x64 (although their x86 counterparts work just fine).
I've tried using the same things on the same system but always ended up finding Windows 7 x64 working slightly faster than x86. I'm very observant. I even notice the tiniest window animations.
System: Windows 7 Ultimate x64
CPU: Intel Core 2 Duo E7500 @ 2.93 GHz
RAM: 2 GB x 2 = 4 GB DDR2 @ 332 MHz
Motherboard: Intel D945GCNL
Graphics: ATI Radeon HD 4350 @ 1 GB Dedicated
Audio: M-Audio FastTrack Pro
HDD: Samsung HD753LJ 733 GB & Samsung HD160JJ 156 GB
As you can see, my system is old.
This is an attempt to provide a complete answer by summarizing bits from individual already existing answers, with some added content. The list tries to include all possibilities for a general case, even if some can be ruled out for this particular case.
CPU instruction set difference
As described by Joel Coehoorn, for a native x64 code a larger register set is available, as well as some additional instructions (e.g. all x64 CPUs are guaranteed to implement SSE and SSE2 instructions). This means native x64 OS and drivers can be more efficient.
Better RAM utilization
64b is able to use full 4 GB (and even more when available). Moreover, some OS internal limits (paged/non-paged pool, maximum cache size) are increased with 64b OS. As a result, both memory paging and file caching may be more efficient.
Different hard disc position
When you have two OSes installed on two partitions of the same disc, one of those two partitions is closes to the outer edge, which is generally faster.
Different OS state
When you have two OSes, each of them may be in a bit different state. One of them may be more fragmented than the other one, one of them may have a bit cleaner registry or less installed services or background applications than the other one.
Better drivers
Another possibility is x64 drivers might be of a better quality than x86 not because of some fundamental architecture differences, but simply because their vendor took more effort to optimize and fine tune them.
64b addressing
I add this only for completeness sake, as for vast majority of everyday applications this difference plays no role, and it definitely is not relevant to what Jasper describes in his question.
If you have an application which processes huge amounts of data (e.g. working in Photoshop with huge pictures), running 64b version can make a huge difference provided you have 4 GB or more of RAM installed.
What does "faster" really mean?
Here is the list from a comment on other answer, what exactly are the "faster things" Jasper can see:
- windows animating smoother
Hard to explain. Windows animation is done by the GPU in Windows 7 and the GPU is the same. The load on CPU is negligible. (I suppose you are using Aero desktop).
- certain photo editing programs drawing faster (both x86 and x64)
- HD videos running smoother (on MPC-HC x64), and an overall more stable experience.
Could be better tuned drivers or drivers taking advantage of x64, .
- files being copied a lot faster
Could be caused by a faster partition (not related to OS at all) or by better cache handling in x64 OS.
- The games didn't show any change.
Understandable. The games performance is determined by CPU and GPU. In case of CPU limitation the limiting code is the game itself, which is the same x86 code with little interfacing to x64 OS. The CPU performance is therefore the same. The GPU is the same. The driver and OS overhead in a well programmed game is low, therefore any driver or OS differences are not likely to show here.
The move from 32 to 64 bits is not the only change in the x64 architecture. x64 also adds more cpu registers and new cpu instructions. An operating system that knows how to take advantage of these can get a modest performance bump out of the same hardware. Oh, and getting 1GB of RAM back that used to be addressed to your video card doesn't hurt either.
Warning: this is a bit more complex question than you may have realized, and certainly more than most of the answers have portrayed. To try to cover at least a bit more of the story, this post is pretty long...
First of all, the situation with video memory. The entirety of the video card's memory is not (at least normally) directly visible in the CPU's address space. You usually have a "window" of about 128-256 megabytes of video memory visible to the CPU. The GPU can map different parts of its memory to that window, so you can typically write to most GPU memory from the CPU, but you need to tell the GPU ahead of time what you're going to write to before you can do so. Just for example, when you're using DirectX and you want to write directly to graphics memory, you can do that -- but to do it, you start by calling LockRect to get the GPU to map the right memory into the window (and as soon as you're done, you call UnlockRect so it can map other memory as needed). At least in the typical case, you can adjust the video window size in the BIOS setup.
Second, even in 32-bit mode x86 processors support what's called Physical Address Extensions (PAE), which allows the CPU to address more than 4 Gig. of memory. Microsoft does support PAE in some versions of Windows -- but only the relatively expensive Enterprise Edition of Windows Server. In addition, the program must be written specifically to use AWE. There are only a few programs (e.g., SQL Server Enterprise Edition) that have ever done so. Bottom line: it's possible, but fairly rare.
As far as reading 64 bits at a time goes: the last processor to read data only 32 bits at a time was the 486. Starting with the Pentium, all processors have had 64 bit data buses. Note that the address bus is not the same as the data bus, so expanding to a 64-bit data bus did not allow the processor to work with more memory (although, as it happens, PAE was added in the Pentium Pro, so it was almost concurrent with the expansion to a 64-bit data bus).
Even though the Pentium could read 64 bits of data in a single clock cycle, internally it (mostly) processed data 32 bits at a time. The wider bus primarily helped make up for the difference in speed between the CPU and main memory. The MMX instructions of the Pentium MMX supported processing data in 64-bit chunks, but it was rather clumsy to use and (in particular) most compilers didn't generate MMX code, so you pretty much had to write in assembly language to use it. The Pentium also supported 64-bit (and 80-bit) operations for floating point numbers, but that's used for only a fairly small minority of most programming (and was generally slower than working with integers anyway).
The x86-64 design does have twice as many general purpose registers as the 32-bit x86 design, and each of those registers is 64 bits wide. When the CPU is running in 32-bit mode, however, only the subset of the registers that existed on 32-bit CPUs is usable.
Going back to floating point for a moment, in 32-bit mode, floating point math is done using the instruction set originally designed for the Intel 8087 math coprocessor. This uses a model that makes it fairly difficult to make full use of its capabilities. Intel (and AMD) have more recently added "Streaming SIMD Extensions", or SSE. Most 64-bit compilers generate code that can/does use SSE instead of 8087-compatible floating point. The "SIMD" in SSE stands for "single instruction, multiple data". What this means is that one SSE instruction can carry out two floating point operations on two separate pieces of data. Though this doesn't necessarily double the speed, it usually improves speed at least a little bit.
Finally, I should probably point out that there's one part of the comparison that's generally a bit unfair. When you install a new OS, it's nearly always at least a little faster than an OS that's been in use for quite a while. Programs store data in the registry, on the hard drive, etc. The more data you add, the more work tends to be involved in finding the data you want at any given time. While companies selling "registry cleaners" and such frequently exaggerate this effect, it's true to some extent anyway. As such, if all you did was re-format your hard drive and re-install exactly the same OS, you could expect to see some speed improvement -- and if you've had the old OS installed and used heavily for a long time, that improvement (all by itself) can be pretty substantial. At least part of the speed improvement you're seeing may be independent of any real difference between the two OSes.
There's more than that, of course, but you start to get the idea. It isn't so much a matter of a single feature making a huge difference, as a lot of features that usually make fairly small differences individually, but many of them add (or even multiply) together to make a fairly substantial difference overall.
It may have nothing to do with 32 vs 64 bit.
Its unclear from your post what you mean by '64bit is faster'. Are we to take from that that you re-installed 64-bit Windows on a machine you previously had a 32bit Windows on? If so, the 'resetting' of the file structure can easily account for the speed changes. A new install, particularly if you reformatted, is often more responsive than an older install where files get fragmented, disk space runs low, the registry gets cluttered, etc.
It might also be one of the drivers... for example, the newer video drivers might be faster and better optimized by the vendor than the older x86 versions were. Or the hard disk driver might tbe better.
To put it simply, it is because your computer can process 64 bits (8 bytes) of data per clock cycle. Your processor receives data in the form of prearranged bits known as words. The words in x64 architecture are twice the size of words in the x86 architecture. Although your processor may not actually be processing data faster (your Core 2 is at 2.93 Ghz on both installs), it is however processing data more efficiently. Also, as mentioned in the comments it will allow you to address all of your RAM because your processor is reading from your RAM in 64 bit words. From Wikipedia:
Very often, when referring to the word size of a modern computer, one is also describing the size of address space on that computer. For instance, a computer said to be "32-bit" also usually allows 32-bit memory addresses; a byte-addressable 32-bit computer can address 2^32 = 4,294,967,296 bytes of memory, or 4 gibibytes (GB). This seems logical and useful, as it allows one memory address to be efficiently stored in one word.
For a 64 bit processor this doesn't multiple by 2, it goes up exponentially:
A modern byte-addressable 64-bit computer—with proper OS support can address 2^64 bytes (or 16 exbibytes) which as of 2011 is considered practically unlimited.
This article, although a little dated, is a very informative read about how 64 bit processing works.
I want to point out that this does not actually translate to a 2x performance increase, this is because actual performance relies on many other variables (disk speed, bus speed, processor cache, available memory ect.). But you should see a performance increases in Windows since more of the OS can be loaded into memory and addressed by the processor more efficiently.