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

Comments

How can you compare if binaries not avail

[Anonymous Coward]

What is the point if the same tasks cant be carried out?

Re:How can you compare if binaries not avail

[areve]

Even if they were compiled properly you can't test the same programs. Eash OS will have pro's and cons. The benifit of these benchmarks could be finding those pro's and cons but most of the time these benchmarks set out to prove a point rather than to investigate the benifits of either system.

Re:How can you compare if binaries not avail

[Waffle Iron]

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 .

PCs have supported 64-bit and 80-bit floating point numbers since the early 1980s. You're talking about 64-bit integers, which are extremely rarely used in mainstream apps; I've probably used them less than a dozen times in 20 years of programming. Rendering and mathematical apps usually use floating point for any number where dynamic range would be an issue. Databases may use long integers, but I/O is probably a far greater bottleneck for a database server than long integer math. It takes orders of magnitude longer to read a long integer field out of the table than it does to add it, even if you split the addition into two 32-bit steps.

You also didn't mention that all of the larger 64-bit pointers come at a cost: increased pressure on your cache resources. This would tend to decrease performance unless you really need 64-bit addressing.

The main reason that AMDs chips are faster on desktop apps are more registers, faster memory controller, and cache architecture. None of those features has anything to do with 64-bitness.

Re:How can you compare if binaries not avail

[timeOday]

While I'm no fan of windows, much like others here, I do see the need to have a *fair* test

Comparing the software available for each platform is perfectly fair.

I can see it now:

"Boss, I think we should use a linux database because it's cheaper and faster."

MCSE: "No! It's not fair! Windows would be faster if only there were a 64 bit version available!"

Boo hoo. Compiling for different platforms is an obvious advantage of open source, there's no reason to rule it out.

Wow, without recompiling

[bustersnyvel]

And what about Gentoo? I think that this is the best distribution to run on a 64-bit processor. Perhaps the test needs to be reworded to "without any manual recompiling" and then redone. Compiling all your software yourself, optimized for your processor, gives you a great speed boost. I think this is one major advantage where Linux excels in comparison to Windows.

Re:Wow, without recompiling

[Anonymous Coward]

Surely the binaries will all be compiled for the lowest common denominator processor (like the way 32-bit x86 binaries are compiled for a 386), and since the lowest common denominator at the moment also happens to be the top of the range, recompiling for performance would be pretty pointless.

uhm, what's the point

[Vacuous]

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.

Re:uhm, what's the point

[Hoser McMoose]

I think that one of the most interesting things to come out of this article is that running 32-bit applications on a 64-bit OS is generally NOT slower than the 64-bit counterparts, or at least not by any significant amount.

This is significant because most applications out there are still 32-bit ones, so if you can upgrade to a 64-bit OS for one or two important 64-bit applications you don't need to worry about upgrading all your legacy 32-bit apps.

This is in stark contrast to Intel's IA-64 (Itanium) solution in which you take a BIG performance hit when running 32-bit code on a 64-bit OS vs. sticking with x86 hardware. This might seem like an obvious conclusion given that the AMD64 hardware fully supports 32-bit x86 code while IA-64 requires emulation to run 32-bit x86 code, however that point is likely to be lost on a lot of people who control the purse strings.

Okay, that review was kind of dumb

[Gregoyle]

That review was pretty dumb. Listen to this:

Since we are still testing out-of-the-box Operating Systems, we did not compile our own binaries for lame 3.96. Instead, we relied on the RPMs bundled with each operating system. For Windows, we went with Mitok compilation (which, sadly, has no 64-bit counterpart).

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:

Mental Ray is the crème of the crop as far as 3D rendering programs go. We only had access to a 32-bit version of the renderer for Linux and Windows, so we used that for this portion of the benchmark.

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.

Biased, as usual

[Anonymous Coward]

"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.

Re:They should have used Gentoo

[essreenim]

Exactly, the performance gains accrued in using Gentoo are negligible if not negative.

Gentoo's only real benefit performance wise would be VERY long distance brute force type work and even then: Whats the point depending on a single OS for that? Better to cluster a number of RPM based boxes together (as many as possible) and not worry about being confined to Gentoo alone.

Still though, Gentoo is a great distro (for its sowtware tools not hardware optimization) in its own right. But if you really want performance - better to have a floppy disk sized distro writen entirely in assembly with no GUI etc.. (that aint Gentoo)

Re:Windows XP 64-bit...

[sweede]

yes, there is a butt-loads of debugging symbols built into Windows Beta releases and no they are not stripped before shipment so they can have people use the system on the massive amounts of varrying hardware and crash windows so the MS team can debug them.

thats the whole point of the beta tests. You can not do that without the debug info, it is NOT stripped.

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.

about the author...

[MySt1k]

i was wondering why everything was boosted for linux without clearly stating that the binairies for windows was almost all only available in 32 bits versions.
many other good posts above explaine this very well.

maybe here is the answer.
Kristopher pioneered AnandTech's coverage in the Display and Optical Storage arenas and most recently has been commissioned to kick off coverage of hardware in the ever expanding Linux world. Using Linux as his primary work environment, Kris was the ideal candidate for AnandTech's endeavors into the Linux world. Kris leverages his vast experience with Linux as well as his hardware knowledge to fight for the Linux community, with the goal of improved hardware and driver support at the top of his priority list.

Have you been reading reviews lately?

[Kjella]

"We compare 18 different motherboards based on the same fucking chip, and there's a 3% difference from top to bottom. The top board $foo completely crushes the bottom board $bar"

Personally, I most care about features, like does it have a 100mbit or 1gbit network? There's a 10x difference, and it hardly gets noticed. But then they wouldn't have so much fun running benchmarks... compared to many other conclusions I've read, this one is far from out of the ordinary.

Kjella

Worst... Benchmark... Ever

[ThisIsFred]

This is the reason why I disregard most benchmarks. You might as well not even waste your time reading the article, because it is so skewed that it couldn't possibly be meaningful in the real world. To note:

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.

Basic Idea: "what should I do right now?"

[Featureless]

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.

Re:This Is Pointless

[fitten]

Funny... The only folks who I know who build everything from source (assuming when they use Linux) are people at home who are playing around or people who must compile on their own because support for something they use isn't in the normal distributions so they have to add it directly into the source themselves and create custom kernels and what-not.

In any case, in order for Linux to get beyond the "geek" realm, it must get to the point where the vast majority of folks can install and use it straight "out of the box" because the vast majority of the people in the world will have no desire to have to compile anything/everything (IMO).

Don't forget future-proof code....

[Kjella]

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

Flamebait

[charnov]

Wow...2001 called and wants its Intel fanboy humor back.

Seriously, it's the P4 that is the torch now as the Hammer based chips run 15 - 25 degrees celcius cooler. Wake up.