Performance of 64-bit vs. 32-bit Windows Dual Core

mikemuch writes "ExtremeTech's Loyd Case has done extensive testing on the same dual-core Athlon X2 4800+ system to explore performance differences between Windows XP Professional x64 and good ole Win32. The biggest hurdle is getting the right drivers. There are a few performance surprises, particularly in 3D games."

Comments

Biggest Benefit

[dsginter]

The spyware can all be run on one of the cores while the other can be used to get work done. I'm getting one for my father-in-law.

Re:Biggest Benefit

[Wocko]

AKA the "hard" core.

Plenty of time to wait for 64 bit apps.

[Godeke]

The good this article tells us is that the 64 bit OS doesn't cause any significant loss of performance for the 32 bit applications that will function under it. On the other hand, the only 64 bit to 32 bit comparisons they have also show almost no differences. I think this is the most telling:

The good news is that 32-bit Far Cry (as of the 1.31 patch) runs fine under Windows 64-bit mode, with very little performance penalty. When we move to the base 64-bit version, we pick up a couple of frames per second at 1280x1024, but we defy anyone to actually notice the difference between 79.5 and 82 fps.

The good news is that the enhanced version still clocks in at 80 fps. This bodes well for 64-bit gaming, as game developers can add substantial new content and detail without sacrificing performance.

Desktop applications (even games) don't need the one thing that 64 bit computing really excels at: massive addressing space. A database server that is compiled to 64 bit code will have access to much more RAM, and thus have much better performance if RAM bound (which many DBs are). Meanwhile for POV-Ray the fastest result of 383 seconds was the 32bit application on 64 OS!

I think that it is safe to hold off on 64 bit for your personal desktop until a larger share of applications are compiled with 64 bit optimizations, but unlike the 16 -> 32 bit shift, I suspect the results will be underwhelming except for extremely memory consuming applications.

Re:Plenty of time to wait for 64 bit apps.

[hunterx11]

In addition to being able to address much more RAM, x86-64 chips also have more general purpose registers than their 32-bit brethren. This would probably account for performance gains more than anything else in most applications.

Why doesn't the submitter do this?

[theGreater]

http://www.extremetech.com/print_article2/0,1217,a =159811,00.asp
Printable Version
-theGreater.

After reading the benchmarks...

[vandy1]

I can only conclude that they made no attempt to use the extra registers. Of *course* an f'ing 32-bit system will outpace a 64-bit system; Why do you think most Solaris apps are still 32-bit?

The reason why x86-64 is a win is because there are more registers as well. This allows compilers to do a better job.

Marketing Hype

[oringo]

I still don't understand why someone would need a 64-bit workstation/desktop. What does x86-64 offer you other than the higher price tag? True, AMD-64 rocks in Intel's face, but the performance is gained through a direct memory interface, not by going 64-bit. The tests from TFA shows no difference between running 64-bit and 32-bit applications. If I were to own a x86-64 machine, I bet I'd turn off the 64-bit function to reduce the complexity of running applications.

Re:Marketing Hype

[Chirs]

When running in 64-bit mode you have a cleaner API with more registers. Compiler writers and low-level developers like this.

In addition, the kernel can provide the full 4GB of virtual address to userspace apps without having to resort to performance-robbing kludges.

Once you switch to 64-bit userspace apps with their huge virtual address space you can also do things like mmap() your entire 500GB disk and manipulate it as though it's all in memory.

The end user might not notice a lot but it's much nicer for coders.

And another change in marching orders:

[MrAnnoyanceToYou]

16TB addressable VM Space should be enough for ANYONE.

Standard phallacy

[vlad_petric]

The main performance gain from going to x86-64 does not come from larger operands and larger addressing space. It comes from a cleaned-up instruction set architecture and, most importantly, from a larger set of registers. x86-64 has 16 general-purpose registers whereas x86-32 arguably has about 7 GPRs. For x86-32, a compiler generally allocates 2 or at most 3 registers to variables. For x86-64, it can utilize ~12. This greatly reduces the number of loads and stores to the stack. The performance gain comes from the fact that it's much faster to communicate via a register than through memory.

BTW, I don't know about windoze, but in the Linux world going from 32 bits to 64 bits almost always seems to produce a performance gain of 10->20%. I personally tried a simulator I'm using with 64 bits (recompiled with gcc), and got a speedup of 12%.

Re:Standard phallacy

[Elwood P Dowd]

"phallacy"? Is that like when you say it's 7 inches but you know damn well it's 5?

Re:Better solution than Linux?

[nukem996]

Im on a 64bit system now. Every open source app that I use has been ported to 64bit. The few 32bit apps that I have run fine in a 64bit environment, all I have to do is make sure I have 32bit libs availible for them. Recent versions of gcc and glibc offer the ablity to do this without any trouble at all. The User Land 32bit was when the AMD64 CPU first came out but things have changed.

