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.

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

[Bloater]

> Is it possible that diminishing returns is kicking in on the register set size, or simply bad compilers (or use thereof)?

Bad compilers or more likely they haven't hand optimised their inner loops.

Most high performance ia32 (Intel Architecture 32 bit) software has hand tuned assembler for the tight inner loops, but it takes time, experience and skill to create such assembler. Some discussions I've seen put recent gcc compiling generic C for amd64 at close to the performance of hand optimised assembler for ia32 on the same Athlon 64 (for tight inner loops).

There was an article about an assembler version of a cryptographic function that showed amd64 was capable of a *huge* performance increase over ia32, due to its increased register set.

However it can also come down to implementation quality. IIRC, benchmarks of early amd64 xeon chips showed that they performed worse than ia32 on the same chip for tests that athlon 64 shows a performance *boost* in its 64 bit mode.

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

[caspper69]

Well, as ironic as it is, gcc is the one that used to suck when it came to generating functions called with the __fastcall calling convention (where function arguments are passed via registers instead of on the stack). But now, the ABI for x86-64 seems to encourage the __fastcall convention by default (assuming this is due to the extra general purpose registers). I found this out when doing some OS dev and some ASM test routines were not working in 64-bit mode. I was looking in RAX like I always had (well, EAX at least), and lo and behold, no value!! Well, a quick read of an AMD64 ABI guide from x86-64.org (which went offline last week, don't know if it's back), and I was ready to rock and roll again.

Seeing as how MSVC and icc both conform to the x86-64 ABI, I would assume that both are equally capable (they're already damn near the same anyway) of utilizing the extra registers.

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

[freidog]

Well x86 chips have pretty well developed methods of dealing the lack of registers.
Register renaming eliminates, or at least minimizes most of the problems with a small register set.
(Athlon64 has something like 72 integer registers and 122 90 bit FP registers (two of these are combined to make an XMM register for SSE vectors), almost all of which are availible in 32 bit mode).

The extra achitectual registers will help with moderate to long term storage (more than a few dozen clock cycles between uses) as the programmer will explicity specify the data remains in the register, where as with current shuffeling it's up to the CPU (and to some extent how the renamed registers are inteded to work) to determine if a write to cache is in order, or not.
And really with the longer storage times, you often have the flexibility to write out to L1 and schedual the load so that there's no penalty for the load. (ie issue the move back to the register the 3 clock cycles prior to when you need it that an L1 load usually takes).

The new registers probably won't make all that much difference in the end. But the again, nothing from the move to 64 bit will be a major impact for a while (at leat on the desktop).

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.

Good deal

[gkozlyk]

Windows 64 seems to be a good deal. From the benchmarks I looked at, i get the same, if not worse performance than the 32-bloat version. Not bad for $140US.

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... ;)

Re:performance difference

[JonLatane]

"Dual core" and "dual processor" are two very different things.

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

[markass530]

but I figure this is the only place I can get a good answer. I was just getting into computers during the 16-32 bit shift, windows 95 etc. (I was 14) How come a new proccesor wasn't required like now? Whats the difference? No need for complete laymans terms, as I consider myself a pretty avid comptuer geek, but certainly no engineer.

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

[redfieldp]

Intel x86 processors were already 32-bit as of the 386 processor. Therefore, when Windows went 32-bit, all the processors out there were already 32 bit. By contrast, until now all Intel and AMD processors have been 32 bit, with the only 64-bit processors being made by other smaller vendors. Therefore, the processor/OS upgrades are simply closer together this time, and it is more apparent. However, as another poster noted: the same driver/incompatibility issues were present when Windows went 32-bit, it was just that no one had to upgrade their hardware.

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 :)

Re:Better solution than Linux?

[poopdeville]

Of course he is.

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.

A "new era", no, an incremental improvement

[AHumbleOpinion]

A "new era", no, it's just an incremental improvement. 32- to 64-bit x86 is going to be far less dramatic than 16- to 32-bit.

Re:Better solution than Linux?

[WhiteWolf666]

Windows has the same 32-bit cruft.

With 32-bit apps, you need a 32-bit userland. That's the WoW64 bit; it's the 32-bit Windows on Windows cruft.

The main difference is that the linux stuff is organized differently. lib is your 32-bit libraries, while lib64 is your 64-bit stuff.

On Windows, the 'normal' location is where you would find the 64-bit libraries, and the WoW64 stuff is loaded from a separate directory.

Implementation details: http://msdn.microsoft.com/library/default.asp?url= /library/en-us/win64/win64/wow64_implementation_de tails.asp

Select Quote:
The WOW64 emulator runs in user mode, provides an interface between the 32-bit version of Ntdll.dll and the kernel of the processor, and it intercepts kernel calls. The emulator consists of the following DLLs:
Wow64.dll provides the core emulation infrastructure and the thunks for the Ntoskrnl.exe entry-point functions.
Wow64Win.dll provides thunks for the Win32k.sys entry-point functions.
Wow64Cpu.dll provides x86 instruction emulation on Itanium processors. It executes mode-switch instructions on the processor. This DLL is not necessary for x64 processors because they execute x86-32 instructions at full clock speed.
Along with the 64-bit version of Ntdll.dll, these are the only 64-bit binaries that can be loaded into a 32-bit process.
At startup, Wow64.dll loads the x86 version of Ntdll.dll and runs its initialization code, which loads all necessary 32-bit DLLs. Almost all 32-bit DLLs are unmodified copies of 32-bit Windows binaries. However, some of these DLLs are written to behave differently on WOW64 than they do on 32-bit Windows, usually because they share memory with 64-bit system components. All user mode address space above the 32-bit limits (2 GB for most applications, 4 GB for applications marked with the IMAGE_FILE_LARGE_ADDRESS_AWARE flag in the image header) is reserved by the system.

It's a different methodolgy, but most likely one that works as well. I appreciate the Linux one better-- the "normal" 32-bit stuff lives in the "normal" places-- that way, you don't *need* an emulation layer for the 64-bit unaware apps. Rather, 64-bit aware apps know to look in the correct location for the libraries (well, they are told by the OS, anyways). The Linux Way (TM) is slightly more backward compatible, me thinks. You'll *never* experience a problem with a 32-bit app on a 64-bit linux system, while there are some bugs in WoW64 which will probably never be fixed, rather, they'll be 'phased out', in the usual MS fashion (ignored until irrelevant).

Information on the Linux approach is here: http://www.hp.com/workstations/pws/linux/faq.html
Mainly, when recompiling your apps to be native 64-bit, you need to observe the following:
Simple. Just rebuild from scratch and the compiler will build 64-bit by default. This is true for most apps. However, some apps must be made 64-bit clean which means that the developers must review the code to get rid of any assumptions about 32-bitness, such pointer arithmetic issues. Some makefiles that explicitly declare paths such as /lib, /usr/lib and /usr/X11R6/lib might need to be changed to append "64".