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

[Psiren]

The AMD's can still run the 32 bit binaries. You'll just get the 64-bit goodness where available.

Re:How can you compare if binaries not avail

[NeoThermic]

Thats exactly what I was thinking.

While I'm no fan of windows, much like others here, I do see the need to have a *fair* test, and at *many* points through the tests, I saw this:

"Again, we had to use 32-bit binaries for the Win-64 beta"

"Unfortunately, there is only a 32-bit version of the game, so we must settle with 32-bit performance benchmarks, even on our 64-bit platforms."

"We noticed the Windows XP 64-bit MySQL running slower than its 32-bit counterpart; unfortunately, this is due to the lack of a 64-bit Windows binary - we had to test using a 32-bit binary on the 64-bit platform. "

Therefore, who is going to be surprised that the windows benchmark for 32 and 64 bit performance under such apps is going to be nearly exactly the same?

Oh, and one last part. The writer of the article doesn't quite get that 64bit binarys *should* be faster than 32bit ones, with this little gem:

"Here shows another case of 64-bit optimized binaries working faster than 32-bit binaries"

We shall be sending him his qualification in the bleeding obvious soon.

NeoThermic

Re:How can you compare if binaries not avail

[Anonymous Coward]

We shall be sending him his qualification in the bleeding obvious soon.

HHooww iiss iitt ""bblleeeeddiinngg oobbvviioouuss??""

DDoouubblliinngg tthhee wwoorrdd ssiizzee ddooeess nnoott aallwwaayyss mmaakkee tthhiinnggss ffaasstteerr.

Re:How can you compare if binaries not avail

[trashme]

While I'm no fan of windows, much like others here, I do see the need to have a *fair* test, and at *many* points through the tests, I saw this: "Again, we had to use 32-bit binaries for the Win-64 beta"

Maybe he was doing his best to test the different 64-bit operating system performance as it stands today. Part of the drawback of Windows is that right now it seems to be pretty hard to get your hands on 64-bit applications.

Oh, and one last part. The writer of the article doesn't quite get that 64bit binarys *should* be faster than 32bit ones, with this little gem:"Here shows another case of 64-bit optimized binaries working faster than 32-bit binaries"

Why?

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.

Re:How can you compare if binaries not avail

[NeoThermic]

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

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

[caswelmo]

You're right, that is OBVIOUS! Nope. Just poking fun, great summary post of the technology.

Re:How can you compare if binaries not avail

[Simon (S2)]

A 64-bit processor has an upper limit of about 18 million terabytes... (32-bit = 0.0043 terabytes... 64-bit = 18,000,000 terabytes)

I think 18,000,000 TB should be enough for anyone.

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

[menkhaura]

Just wait until the Windows following Longhorn is released...

Re:How can you compare if binaries not avail

[calc]

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.

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.

right

[muyuubyou]

UT2004 is a must in any server worth it's salt.

Re:right

[Anonymous Coward]

Why all the fuss over 64? Commodore64 had it years ago.

They should have used Gentoo

[Anonymous Coward]

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!

Re:They should have used Gentoo

[fireman sam]

You should have read the article...
"Unfortunately, we had difficulties running our new hardware platform on Gentoo and Debian"

Re:They should have used Gentoo

[Tet]

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.

Really? Explain to me how an app compiled for x86_64 under Gentoo will be so much faster than the same app compiled for x86_64 under Fedora or SuSE.

Re:They should have used Gentoo

[molarmass192]

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.

You mean like SuSE 9.1 64-bit edition that comes fully optimized and ready to run on a single DVD? Look, not to be a dick or anything, but Gentoo is in no way the "only sane" option for getting the most from your hardware. Yeah, it's far more oriented towrds optimizing for hardware than any other distro, but for me "sanity" means pop a DVD in, install, configure, and get to leave in under 60 minutes. That doesn't mean Gentoo is bad, it's a fun hacking distro and you can learn a hell of a lot more from using it than any binary distro, but it's certainly not a PHB compatible distro.

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:They should have used Gentoo

[gmuslera]

They don't even did the minimal recompilation to make the NVidia kernel module to work, because one of the objectives of the test were no compilation required. Gentoo, almost by definition, is all about compilation, so is out of the reach of this comparation.

But if things can be compiled probably those benchmarks will improve, and maybe even could have better results with Gentoo.

Re:They should have used Gentoo

[e40]

