Slashdot Mirror
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."
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.
English is easier said than done.
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.
Arguably, though, you'd see much more of a performance gap if the applications were better designed to take advantage of the 64 bit power of the processor. That means not just a recompile as a 64 bit application, but having the app actually use 64 bit numbers whenever possible.
It's a bit like the jump to 32bit. When all we had was 16bit software to test, the performance numbers tended to be equal. Once the software started showing up that was written for 64bit processing, we started seeing a major performance gap.
Javascript + Nintendo DSi = DSiCade
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)
I think most people hailing 64 bit computing are missing the obvous. You'll need a little more RAM to run equalivent to 32 bits. That's because pointers are platform dependant and on a 32 bit machine they are 32 bits long, and 64 bits on x86-64.
Not that RAM isn't cheap enough today, but when you draw the line, 64 bits doesn't bring anything better to the table if we count out larger address space. Not _really_ worth switching if you don't need that extra RAM (and I doubt most of you do).
That's largely due to the fact that when the 32-bit OS shift happened, most people already had 32-bit processors in their systems.
I'd expect much the same thing to happen here. Microsoft will wait for proliferation of AMD64/EM64T chips before they make a strong push to 64-bit Windows. I'm actually surprised they've released it at all, personally...
--S
-- sigs cause cancer.
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.
You are right on both counts, but the latter is not as big of an issue as RISC advocates would like you to believe. x86 processors since the Pentium Pro (hazy, but maybe the Pentium) have used register renaming, whereby the internal micro-op execution core of the processor has many, many more registers than the IA32 ISA (like 32/64/128 vs. 8).
The greatest speed increase will not come from the number of registers, per se, but rather the compiler's ability to explicitly access those registers. There is only so much a processor can know about a code path prior to execution, and even if it does know as much as we can possibly tell it beforehand, there is no guarantee that two code paths will ever be identical. But a compiler can be much more creative about its knowledge of a given code path and can instead optimize for 16 instead of 8 general purpose registers in addition to making the __fastcall calling convention the ABI's default.
I guess my point is that yes, the number of externally addressable registers is important, but only if a compiler can really make intelligent use of it. Simply using 16 instead of 8 will not get you nearly as much of a speed increase because of the large internal register windows of modern x86(-64) processors. I think you'd be surprised just how optimized that register window is. The speed impact is not zero, but it's nearly imperceptible in most instances. You're much more likely to see a huge imporovement on a given algorithm if all of its instructions and data (and output if it uses it's output for further input) can reside in the on-die cache than anything to do with the number of registers. If that were the case, then we should see a tremendous speed increase just from moving applications to 64-bit. Right now, either due to the compilers not being quite up to snuff or due to the increased memory footprint of 64-bit code, this is simply not the case. Real world ranges from a hit of 10-15% to an increase of 5-10%. Some apps do benefit substantially more, but they are definitely the exception.
DEC Alpha's in the mid 90's were 64bit and Linux went through a fairly large push to clean everything up to work with them.
I think that's one of the reasons why everything works so well with AMD64 today under Linux.
Dual core and dual processor aren't really all that different. The main difference is that dual core has two CPUs on the same die and therefore has shorter distances to travel to the shared memory cache(s). Yes, there's additional glue and such (stuff like shared registers and even some pipeline chunks), but nothing that's a huge fundamental difference.
For that matter, dual core processors often report as two separate processors, which potentially would cause Windows user license violations if you used a dual, dual-core setup. I believe Microsoft has found a way to identify dual-core CPUs before this even became an issue, so a 2x2 should be fine, but it was an issue.
As for the performance numbers for games, I'm not entirely surprised... maybe if games threaded themselves better, but most of the time they don't and that is a waste of an extra CPU (well, ok, some compilers may optimize the code for two CPU use, but I don't think they help much, yet). I would expect performance to be optimal in stuff with lots of independent threads like Web Servers (which usually have many processes running many threads) that don't depend on other hardware (like games, which also are throttled by the GPU).
64 bit is useful when you want to manipulate 8 megapixel movies in floating point RGB. 64 bit addressing allows those to be manipulated entirely in RAM with no tiling. The improvement is huge and the money saved on tiling engines can be spent on image manipulation.
I'd recommed getting him a computer that actually works.
THIS IS THE INTERNET. PLEASE PICK UP YOUR SERIOUS BUSINESS SUIT AT THE FRONT COUNTER.
Terrible summary of a meaningless article