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."
http://www.extremetech.com/print_article2/0,1217,a =159811,00.asp
Printable Version
-theGreater.
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.
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.
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).
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...
The filesystem is the package manager
It was, it's called the 386.
However, there were many years between the release of the 32-bit capable 386 and the first mainstream 32bit operating system (Win95). About the same way as AMD64 was released before there was a usable 64-bit (Windows) OS to run on it, although the timespan is shorter this time.
wtf does 'source based' mean? all the stuff you get on a Fedora ISO was compiled at some point.. you just choose the right version (64 bit) and go on your way.
Means that you download and compile your software packages in-situ instead of waiting for your distro of choice to offer packages precompiled for 64-bits systems. Like the parent poster said, a lot of Linux distro don't offer 64-bit binaries (as of yet), but in a source based distro this is a non issue. Zealot my ass.
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.
Almost non-existent in 6, 7 (.Net 2002) and 7.1 (.Net 2003). We've switched some of our 64-bit test platforms at the office from using an SDK to using the beta of version 8 (VS 2005), which seems to be much better at targetting such a platform, but obviously it's unlikely you'll see the latest and greatest game today built with a compiler that's not due for release until 7 November...
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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 :)
Never eat more than you can lift -- Miss Piggy
Great post. Just a minor nitpick...Linux was released (albeit in a crude form) in 1991.
While the x86 ISA leaves you with hardly any registers, Intel and AMD's chips do register renaming to hundreds of hardware registers - register renaming is something that you do to allow you to have the same logical register in flight many times (it basically eliminates WAR and WAW register hazards, leaving just true communication). However, if the compiler doesn't have logical registers to allocate to variables, it has to spill them to the stack ... and since memory is not renamed, it really doesn't matter if you have powerful register renaming.
In reality, going from 7 to 16 GPR's is not nearly the win you might think it is, To get really excited you need to be talking about 32 or 64 registers. Sure, 32 register is definitely better, however ... going from 7 to 16 is a big deal. I've seen experiments (stuff that's not published yet, unfortunately) showing how the number of dynamic stores/loads decreases more sharply from 7 to 16 than from 16 to 32. Feel free to contradict me with some other study, though.
The Raven
[pedant] Actually, 128 bits can only address the number of atoms in about a billion (american) metric tons of hydrogen, about the weight of a cubic kilometer of water. (6.023 x 10^26 atoms per kilogram x 10^12 kilograms = 6.023 x 10^38 ~= 2^128). 256 bits could probably address every atom in the universe though. (2^256 ~= 10^77). [/pedant]
Interestingly, (to me, anyway), 64 bits can address almost the number of silicon atoms in a typical silicon chip.
This has always been true, but here are the problems:
To determine whether or not it's a pointer or a char string, you have to have some bit or set of bits dedicated to a switch.
Well you could say, dedicate the last byte to a true/false value. Then you can't address any memory that corresponds to a string at certain addresses. So if you pick 0x00 then you can't use low memory addresses. If you pick 0xFF you can't use high memory addresses.
If you use the first byte then you can't address any location in memory that, taken mod 256, will equal that value.
So it might seem simple enough but it requires a lot of knowledge about the system in order to make it work right. For example, can you guaruntee that every pointer will be even? If you can, then it's ok to simply declare a string-and-char-pointer-type with least significant bit to be 1 to designate a string within the object.
But can you guaruntee this? Universally? At runtime?
Well you might be able to do this, but can you do it easily? Cleanly? In multiple languages? Suddenly the simplicity becomes a little overwhelming.
Wrong. At least in Athlon 64, both cores have independent 512K or 1MB L2 caches, NOT SHARED. They do, however, share the 128-bit channel to memory.
I work with both dual processor and dual core Athlon 64 / Opteron systems and in terms of performance at the same clock speed and memory timing, there isn't much difference. If anything, the dual core is faster.
By the way, since when does a tight loop lock up a machine? That thread would have 100% CPU utilization, but you can certainly context switch to a higher or equal priority task. Maybe Windows doesn't work that way (?), but I've never had this problem on my Linux box.
Hmm... you're right, and I can't find much information about it.
s /index.xml?part=1&chap=2
;-)
Here's what Gentoo says about it, but there really isn't much detail:
Are 32bit applications supported? Is it through emulation or native?
Yes, 32bit applications are fully supported by the CPU, and are executed natively. A standard x86 OS can be installed on an amd64 processor, and can execute 32bit applications from a 64bit operating system if it is capable of mapping the 32bit syscalls to the kernel's 64bit interfaces (such as Linux is capable of doing if you enable it in the kernel). Please see the below section on 32bit support for further information. Please also note there is no performance penalty for running 32bit apps on an amd64 class processor, and will always be faster than the athlonxp line of processors running 32bit code (please note this is different than ia64 itanium processors!)
That's from here http://www.gentoo.org/proj/en/base/amd64/technote
I think if we want to know more about it we have to go stare at the kernel source, and I know that'll confuse me
I'm wondering how it compares in complexity to WoW64
WhiteWolf666 an exBush supporter. All you new-school,compassionate,save the children Republicans can rot in hell
That and that the AMD64s many many ass kicking improvements owe more than a passing glance to the Alpha, with a significant number of engineers fleeing DEC/Compaq/HP to avoid being layed off, or sold to intel for Itanic, moving to AMD, along with AMD licencing a number of KEY technologies off DEC/Compaq such as the Onboard Memory Controler bus technologies (why the AMD mobos have no southbridge) and the high performance scalability that your seeing in those 4-8 way Opteron Mobos cropping up (though i hasten to say that i dont think this was directly licenced, more, developed using the Licenced tech that came with the Southbridgeless designs and other ALpha based stuff by those DEC/Compaq engineers that moved to AMD)
XML - A clever joke would be here if
What really makes this 64-bit edition interesting, is the amount of RAM that is available for user. As you know, the 32-bit edition supports up to 4Gb which is not even nearly needful for most appliances, including hard 3D gaming, but may be insufficient (in some rare cases) for things like video and multimedia edit. Probably 128Gb, supported by 64-bit edition is a key feature for multimedia designers for making a switch decision.