No, SuSE is the best AMD64 Linux. Why? Because of Andi Kleen. He's a linux kernel developer primarily focused on AMD64 and he works at SuSE. The Redhat distribution that came out before SuSE's doesn't run some IA32 binaries (my company's, for one), because, IMO, they didn't know what they were doing. SuSE waited until it was ready. Andi contributes lots of AMD64-specific fixes to the 2.6.x releases (according to the changelog's I read).

AMD64 is a new platform, and Andi is a really good developer. He's also been very helpful to a developer I work with, exchanging emails on AMD64 details for our compiler. I'm staying with SuSE for this reason.

Note that PostgreSQL has also been optimized...

[tcopeland]

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

Apparently the poster didn't RTFA.

[BoomerSooner]

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.

Why?

[wongn]

What factor of raw "speed" faster would a 64bit processor be over a standard 32bit processor of the same clock-speed. Do you think that is is currently economically viable for any purchases at all to be made of 64 bit computers other than for the stasis that comes with it: "I've got a 64 bit computer, ner :P"

Re:Why?

[r00t]

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.

Re:Why?

[TheRaven64]

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.

Re:Why?

[milgr]

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.

Re:Why?

[Frit Mock]

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

Re:Why?

[unapersson]

You're missing out all the extra registers. That alone would give a speed boost.

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

That's because people were idiots. The Dreamcast wasn't 128-bit, the Jaguar wasn't 64-bit. It was just marketing.

Speed Is Relative

[rute_1]

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

Re:Speed Is Relative

[Zzootnik]

Kinda like "The Racing Stripes make it go faster!" ?

Re:Speed Is Relative

[Pharmboy]

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.

Better article

[ValourX]

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

Windows XP 64-bit...

[Jugalator]

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.

Re:Windows XP 64-bit...

[kmmatthews]

The debug info is stripped.

Besides, they're not using an optimized linux system, so...............

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.

Re:Wow, without recompiling

[Scarblac]

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.

Re:Windows? 64-bit?

[chrismcdirty]

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.

Re:Windows? 64-bit?

[leperkuhn]

Linux runs on the PowerPC too.

Re:Windows? 64-bit?

[cozziewozzie]

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.

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

[Illissius]

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

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.

But are they comparing

[lachlan76]

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.

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.

Rethink that Rendering Assessment

[Bob(TM)]

Um, *reading* the article shows Linux slugging out pretty well compared to Windows WRT rendering.

Benchmark render times - less is better. Times are shown as 64 bit (32 bit)

Mental Ray 3.3.1 (32 bit app *only*):

Windows: 91.97s (92.08s)
SUSE: 85.29s (86.73s)
FC2: 84.15s (85.88s)

Looks like Linux slugs it out with XP pretty well here.

POV-Ray (32 bit app for Windows only):

Windows: 1589s (1592s)
SUSE: 1399s (1762s)
FC2: 1700s (1864s)

Little apples and oranges mix here - you've got a Linux boost in 64 bit but the comparison breaks because XP is using a 32 bit binary. Windows hangs on here.

SUSE is free

[houghi]

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.

Re:SUSE is free

[Buelldozer]

You can now download an ISO image of Suse 9.1 Pro, yes I said an ISO. No, I did not confuse that with "Live CD".

It is free, go look. :-)

Re:SUSE is free

[Sunspire]

Well, they've managed to hide it pretty good in this case as I could not locate any such thing. Mind pointing it out to me exactly where I could download ISOs of 9.1 Pro?

The closest thing I could find was the single-disc 9.1 Personal which contains about 1/4'th of the software in the Pro version. It's useless to me as it doesn't include any development tools, and I need something to build SuSE RPM packages of my programs with.

Linux on the Playstation "Cell" processor

[sleepingsquirrel]

As long as long as we're talking about linux under other architectures, I wonder what others think of these Linux Insider editorials speculating about running Linux on the 'Cell' processor for the next Sony Playstation. The bold prediction? "the Linux developer community will, virtually en masse, abandon the x86 in favor of the new machine."

RTFA

[13Echo]

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

This is an interesting quote, considering that Suse 64 beats WindowsXP 64 at PovRay rendering. FC2 beats Windows in 64 and 32 bit mode for Mental Ray rendering.

