Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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.

share|improve this question
4  
For starters, 64-bit Windows will use all of your allocated RAM. –  user3463 Feb 7 '11 at 6:32
2  
Why do you care that it's faster? you should be glad that it is. –  Matt H Feb 7 '11 at 7:47
    
@Randolph I get that, but how does that affect the x86 things? @Matt No, I'm glad, of course. I'm just very curious. I can't, for the life of me, understand WHY it's happening. –  Jasper Feb 7 '11 at 7:54

6 Answers 6

up vote 6 down vote accepted

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.

share|improve this answer
    
I commented with my experiences on GrandmasterB's answer. How can experiences be coincidental with the same (amount of) things installed (especially, Windows' own functions) on the same machine TWICE? Was Windows 7 somehow more optimized for being x64? Are hardware vendors more careful about their x64 drivers? If both the programs and the machine stay the same with a consistent difference, it seems like some things are being better optimized for one way than the other. –  Jasper Feb 9 '11 at 4:40
    
I do not claim the experience is coincidental in your particular case. However, for a complete explanation, such possibility should be considered in a general case. E.g. the inner/outer partition is something which can make a significant difference on loading times, and it is in no way related to 64b/32b OS. –  Suma Feb 9 '11 at 8:37
    
I'd like to add a little piece of information though. Every time I installed 7 (in this case, the first two x86 installations and the latter two x64 installations), I've always freshly installed it on the same drive completely erasing the previous install. No dual-boots were involved whatsoever. Lol. Yes, I even left the drives untouched. –  Jasper Feb 9 '11 at 13:32
    
More: I am using Aero on a 1080p monitor. Also, I always performed a quick format instead of a full format. –  Jasper Feb 9 '11 at 13:40
    
"I've always freshly installed it on the same drive completely erasing the previous install" Great to know, this rules out the "outer partition faster" possibility, as well as the OS State possibility. –  Suma Feb 9 '11 at 15:00

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.

share|improve this answer
    
Actually, only 3.25 GB is usable out of 4 GB even in x64. I was expecting this to be fixed with my upgrade from x86, but it didn't. –  Jasper Feb 8 '11 at 3:36
    
+1 for the video memory, didn't even notice he had a vid card. –  Kyle Feb 8 '11 at 13:34
2  
@Jasper: Not sure if I'm getting you right, but one of my computers uses the entire 8GB of RAM I've installed (Win 7 x64 Ultimate) –  xbonez Feb 8 '11 at 15:33
    
This is really the only thing which makes sense to me. All other things are same when running the 32b and 64b editions of the same OS on the same system. There are only two differences: 1) enhanced register and instruction set 2) 64b address space allowing to address full 4 GB or RAM and more –  Suma Feb 8 '11 at 16:08
    
