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)."
What is the point if the same tasks cant be carried out?
UT2004 is a must in any server worth it's salt.
As a Gentoo user what really stands out to me is that this test was clearly biased away from Linux. If the reviewers had been serious they would have used an optimised distributions such as Gentoo, which would have taken far fuller advantage of the extra 32bits in each register to provide a much fuller experience, more than any current Linux distribution possibly could.
It really saddens me to see that people go out of their way to spend so much money on such expensive hardware and then squander their investment by running barely suitable software on it. To me, an extra 0.1% performance increase, even if I am only imagining it to be faster, is certainly worth one day a week recompiling all of the latest packages from source code. Even if I do occasionally get my CFLAGS in a muddle!
I think I speak for Slashdot when I say that Gentoo is the only sane option for getting the most from your hardware!
...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.
Just the fact that you're running a 64 bit system gives you the sense that everything is faster.
Besides, 64 being twice 32 justifies the upgrade cost...
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
Wouldn't that still contain a lot of debug code slowing things down, making it unfair in a comparison like this? Interesting to see the beta is even faster than the Linux distros in some cases though.
Beware: In C++, your friends can see your privates!
They are using a 64-bit processor, on 64-bit enabled Operating systems, and benchmarking using 32-bit code, which in most cases is going to be slower on the 64-bit platform. On top of that, they aren't even using any of the 64-bit memory addressing so what is the freaking point of any of it. On top of that they are benchmarking in incomplete version of Windows, which a previous poster pointed out probably still has a bunch of debuig code/optimizing to be done.
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.
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
They then go on to chart Windows performance in 32 AND 64 bit! They just told us that there was no windows 64 bit software! Also, the whole "out of the box" thing strikes me as just a tad bit lazy, being that this is an experimental platform on windows and a young one on linux. They do it again here:
Gee, I wonder why the results are almost exactly the same?? Could it be because you used the exact same software on each platform?
They do this again for UT2K4 and a couple other pieces of software. I understand that the 32 bit versions of the software were running on 64 bit versions of the OS, but do you really think that makes much difference? That seems like only question the article seems to asnwer here; the answer is no, it doesn't seem to make one fig of difference.
Interestingly enough, there are many places where the 32 bit versions outshine the 64 bit ones. I wonder if that's due to poor optimization, or if it really means the 64 bit is overrated and only has an advantage due to increased memory addressing. I'd like to see benchmarks on software people think would benifit by using 64 bit.
I'd also like to see them do these benchmarks again, this time being less lazy and compiling 64 bit versions of the software used on each plaform. And if you can't find 64 bit software on one of the platforms, don't do tests in that software and find something that does have 64 bit to compare.
"He's more machine now than man, twisted and evil."
"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"
Huh? This was in the conclusion of the article. Close results, but I wouldn't call it "laying waste" to anything.
And maybe I'm dumb or just a fanboy, but weren't they using 32 bit binaries on alot of the Windows tests? With Linux programs that had been ported to Windows, not vice-versa? I don't know much, but I know that most ports are certainly not uniformly well writen accross platforms, especially when done by other developers or as an afterthought. Not to mention this was all on a beta version of Windows?
Just some things to think about. Not that many think on their own here.
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.
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.
MPlayer for Windows is built with MinGW32. That's a big minus for Windows, and most of us that have compared compilers know that VC++ produces faster code. Chances are that mencoder doesn't prefer Microsoft's functions over standard ones, for portability reasons. The benchmark would have been fair if the respective platforms used whichever encoder is considered the best.
The above applies for LAME. I also didn't see assembler optimizations mentioned, which is a feature that makes LAME so much faster than all the other audio encoders out there. But does that even work for 64-bit code?
You can toss the rendering comparisions out as well. 32-bit versions were compared. Why even include it?
Likewise with the game benchmarks. Of course Linux wins with the Unreal engine, because it's using the more efficient OpenGL renderer. Windows does not have this choice.
There was no 64-bit Windows version of MySQL, yet they included the benchmark anyway. Amazing.
Considering all the problems Anandtech had with 1) finding the right programs for 64-bit Windows, and 2) getting 64-bit drivers to work with the Linux kernel, they should have just said, "we couldn't complete the benchmark because third-party developers' software is not yet mature enough.
Fred
"A fool and his freedom are soon parted"
-RMS
It's a pragmatic test. Should I go to 64-bit yet? If I do, what OS should I run? What applications are ready?
And the answer is, not surprisingly, go with an operating system where the sources are almost always open or at least generally available, so the migration to 64-bit will be vastly faster and better.
Want to Know How to Cheat the GPL? Read On!
By itself, 64 bits will only be an advantage when you have large databases, with several billion records in a table. (...) Usually, when one has more than 32 significant bits in a number, programmers shift to floating point.
Actually, I've been using a lot of (ok, some) 64 bit numbers in my programming recently. Why? Files over 4gb. Timestamps that should span more than 2^32 seconds. Calculations that could, if using extremely large numbers, pass 2^32. Yes, it will probably be overkill for 99,99% of the files, times and calculations that it handles. So what? The day you want to handle a DVD image, it will be far more annoying than the 4 bytes I skimped on when doing sizes and offsets.
The difference between 32 and 64 bits is not significant anywhere but in the CPU. It is not significant on the hard disk, in memory or even over the network/Internet. So being able to do 0x0000000000000002 + 0x0000000000000002 = 0x0000000000000004 as easily as 0x00000002 + 0x00000002 = 0x00000004 has value in my opinion, no matter how few the significant bits...
Kjella
Live today, because you never know what tomorrow brings