So, saying "Windows wins some (rendering..." is pretty subjective. Fedora is slower as is, in most cases, compared to Suse, as shown by the benchmarks (not surprising for Fedora). I find it strange that ET is slower on Linux than Windows, since most Q3 engine games are faster on Linux than Windows. Must have something to do with the way ET was specifically built or the nature of the OpenGL 32 bit code in the Linux nVidia 64 bit drivers.

Regardless, it still looks like Windows still isn't viable as a 64 bit OS. Given that Linux has better compilers for 64 bit code, more software that can take advantage of 64 bit (by nature of the the fact that most of it is free/opensource), and better 64 bit support in general, I think that it really shows that it is probably the best option for 64 bit at the moment. It could take *years* before most Windows software gets 64 bit variants. With Linux, it's all here now, aside from the handful of proprietary programs that many people don't run anyway. And since nVidia's 64 bit Linux drivers are still pretty immature (they only added 32 bit OpenGL support in June, in spite of it being a more capable 64 bit platform than Windows XP at the moment), expect some major gains in performance in the coming months, for the handful of games that you can play on Linux.

Re:I think we all know

[Tobias Luetke]

Think about gentoo what you want, i think the parent is rather insightful than funny. This is preciecly the enviroment where gentoo comes in its own.

As the poster...

[Illissius]

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.

64-bit nVidia drivers under FC2

[Brian Stretch]

For 64-bit Fedora Core 2, we were not able to install NVIDIA's graphics driver with the default kernel. Thus, their 64-bit tests must be omitted from the benchmark.

If you install the updated FC2 kernel (any of them from the past month or two), nVidia's new 64-bit drivers install without trouble. I've been playing 64-bit UT2004 and tested 32-bit Wolfenstein:ET on my Athlon 64 3200+ box w/BFG GeForceFX 5900XTOC and suffice it to say that nVidia has done an OUTSTANDING job on their new drivers. I can't compare the 64-bit Linux version of UT2004 to the Windows version because I wiped Windows XP from the machine. If games don't run under Linux, well, I shouldn't waste time playing them anyhow. (I trust that Doom 3 will have a 64-bit Linux build?)

Re:Wow, without recompiling

[Too Much Noise]

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.

Re:How does that correlate to Opterons?

[Illissius]

Not considering possible discrepancies with SMP performance, the relative performance with Athlon 64s and Opterons should be exactly the same, as the architectural differences are minor - the Opteron has more cache and uses registered ECC memory. There's also a variant of Athlon 64s which only have single channel memory (socket 754), but again, all of these are for the most part minor 1-2% performance differences and shouldn't affect the big picture.
As for SuSE vs. Fedora, do note that they didn't actually recompile anything, which could change the picture significantly.

Re:performance boost?

[mangu]

is there an overall performance boost (not platform specific) to a 64 bit architecture?

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.

For anyone complaining about testing more OSes...

[Illissius]

And judging from the amount of replies to the parent, there's a lot of you, here's an interesting bit from the end of the article:

Eventually, we anticipate adding more operating systems to our mini-breakdown, perhaps including BSD distributions and Mandrake, Gentoo and maybe even an AT-optimized mini-distro.

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.

Pathscale compilers would be interesting...

[coats]

The PathScale folks (who started out as a spin-off from Cray's compiler group) worked extensively with AMD to construct "state-of-the-art" C and Fortran compilers for AMD64. See http://www.pathscale.com/index.html

Since the code for these benchmarks is available, it would have been really interesting (for me--as a developer/environmental modeler who compiles his own codes) to see what performance boost these compilers would have given (as compared with default "gcc" builds)... A lot more work, I'll admit.

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

Re:Nope, you're wrong

[Nasarius]

Actually it's not. Because if the app has not been tested to compile and run cleanly in a 64-bit LP64 environment then you will have no end of problems.

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.

The largest deployed 64bit OS is OS X

[mrnick]

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

nVidia drivers updated

[DeathPenguin]

It might worth noting that the nVidia drivers used in the Anandtech benchmark are from January. nVidia released new 6xxx drivers for both IA32 and AMD64 on June 30.

32-bit is not emulated on amd64

[xswl0931]

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.

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.

Re:windows not ready for prime time

[Trailwalker]

I recently installed Win64 on a box with an AMD64 3800+.

"Not really usable." is far kinder than my opinion.

I am trying to think of someone I dislike enough to give the Win64 install disk.

64 bit FedoraCore2 was a relatively painless install and execpt for the sound card, worked rather nicely.