Still, for sake of completeness, the part about 1 GB card hiding 1 GB of RAM is definitely not true, as anyone with 4 GB RAM, 32b OS and such card can easily witness (see also my comment to Pete's answer). –  Suma Feb 8 '11 at 16:10

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.

share|improve this answer
11  
"can process 64 bits (8 bytes) of data per clock cycle" this may sound reasonable, but actually it is nonsense. Almost no computations use 8 bytes for anything useful. As for memory traffic, the underlying CPU is the same, the cache and memory traffic use the same BUS. –  Suma Feb 8 '11 at 7:38
4  
"since more of the OS can be loaded into memory" again, not true. This would be true if the "more of the OS" would be over 4 GB. 64b addressing does not help at all while working with data under 4 GB. –  Suma Feb 8 '11 at 7:50
4  
@Kyle : you're discussing the difference in hardware architecture, the question is about software working on hardware with the same architecture. That's what Shuma is trying to get through to you. –  Joris Meys Feb 8 '11 at 15:01
6  
@Kyle : read the question again. The processor is the same as it's on the same machine. It's about the difference of OS behaviour on the same machine, not the difference between two machines. and fyi, I'd like to keep to the argument. Yelling at people never helped anybody. Plus, I am a computer user, and this is a computer user question. So why shouldn't I answer it? –  Joris Meys Feb 8 '11 at 15:08
6  
You can't answer on a public forum without thick enough skin to take some lumps. You also have to be able to handle the pedantic nature of computer nerds picking thru every detail of question AND answer. Don't pull your punches, but make sure you give posts good thought. make corrections as your proven wrong, and stand your ground when your right. –  WernerCD Feb 8 '11 at 17:15

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.

share|improve this answer

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.

share|improve this answer
1  
Great idea. Knowing more what "faster" actually means could help. Do applications load faster? Do window animate faster? Do games have higher fps? Are files copied faster? It is quite possible all the explanation here, while interesting to understand the 32b and 64b OS difference, are actually irrelevant to the real difference Jasper describes. –  Suma Feb 8 '11 at 19:54
    
Alright, let me give you a clearer picture of what I'm talking about. I had Windows 7 x86 for a while with 100% of my needed software and games installed. I reinstalled the same system on on the same machine along with the same amount of software and games, and it delivered me an identical experience. I clean my registries once a day, fragment my hard drives every few days, and always maintain a decent amount of free space in each drive. Anyway, after these, I installed Windows 7 x64 twice with 100% of my required things in it only to find both of the latter experiences identical. [Continue] –  Jasper Feb 9 '11 at 3:51
    
The things that felt better – windows animating smoother, files being copied a lot faster, certain photo editing programs drawing faster (both x86 and x64), HD videos running smoother (on MPC-HC x64), and an overall more stable experience. The games didn't show any change. –  Jasper Feb 9 '11 at 3:57
    
You see, these are little things. But, I'm not understanding WHY these little things are happening which gave birth to this question. =) I wouldn't have bothered if I had 4+ GB RAM. I'd have given the credits to Windows 7 x64 being able to handle that, but that's not the case in here which makes it a little more complex. –  Jasper Feb 9 '11 at 4:01

I think that the most profound reason why the system is faster using a 64bit OS is because the 32bit OS is not capable of utilizing all the RAM in the system.

The 32bit OS will be able to control 32bits, i.e. 4GB of physical address space. This address space includes system memory, video memory, IO devices, etc. So when you have 1GB dedicated video ram, you can subtract the first GB from your available ram. Then the other devices will probably subtract another 200MB or so.

This leaves you with only 2.8 GB of RAM for applications. Not a lot on Windows 7 ;)

The 64bit OS on the other hand is capable of utilizing all your RAM.

share|improve this answer
    
"So when you have 1GB dedicated video ram, you can subtract the first GB from your available ram." I am sorry to be such a nuisance here, but this does not seem to be true. I had a WinXP system with 4 GB RAM and 1 GB dedicated VRAM GPU and I had 3.6 GB of RAM available for the system. The address space question is quite complicated: e.g. each process has a 4 GB of virtual address space. Driver need to map GPU RAM into virtual address space so that they can access it, but there is no need for OS to map GPU RAM into physical RAM. –  Suma Feb 8 '11 at 16:05
    
@Suma then perhaps not all the VRAM is not mapped to the physical ram. But 32bit windows XP, Vista, and 7 will not be able to use more than 4GB of physical address space. Some 32bit server versions of windows will be able address more however using physical address extensions (though you can enable physical address extensions in 32bit desktop windows os'es, it will still refuse to address more than 4GB of physical address space). So place 4GB of RAM in a 32bit windows 7, and you will not be able to use it all. The virtual address space for processes have nothing to do with this limit –  Pete Feb 8 '11 at 16:54
    
"But 32bit windows XP, Vista, and 7 will not be able to use more than 4GB of physical address space." Yes, this is true. For a detailed explanation see codinghorror.com/blog/2007/03/…. The GPU definitely eats some of the 4 GB space. I only wanted to correct the common misconception the address space eaten is need to access the GPU RAM, which in fact it is not. The description in superuser.com/questions/242562/… is correct in this respect. –  Suma Feb 8 '11 at 19:19

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.