Slashdot Mirror
AMD64 Windows vs. Fedora vs. SuSE benchmarks
Illissius writes "AnandTech just posted a review comparing 32- and 64-bit performance on both Linux and Windows. They focused on what is available out of the box without having to compile anything seperately - unfortunately, 64-bit binaries weren't available for most of the Windows benchmarks. To save people the pain of RTFA, there's a very tangible gain moving to 64-bitness, Linux wins some (MySQL, UT2004), and Windows wins some (rendering, RtCW)."
...to work with AMD's 64 bit Opteron. And that was last November, so I daresay it's even better now... check it out here.
PLUG: Good tools, too!
The Army reading list
Although we primarily focused on comparing SuSE, Fedora and Windows in this article, we did not include dozens of other 64-bit distributions available today. Given just the three operating systems analyzed before, SuSE comes out ahead of Fedora consistently - but more importantly, both Linux distributions also lay waste to the 64-bit and 32-bit editions of Windows XP. In fact, the only real benchmarks where Windows ever came against either Linux distribution were the game tests. Fortunately, the point of this analysis was to see if Linux takes advantage of the 64-bit gap; and with reasonable assurance, we can conclude it does. Encoding, database and rendering tests all show a distinct advantage with a 64-bit operating system over a 32-bit one, and even more distinct advantage with Linux over Windows.
The AMD's can still run the 32 bit binaries. You'll just get the 64-bit goodness where available.
Is it just me or did AnandTech stuff the key on the graph up? It says blue for 32-bit, and red for 64, but most charts show red underperforming blue, and the article text says it should be the other way round.
========
CINC, 4th Penguin Legion
I did a 64/32-bit comparison on FreeBSD a while ago, and then did some comparisons in SuSE 9.1.
I haven't gotten around to 3D benchmarking yet, but soon...
-Jem
They tried Gentoo, and couldn't get it to work (of course I didn't read the article either, but some other reply says they did :-)).
A friend of mine also recently reported he had problems getting Gentoo to work on an Athlon 64, getting a segmentation fault during a compile in the first big emerge. Unfortunately I don't know any more details, but it does seem there may be some gotchas.
I believe posters are recognized by their sig. So I made one.
I wouldn't say it would be fair. Linux and Windows are running on the same hardware. This is a test to see whose OS is taking better advantage of the AMD64 processors. Seeing as the Apples use a PowerPC processor, it would be completely different testing procedure.
It's like sex, except I'm having it!
Linux runs on the PowerPC too.
http://www.rustyrazorblade.com
Linux runs on more than just Intel/AMD processors. It runs happily on PowerPC and, in fact, uses the same compiler as OS X (GCC). A comparison would definitely make sense.
Besides, they're not using an optimized linux system, so...............
feh. stuff.
It's not so much the 64-bit ability, though that is
nice for dealing with the occasional 64-bit value
and nice for dealing with over 896 MB of memory.
It's the other stuff you get.
With the AMD64 Opteron, you get double the number
of registers. You get a modern calling convention.
You get a 128-bit memory bus directly connected to
the processor, without a north bridge chip in the
middle. You get a good clock speed.
With the Mac G5 (an IBM chip), you get IBM's
ass-kicking FPU in a very well-made system.
(this is what Linus Torvalds uses)
The speed difference is noticable.
There won't be any specific gain from going from 32-bit to 64-bit, the only thing that you get offhand is the ability to work with bigger numbers. This has two main benefits: (1) the ability to address more RAM and (2) in any software written for a 32-bit chip, you can eliminate doubles and use standard int data types. This will provide some measure of speed up, but not a whole lot.
That's always been a problem with "bits" as far as I'm concerned. People used to say "man Atari Jaguar is 64-bit. It should destroy Playstation since it's only 32-bit". That makes no difference. Dreamcast was 128-bit and X-box is 32-bit. Guess which ones faster.
64-Bit Programs, as well as a 64-Bit OS? There is no advantage to running a 32-Bit program on a 64-Bit OS if the software can't take advantage of the extra features. That's why you have to recompile. A 32-Bit program will run slower on a 64-Bit OS because it has to emulate 32-Bit hardware, but native 64-Bit will run much faster.
On a sane architecture, such as SPARC or PowerPC, you would be right. There is no advantage (and occasionally a penalty) in running 64-bit programs which use less than 4GB of address space. On x86 / AMD64, however, you gain an additional advantage when running in 64-bit mode - more registers. This gives a significant performance gain when software is compiler to take advantage of it.
I am TheRaven on Soylent News
64 bits should show improvements over 32 bits in two areas: high precision math, and large address spaces. Large databases like to use lots of memory.
Under 32 bit linux, there are a couple of ways that memory may be split between kernel and user: 1:3 (one GB kernel, 3 GB user space); 2:2 (2GB addressible for each); 3:1 (3GB for the kernel, 1 for user space); 4:4 - each has 4GB addressible, but there is a significant performance penalties for system calls.
It is possible to use more than 8GB RAM in a 32bit Linux system because different users will access different portions of virtual memory.
For 64bit systems, the kernel could be configured to use 4GB RAM, and users could use over 4GB RAM without kluges to the OS. So there is a good use for 64bit systems.
I think 64bit systems are useful for certain applications. On the other hand, most individuals don't need 64bit systems.
Where law ends, tyranny begins -- William Pitt
Unfortunately, you can't even try the Personal version of SuSE 9.1 without forking the $90
The FTP instalation, wich is almost the same as the pro is available for free. mirrors are here Naturaly also the X86_64 is available on several mirrors.
Don't fight for your country, if your country does not fight for you.
Yeah, but you get double the bits (32 -> 64)
I hate to break this to you, but technically, 33 bit is double 32 bits. Each bit you add doubles the amount of data, regardless of how many you start with. 8 bits has 256 possibilities, 9 has 512, 10 has 1024, 11 has 2048, etc. Thats kinda how binary works.
64 is rather larger than twice, which is both good and bad, depending on whether you need to drag around all those extra bits for nothing.
Since then, the progress has slowed down. I mean, Pentium3 -> Pentium4 was only a 33% improvement
For tasks other than multimedia, the P4 was actually SLOWER than the P3, per clock tick. The P3 design had hit the ceiling for speed, so the P4 was a redesign that was optimized for desktop stuff, like video, etc. But for most raw cranking tasks, it was slower than the P3, relatively. Oh yea, and you can run P3s in Dual CPU systems, another plus. The Centrino chip, on the other hand, is closer to the P3 in performance (work done) per clock tick.
Tequila: It's not just for breakfast anymore!
"Clearly, 64 bits would be twice as fast as 32 bits."
Not realy, there are quite a lot of operations, where 32 bits are just enough, sometimes 32 bit even more than neccesary. In these cases 64 bit can't be any faster. (Even more, in such cases you just spend more RAM and with the same amount of RAM you could in some corner cases even notice a performance loss with a 64 bit CPU.)
If you are refering to the "bottleneck" of transfering data from RAM into CPU (more precisely into L2 cache then into L1 cache and after that into CPU) you are not right either, since a 32 bit CPU processes data in 32 bit units, but this does not neccessarily mean that data moves in 32 bit units into the CPU.
There won't be any real performance increase, unless you realy need to prcess data in units larger than 32 bits.
For example comparing two large strings should be twice as fast, but comparing two single characters or (byte encoded) IP's won't be any faster.
I do not expect 64 bit CPU's to be twice as fast, on avaerage I would expect them to be 10%-50% faster.
I would suggest that you have not read the article yourself, and have merely skipped to the conclusion (which is rather an odd one, seeing as it does not quite reflect the benchmarks - they actually split both the gaming and rendering).
Take a look at, for example, this benchmark, where Windows outright beats Fedora at both 32- and 64-bit, and only loses to 64-bit SuSE slightly because it doesn't have a 64-bit binary itself, and this one, where Windows just plain wins.
I did mess up on the "Windows wins at rendering" part, though, sorry for that - they split it actually. I didn't notice the "lower is better" part on the Mental Ray bench and just went with the one that had longer bars. Oops.
Work is punishment for failing to procrastinate effectively.
HHooww iiss iitt ""bblleeeeddiinngg oobbvviioouuss??""
DDoouubblliinngg tthhee wwoorrdd ssiizzee ddooeess nnoott aallwwaayyss mmaakkee tthhiinnggss ffaasstteerr.
If you had specific problems, file bugs. If it's just hearsay, don't bother posting it next time. 2004.0 works correctly on a lot of AMD64 hw - look only at how active the amd64 tree is, you think they're running it on emulators?
For me, at least, AMD64 Gentoo is quite usable, thank you. Even with nvidia drivers out of the box.
But if things can be compiled probably those benchmarks will improve, and maybe even could have better results with Gentoo.
By itself, 64 bits will only be an advantage when you have large databases, with several billion records in a table. For "common" users, 64 bits is more marketing hype than anything.
Usually, when one has more than 32 significant bits in a number, programmers shift to floating point. Floating point processors have had 80-bit registers since the 8087 came out in the late 1970's.
However, if the architecture is different, you may get a gain from other factors. For instance, the AMD64 CPU's have more general-purpose registers than Pentium 4's, and you may gain some performance improvement from this fact. But this has nothing to do with the 32/64 bits question, you could have a 32-bit CPU with more registers and get the same performance gain.
Sorry but the rendering we do here on AMD64 with recompiled blender and Povray (and yafray) is MUCH faster than the marks they show. even with scenes that are more comkplex.
povray has a 64bit ready version that when compiled yourself on your target platform absolutely screams.
blender is next on getting changed to support 64 bit.
Work is punishment for failing to procrastinate effectively.
The point of it is to see how much performance improvement is to be seen moving from 32-bit to 64-bit with x86-64 optimizations (more registers, and the like). I can count the number of reviews on the subject on one hand, and don't need any hands for the number of them with any relevance whatsoever - they all used 32 bit binaries on 64 bit Windows. Which is why people have been asking for Linux benchmarks since, err, a long time ago.
The fact that you get to compare Linux and Windows while doing it is more of an afterthought (I only worded the submission the way I did because a more descriptive one wouldn't fit the character limit).
Work is punishment for failing to procrastinate effectively.
Why is it so obvious 64-bit is faster than 32-bit? Just because the word size is doubled? For many applications that doesn't help at all. FYI, one of the big advantages of the amd64 instruction set is a larger (than ia32) set of registers for the compiler to work with. That is where the speed boost is most likely coming from. Only certain applications truly benefit from a 64-bit word size.
>>HHooww iiss iitt ""bblleeeeddiinngg oobbvviioouuss??""
.
:)
I'ld check the repeate rate on that keyboard. Seems a bit out of sync if you ask me.
In all seriousness, 64-bit computing by itself means that the General Purpose Registers are 64-bits wide. That means increased dynamic range. Using base 2, a 32-bit processor gives you 4,294,967,296 possible values. (which is where the 4 GB RAM limit of 32-bit processors comes from.) That is it's dynamic range.
A 64-bit processor's dynamic range is approximately 4.3 billion times greater than a 32-bit processor, which simply means, it can work with much larger numbers. Thats Important in applications like rendering, mathmatical calculations, and even database servers
64-bit computing also allows for more RAM than a 32-bit processor because of it's increased dynamic range. As shown, a 32-bit processor can only handle about 4.3 billion values, which roughly works out to about 4 GB of memory. A 64-bit processor has an upper limit of about 18 million terabytes... (32-bit = 0.0043 terabytes... 64-bit = 18,000,000 terabytes), something that I don't see anyone quite needing, but it does mean that your 64bits will go further
AMD changed some more things when they designed the Athlon-64.
To start with they used a 40-bit memory address rather than 64-bit since we're not going to need 18 million terabytes of memory anytime soon. Therefore a 40-bit address allows up to 1 terabyte of memory. Thats enough, considering that you won't find a motherboard with support for 1024 sticks of 1GB ram anytime soon.
Then they doubled the amount of General Purpose Registers so there is now 16. So not only have we doubled the number of addresses, we then make them twice as big again. But they can only be used by 64-bit software, so the benefit of extra registers isn't realized with 32-bit software, which is my point. A 32bit app isn't going to excell on a 64bit processor, hence why benching it isn't fair.
After that they lengthened the pipeline by a few stages. In short, you basically make it so higher clock speeds are easier to reach without having to change the format of the processor.
AMD have also built the memory controller into the core, which eliminates almost all latency issues from the CPU to the memory controller. Basically the memory is now just connected to the CPU by wires, whereas the CPU was connected to the northbridge, and so was the RAM. So the northbridge sat between the RAM and the CPU.
Then you have added support for SSE2, so applications designed to take advantage of Intel's SSE2 instructions can now also take advantage of those instructions on an Athlon-64. So now Intel isn't holding the upper hand again.
Finally they are using SOI, which in short, reduces current leakage within the processor, making switching of the transistors more efficent, which means faster speeds and less power consumption.
They've made other changes as well, quite alot more than listed here, but those are the main ones that effect performance.
NeoThermic
Use my link above, or to view my server, NeoThermic.com
Yeah, but even with that 80-bit floating point register, you can only carry around 17 or 18 significant figures (varies with math libraries). And after crunching a bunch of doubles through a lot of multiplication and division to get your end result, you could (your mileage may vary) only be good to three or four decimal places in accuracy in the end. Here is where a 64-bit system can help. So scientific applications can benefit too.
There are a ton of people running amd64 on Gentoo, and at this point, the problems are fairly minor. Check out the forums and Bugzilla.
LOAD "SIG",8,1
I quote from the article:
"This was thoroughly discouraging; no out-of-the-box NVIDIA support for the largest (or at least second largest) 64-bit operating system."
The Power Mac G5 is 64-bit and ships with NVIDIA cards. This would make Mac OS X the largest 64-bit operating system.
I know this review was on AMD but at least qualify a statement when it is so alarmingly wrong.
Nick Powers
P.s.
Watch out Microsoft, Apple is coming
Encryption: I may not agree with what you say, but I will defend your right to encrypt it...
The checked beta build has full debugging info.
A beta version of windows with the debugging tools built into the OS is no where close to the same level as an "un-optimized" linux system.
Debugging tools built into the OS? Uhh.. Task manager and perfmon.. are not debugging tools.
feh. stuff.
The point of AMD64 vs say Itanium is that 32-bit apps run natively on AMD64, they are not emulated, unlike the Itanium. On Windows, there is a small cost of thunking between 32-bit and 64-bit, but these benchmarks indicate that in many cases, the 32-bit app runs "better" on the 64-bit OS due to 64-bit drivers.
I think a slightly bigger issue is the difference in cost between an amd64 and ia64 chip. The ia64 chips 4 years after release are still over $1300/each for a low end model while there are amd64 chips that are already down to $170/each.
Another issue is that the ia64 runs (or did) a lot hotter than amd64 and the chip itself is also much larger so you wouldn't find them in laptops. There are already 35W laptop versions of the Athlon64. Lower power chips also are very useful in large datacenters due to not needing nearly as much air conditioning.