Architecture change

[fjf33]

From what I've been able to understand from other people that know a lot about this than me. The main gain in going from the classic 32bit x86 architecture to the AMD64/x86-64 is that they bring into play some of the things learned from the RISC architecture. Lots of registers that can be used instead of the much slower main memory. The speed comes not from the 64bit wide bus but from being able to use this very fast registers to hold and pass information. So until compilers optimize for using registers instead of the stack, then little will be gained except for higher memory requirements.

Microsoft recommends other operating systems

[serano]

A few months ago I bought a new AMD 64-bit processor and mother board. I installed XP Professional 64-bit edition, but the wireless MS mouse and keyboard I had wouldn't work. I couldn't find 64-bit drivers anywhere on MS's site, so I gave them a call. The person on the phone told me the keyboard and mouse wouldn't work with XP 64 and suggested I try another operating system. I asked if she recommmended Red Hat or Gentoo, but she just said, "No comment. Is there anything I can help you with?"

Not in these apps

[mobby_6kl]

None of thes programs they tested showed any significant difference, but scientific benchmarks seem to show significant improvement. Much smaller, but still detectable improvement in xvid/divx encoding. The 64-bit version of CINEMA 4D also benefits significantly in most cases (page 11).

Good to see them drop the old cruft... not quite

[HishamMuhammad]

A 32-bit application that has any remaining 16-bit code won't run, because WOW64 doesn't support any 16-bit code.

Hooray, it's about time. Further in the same paragraph:

"Program Files" is reserved for 64-bit apps, while "Program Files (x86)" is for 32-bit software. This will sometimes result in strange installer behavior, as with Steam, Valve Software's game download application. Steam insisted that the parentheses in "Program Files (x86)" were illegal characters, and refused to install. You can either install Steam into a different folder (e.g., \games\valve) or change the folder name in the installer to "Progra~2\valve".

Some things never change... ;)

Coding practices need rethinking...

[mi]

Complex data-structures involve a lot of pointers -- all of which are twice bigger on 64-bit machines. Sometimes, this makes the pointers bigger (or comparable) to the structures themselves.

Most obvious are char * fields. If the string is 8 characters or less, it is cheaper to just store in the structure (and pass by value, where possible).

Considering, that most such strings (and substructures) are malloc-ed (with a couple of pointers worth of malloc's overhead), the case for embedding them becomes even stronger...

Oh dear... parentheses!

[Spy der Mann]

I've had problems installing and / or running apps in directories with parentheses.

And there we go, the MAIN DIRECTORY for storing the program files uses them! Don't they ever learn? We had the same problems when dealing with Program[INSERT BIG UGLY SPACE HERE]Files. Couldn't PROGRAMS work? And look, it's 8 characters long!

Sheesh... (/rant)

Re:Oh dear... parentheses!

[Fulcrum of Evil]

We had the same problems when dealing with Program[INSERT BIG UGLY SPACE HERE]Files. Couldn't PROGRAMS work?

That was kind of the point - forcing programs to deal with spaces forced (some) app developers to deal with spaces generally.

Re:I'm taking a big risk by asking this..

[canadiangoose]

A new processor was required for the shift from 16-bits to 32-bits, but you may not have noticed because the processors came out well before the microsoft software that was available to support them.

The first x86 processor to feature 32-bit registers and addressing was the i386 released in 1985. Support for the new 32-bit features of the chip was added to Windows slowly starting with Windows 2.1 in 1987(also known as Windows/386), and provided support for virtual memory and somewhat improved multitasking. The 32-bit features in Windows were optional right through to Windows 3.1 in 1992, infact Win3.1 runs fairly well on a 286/AT with 2MB of memory. Although Windows included some 32-bit code as early as 1987, it did not provide a 32-bit API for applications until the introduction of the Win32 API with Windows NT 3.1 (1993) and Windows 95. There was also a free update released for Windows 3.1 called Win32s that provided a subset of the Win32 API for Windows 3.1 amd Windows for Workgroups 3.11, though it provided rather poor compatibility; major features like comctl32.dll and a real registry were not provided.

The first version of Windows to offer a complete 32-bit kernel and drivers was Windows NT 3.1. It provided proper support for the 32-bit funtionality as early as 1993, but it was not used much outside of a corporate environment. Home users had to wait for Windows 95, 10 frickin' years after the release of the 386!!! Even then, Windows 95 still contained a large ammount of 16-bit code!

Anyhow, I find it funny that people With Athlon64's are complaining about having to wait a year or two for a version of Windows that can make proper use of the processors. At least users now have the option of running 64-bit Linux or BSD, but alternative operating systems for the 386 didn't become available until 1993 with the release of BSD/386 and OS/2 2.0, neither of which were free.

Well, enough of my rambling. Hope that answers your question :)