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

so ?

[Anonymous Coward]

Windows = Desktop and Linux = System ?
How new !

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

[ViolentGreen]

But the 64-bit OS is not available. It's not a fair comparison.

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

[Anonymous Coward]

That's irrelevent. If you are choosing between Windows and Linux for your next 64-bit computers purchase, the fact that Windows might theoretically perform better with appropriate binaries is completely useless if you want to actually do work with the computers instead of wank about how fast they might be with non-existent 64-bit binaries.

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

[Anonymous Coward]

> bleeding obvious

In a later post you spend about 5 paragraphs explaining why it is "bleeding obvious". I'll
ignore all of that post BECAUSE while it is a great summary, it does NOTHING to explain why it is
"bleeding obvious" that 64-bit binaries should work faster than 32-bit binaries.

Let me explain: it is NOT "bleeding obvious". In fact there is no technical reason an arbitrary* 64-bit binary should be faster than a 32-bit one.

HOWEVER - the amd64 platform incorporates more than just extended word length, as you spend about 5 paragraphs later explaining.

In the future, please stick to calling things "bleeding obvious" only if they are.

* By arbitrary, I mean a randomly sampled one. If the data does not benefit from the extended word length, there is no gain.

Re:How can you compare if binaries not avail

[atheken]

asside from making me feel ddrruunnkk, your example right there proves the opposite, I read it SSLLOOWWEERR. :-) But you're correct, word-size alone doesn't do much at all, it's the rest of the system around that can be improved, but you knew that.

Re:How can you compare if binaries not avail

[armando_wall]

I know you are joking, but anyways, it's interesting to continue the discussion.

YYoouu rreeaadd iitt sslloowweerr because it's not a good analogy. A better analogy would be that we extend the alphabet by adding 26 times more symbols (26*26 = 676 symbols), so, in theory, we could cut the words half their current size, and thus, reading them faster.

Re:How can you compare if binaries not avail

[wayne606]

It's not generally the case that 64-bit code should be faster than 32-bit code (I'd expect the reverse, by a small margin) but the Itanium is a special case. The IA-64 instruction set is different from IA-32 and the CPU has to translate the 32-bit codes on the fly into 64-bit operations before executing them. *That* is what's slow. The AMD64 architecture, on the other hand, is an extension of IA-32 and so it's a lot faster than Itanium at running 32-bit executable.

I would guess Intel is moving in the direction of dropping Itanium and going with AMD's architecture. They really goofed when they assumed everybody would recompile all their old 32-bit apps immediately for Itanium. This is a mistake a lot of hardware vendors make... If DEC hadn't made that mistake with the Alpha 15 years ago they might still be around and the Alpha architecture might be the standard for PC's now.

Re:How can you compare if binaries not avail

[PeterPumpkin]

I'll frame this screen shot, and give you follow up crap in 50 years. :D I can see it now: "18 MTB should be enough for anyone...heh heh heh...hell I'm dyin here with 30 'emtabs'"

And yes, I'm taking credit for the first person to coin that term! :P

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

[Anonymous Coward]

I stand by my analogy. There are plenty of cases were 32 bit is good enough. Forcing them to use 64 bits will not make them faster and can be a waste of resources.

Re:How can you compare if binaries not avail

[Anonymous Coward]

Interesting post but how much was actually related to 64 bit vs just a new processor design?

I'll grant you for the large number crunching processes you mentioned, the >4GB memory that you can use with 64 bit systems will speed things up by keeping more data in memory. Everything else you mentioned is not really anything special about a 64bit system but more related to the specific Athlon-64 implementation. Is there any reason why someone couldn't design a 32 bit system with 2x the GPRs, SSE2, and using SOI?

Maybe I just misunderstood your inital post but your "64bit binarys *should* be faster than 32bit ones" comment made me think that you assume all 64 bit processes will be faster than corresponding 32 bit processes. I just don't think that that is true in all cases and thus wasn't bleeding obvious.

Re:How can you compare if binaries not avail

[sad_]

well, isn't it a valid test? it shows 64bit programs are available at least on linux but not in windows. this means linux already wins only keeping that factor in mind!

Re:How can you compare if binaries not avail

[Anonymous Coward]

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.

Right, but you won't get the benefit of the extra registers in particular unless you recompile, so comparing 64-bit and old 32-bit executables still isn't fair.

Re:How can you compare if binaries not avail

[Mr. Shiny And New]

It IS a good analogy. The OP was claiming that just because something is 64 bits instead of 32 bits doesn't mean it's faster. Reading things from memory that used to be 32 bits, but are now 64 bits, will be slower. Tests have already shown that this is the case (it's been posted on /. in the past). Take pointers for example. Someone mentioned that pointers on AMD64 are 40 bits, but that's still bigger than 32 bits. So now pointers take more room in memory, which means more work to store/read them, and the cache can hold fewer of them. All of that means less speed, unless you compensate in other areas.

If your application needs more than 4GB of RAM, or needs 64-bit math, then it may be faster because it can do things in one step (1 64-bit add vs. 2 32-bit adds). But otherwise, there may be no benefit to the AMD-64 architecture.

Also, nothing in the AMD-64 architecture matches YOUR analogy of adding more symbols: it's still binary, and thus there are only two symbols. But you're right in principle: there are designs for trinary circuits that are faster than binary circuits. But these things are not mainstream.

Re:How can you compare if binaries not avail

[Dravik]

I thought the biggest bar to linux adoption was that they didn't have the software support that windows does. How is it that I'm reading complaints that windows doesn't have the sofware support to properly benchmark against linux? I'm a little confused by this contradiction.

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.

Re:How can you compare if binaries not avail

[Anonymous Coward]

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.

It would have done that if 64 bit registers weren't 0 extended. With x86-64, you can use lower 32 bits of pointers if you don't need higher bits and it just works.

Re:How can you compare if binaries not avail

[alexo]

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

Actually, fixed point arithmetic is much faster and is accurate enough for these applications.

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

The "more registers" are not accessible by 32-bit applications.

Re:How can you compare if binaries not avail

[Smallpond]

Xeon has a 36-bit physical address (64GB) so this isn't really a 64-bit issue either.

Re:How can you compare if binaries not avail

[Waffle Iron]

Actually, fixed point arithmetic is much faster and is accurate enough for these applications.

Most modern FP units manage 1 operation per clock, just like the integer units. The vector FP extensions on some newer CPUs can do several FP operations per clock, which can beat the 64-bit integer units and provide more dynamic range at the same time.

The "more registers" are not accessible by 32-bit applications.

Exactly. That's why a lot of people incorrectly think that bigger numbers and pointers cause 64-bit apps to run faster than 32-bit apps on AMD CPUs, when it's really just that there are more registers available.

Re:How can you compare if binaries not avail

[fitten]

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 .


Funny... I can do 64-bit integer calculations using an 8-bit CPU as long as I don't mind the wait. 64-bit registers just means you can do the operations in one ALU operation instead of multiple.

I wrote a simple matrix/matrix multiplication program on my Athlon64 machine (running FC2 AMD64 because it's the only distro that I can make stable without tons of work) just to see the difference between using 64-bit and 32-bit modes on 64-bit integer data. The 64-bit version of the program was about 5.5X as fast as the 32-bit version when both matrices and the result matrices fit into L1 (or L2 cache), iirc. The 32-bit data running in 32-bit mode was slightly faster than the 32-bit data running in 64-bit mode (I suspect the matrix/matrix multiply doesn't need that many intermediates so it doesn't really need more than 8 GP registers). I can tar it up and post it if anyone cares to see it. All tests were using gcc and very simple algorithms.

Re:How can you compare if binaries not avail

[Anonymous Coward]

I stay with my 286. 16MB must be enough for everyone.

Re:How can you compare if binaries not avail

[Anonymous Coward]

Apparently the "most modern FP units" doesn't include Athlons'.
It can perform 2 fp ops per clock plus some load/store without resorting to any vector stuff. With extensions the number doubles if you're using only single precision numbers. P3/4 can do only one x87 op/clock but max SSE speed ought to be equal.
Also, both Athlon and P3 can do easily 3 integer ops per clock. Dunno about P4 but it's at least 2 as well.

Re:How can you compare if binaries not avail

[Anonymous Coward]

It can be "bleeding obvious" and still have nothing to do with a random sample. That's an arbitrary factor you just threw in.

Perhaps the best evidence for a 64-bit binary being faster than a 32-bit binary, is the millions of dollars and thousands of hours that chip makers and software developers are spending to make the transition. I believe that's pretty obvious.

Re:How can you compare if binaries not avail

[Anonymous Coward]

Comparing the software available for each platform is perfectly fair.

I can see it now:

"Boss, I think we should use the Windows OS because it can run MS Office."

Linux Zealot: "No! It's not fair! Linux would be able to run MS Office if MS made a version available!"

Boo hoo. Being able to run industry-standard applications is an obvious advantage of closed soucre, there's no reason to rule it out.

Re:How can you compare if binaries not avail

[IncohereD]

The "more registers" are not accessible by 32-bit applications.

I thought one of the improvements was there were multiple copies of the basic set of 32-bit registers, so different threads wouldn't have to push each other out on a swap?

Re:How can you compare if binaries not avail

[Psyrg]

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

Interestingly enough, it appears Moores Law States otherwise. Not only does Moores Law accuratly predict the increase in performance of processors, but it also seems to describe our lust for RAM capacity.

To present my point, Moores Law predicts that every 18 months the amount of ram we use doubles. Thus, we need to use one more address bit for every 18 months. This means AMDs choice of a 40 bit address bus only serves us for twelve years beyond the death of the 32 bit x86 microprocessor, and that is not including the four or so bits of hack space we have with PAE.

To paraphrase...

Who would ever need more than 16 bit memory addressing? Why, when with ten availiable pages of it we have 640K?

Who would ever need more than 32 bit memory addressing? Why, when with 16 pages of it we can have 64GB?

See where this is going?

Re:How can you compare if binaries not avail

[SEE]

"Emtabs"? What's wrong with "exabytes"? We call the quantity four million kilobytes four "gigabytes", after all, instead of four "emkibs".

And no, no "emxabs", either -- that's a yottabyte.

I call dibs on the term "emyobs", however. (Hey, it's got at least as good a chance as grouchibytes.)

Re:How can you compare if binaries not avail

[Sj0]

Hasn't that version of moores law been proven pretty much wrong in the past 18 months? Seems to me we've spent years around 3Ghz.

'course, moores law was more applied to TRANSISTORS than speed in any sense, but oh well. :)

Re:How can you compare if binaries not avail

[sirsnork]

This might be viable, except AMD64 doesn't have "Hyper-Threading" so it can't actually run 2 threads simultaneously.

Re:How can you compare if binaries not avail

[sirsnork]

The difference is that the address bus can be expanded to 64bit without the software ever knowing or caring, and I seriously doubt a current Athlon64 is going to be required to run the latest and greatest software in 12 years time

Re:How can you compare if binaries not avail

[IncohereD]

This might be viable, except AMD64 doesn't have "Hyper-Threading" so it can't actually run 2 threads simultaneously.

That wasn't my point. My point is context switches happen many, many, many times a second, especially on single threaded processors. The point is if instead of having one set of AX/BX/etc/etc you have multiple ones you can switch between depending on the context, that's a huge win. Rather than copying in and out every time.

Re:How can you compare if binaries not avail

[PeterPumpkin]

Poe-tay-toe Poe-tah-toe. Now that I think about it, it would be nice if we had a unit of storage that doesn't sound like another word, a phrase, or a slang term.

byte = bite
kilobyte = killer bite
megabyte = mega bite
gigabyte = jig 'o BYET (cessna)
terrabyte = tear a bite

Perhaps we should be evil and push for something like the "cockbyte".

*20 whats?
+Cockbytes
*Hey now, what are you mad about?
+What? I got 20 cockbytes, I'm pretty happy.
*Oww, that sounds painful - err...are you high or something?
+Huh? No. Anyway, all I need now is a couple cocks of ram, I'll go down Cox's . I feel like a cock getting all that ram from Cox's at such a quick, low overhead. Although some of the things I grab are best left behind... Hopefully I'll come back up to my throat in cocks. Although, I love seeing new stuff coming up...as soon as my equipment gets up, I'll be behind on cocks, and need a quick ram... Hey where you goin...?
*[Boldly, Brave Sir Robin, runs away, runs away...]

Re:How can you compare if binaries not avail

[Psyrg]

course, moores law was more applied to TRANSISTORS than speed in any sense, but oh well. :)

I guess in this case it makes more sense, since the amount of RAM on a chip is proportional to the number of transistors it has... :)

Re:How can you compare if binaries not avail

[John Courtland]

I think modern x86 processors have register masquerading or whatever it's called, where there are many more internal registers than the 8 GP's, 8 FP's and 4 Segments. Then the processor just remaps (you could say it binds) the underlying registers to the visible registers. So in essence, you only have 8 GPs visible, but a bunch more under the surface.

Re:How can you compare if binaries not avail

[tricorn]

DEC's IA-32 emulation under Windows was flawless and quite fast. The reason the Alpha didn't become a popular architecture was (a) Digital didn't know how to sell it; (b) Microsoft dropped it; (c) people keep buying what they're used to buying. If they'd put as much money into increasing the speed and decreasing the power, say by moving to a modern process size, as Intel put into developing the IA-64 architecture, Alpha chips would be twice as fast as they are and using half the power (that is to say, totally blowing away anything else that's currently available)

When Intel first started talking Merced, and how it would have hardware support for emulating IA-32, my first thought was that it would be a total failure unless it could run x86 programs at least as fast as mid-range 32-bit processors available at that time. Otherwise, switching to Alpha, with its emulation, would be just as good, with the 64-bit aspects already old and stable technology. Of course, that was before Compaq bought DEC, then blew any possible synergy and sold out to HP, which had an active reason to kill Alpha, and that was that.

As far as 64-bitness being faster, there are various techniques that can take advantage of 64-bit integer operations for "ordinary" programming tasks. Alpha libraries do an amazingly good job of doing character manipulation even though the Alpha has no 8-bit instructions, for example, or using bitmaps for block allocation. String searching and sorting, doing unordered data sieves on multiple bit fields - many techniques dating back to the 60-bit Cyber architecture. Most programmers don't use them because doing them using "long long" on a 32-bit processor slows you down.

So, no, 64-bit processors being able to address more virtual/real memory is not the only advantage.

Re:How can you compare if binaries not avail

[wayne606]

The other problem with Alpha was that it came out too far in advance of other 64-bit systems, and it had no 32-bit pointer type. Back then (12 years ago or so) lots of code assumed that sizeof (int) == sizeof (pointer) which meant that only very clean code would be portable to the Alpha. That hindered adoption quite a bit.

Now that everybody has a 64-bit architecture, Alpha might be able to compete very well against Sparc, MIPS, etc, if it had a foothold in the market...

The ironic thing about the sizeof (pointer) issue is that everybody now uses 32-bit ints and 64-bit longs, except for Win64, where long is still 32 bits. Obviously all decent code should be using caddr_t instead of making these assumptions, but...

I think we all know

[Anonymous Coward]

That this is a test for Gentoo. 64bit optimization! WHOOO!

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.

Re:I think we all know

[Phragmen-Lindelof]

I run my AMD64 under Gentoo and it works great! Granted, this is not "out of the box" (does Gentoo have a "box"?) but Gentoo is easy to use and update.
Since my computers have been 64 bit (Alpha, AMD64) for many years, I am aware of the problems with applications which are not 64 bit clean. I do not consider this an OS issue (except when the problem is with the kernel) but an application issue. As an OS for AMD64, Gentoo Linux works very well.

right

[muyuubyou]

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

Re:right

[PitaBred]

Silly rabbit, 64bits aren't just for servers any more. But I'm guessing you knew that.

Re:right

[Anonymous Coward]

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

Re:right

[redtape]

Yeah, but a 64-bit processor is a bit different from 64 KB of ram ;)

Re:right

[Anonymous Coward]

worth it's salt

"its".

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

[Anonymous Coward]

O3 is like... 150% faster than O2. There are other optimizing flags you can use, too.

Re:They should have used Gentoo

[Anonymous Coward]

Yeah, like -funroll-loops.

Re:They should have used Gentoo

[HaloZero]

I've not been able to get the Gentoo distro (2004.0, 2004.1?, when is 2004.2?) on my AMD64 box. It's a shame, I ran with Gentoo for a while on a few machines, and I'll try it again if it can do what I want. For now, I'm very very happy with Slackware, but I'm sad that Patrick can't do a 64-bit edition.

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

[Anonymous Coward]

This is how.

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

[Anonymous Coward]

The extra 32 bits in each register will only be used if you're running scientific simulations or something which requires massive numbers, like encryption. What compilers will do, however, is allocate registers more efficiently since AMD64 has more of them.

Re:They should have used Gentoo

[essreenim]

Well, maybe a little bigger than floppy size ; )!!

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

[Anonymous Coward]

> but for me "sanity" means pop a DVD in

Agreed. With thinking like the previous authors post it's small wonder linux can't progress beyond the hacked together mess that it is now.

Re:They should have used Gentoo

[NeoSkandranon]

Yeah it's so unfair to actually use 64bit binaries in linux whereas the blurb plainly states they werent available for several windows apps.

Re:They should have used Gentoo

[IdleTime]

I have been running Gentoo on my AMD64 3200+ box since April and without any problems so far.

I doubt you have put any efforts into it. Have you asked for assistance in the AMD64 forum on forums.gentoo.org?

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.

Re:They should have used Gentoo

[nuOpus]

The theme of the test was "out of the box" configuration ... as anyone would get if they just used the installer. With gentoo ... there really isnt any out of the box configuration which would leave an optimized OS (gentoo) with an unoptimized windows unless they changed the mindset of the test. The only way to fairly test windows against gentoo would be to optimize Windows also ... but again, not the basis for that test.

Re:They should have used Gentoo

[fitten]

...so you are saying that only Gentoo actually compiles everything in the distribution in actual 64-bit mode? I use FC2 on my AMD64 and it seems that almost everything I've checked is actually 64-bit compiled.

which would have taken far fuller advantage of the extra 32bits in each register to provide a much fuller experience

And I have *no* idea what this statement means...

Re:They should have used Gentoo

[HaloZero]

You're right. I really haven't put much effort into it. A few weekends. But when the majority of my time is spent trying to get the distribution to work, in order for me to do other work, the distribution is not worth my time.

And I've browsed the AMD64 forum, looking for answers to my problems here and there. Google is a wonderful resource, too.

Re:They should have used Gentoo

[DAldredge]

You must understand that the Gentoo people, at least on /., do not care if the app runs correctly, they just want it to run fast.

That's why they use every gcc flag they can.

Re:They should have used Gentoo

[budgenator]

O3 is like... 150% faster than O2.
I always thought that O3 while producing code that was theoreticaly faster, also produced code that was larger. That often meant that the faster code ran slower due to I/O bottlenecks and a tighter squeaze into existing RAM.

The bottom line is if you have a Need for Speed, then you also have a need to do your own benchmarks on the hardware and software you actualy run.

Re:They should have used Gentoo

[Phragmen-Lindelof]

"Unfortunately, we had difficulties running our new hardware platform on Gentoo and Debian"
This is a dumb comment. I would have trouble running Gentoo Linux if my computer did not have a power cord; would this be the fault of Gentoo? The Gentoo site has lots of helpful information and it is fairly easy to get answers to questions if you are having trouble installing Gentoo. I do not think the "testers" wanted to include Gentoo and this was an excuse. I am very disappointed.

Re:They should have used Gentoo

[Anonymous Coward]

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

This just goes to show that customer service is still king.

Re:They should have used Gentoo

[Phragmen-Lindelof]

Using you reasoning, they should not have included Windows at all. There is no "out of the box" Windows product (64 bit non-beta OS) out there.

Re:They should have used Gentoo

[general_re]

There is no "out of the box" Windows product (64 bit non-beta OS) out there.

Of course there is. And has been for several years now. That would have made for an interesting test, actually, comparing 64-bit Linux to 64-bit XP on Itanium/I2, but of course the binary availability problem would have reared its head for both systems....

Re:They should have used Gentoo

[fymidos]

No, O3 produces code that is faster, 02 produces code that is still fast *but* safe.

The performance gap in mathematical tasks can certainly be over 200%. Propably because O3 does no math error checks.

Re:They should have used Gentoo

[Phragmen-Lindelof]

OK, I should have said "There is no "out of the box" Windows product (64 bit non-beta OS) for AMD64 out there." Of course, you forgot NT on Alphas.
Your test sounds interesting. We could compare OSs on IA64 and on Alphas. Our university has a cluster of 32 IA64s (which was probably a waste of money).

Re:They should have used Gentoo

[general_re]

Our university has a cluster of 32 IA64s (which was probably a waste of money).

Depends on how much you paid ;)

It's a shame that I2 looks like a dead end - the first batch of SPEC results I saw for AMD64 had them running quite a bit slower than I2. Perhaps the increased interest in 64-bit clean Linux will breathe new life into your cluster.

Re:They should have used Gentoo

[NoOneInParticular]

sigh, 'man gcc' reveals

-O3 Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions
and -frename-registers options.

None of the -O options in gcc allow for unsafe optimizations. For that you have to look at -ffast-math. And yes, math error checks are still done. Inlining can be very good but does lead to larger executables and thus a caching penalty. It's often not worth it. For math-heavy stuff it's usually better to rewrite your code so that the intesive stuff is vectorized.

Re:They should have used Gentoo

[HogynCymraeg]

Andi Kleen. What a great name for a tissue product!

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.

Re:Apparently the poster didn't RTFA.

[dostert]

Yeah... I agree... it says NOTHING about Unreal 2004 being faster, like the poster suggests. In fact, they said they had to hack up the kernel just to get it to work, and didn't even bother testing the 64-bit version cause it was such a pain the the butt.

Re:Apparently the poster didn't RTFA.

[Tow_cow]

I guess most moderators don't RTFA either. Your post should have reached +5 informative by now...

Re:Apparently the poster didn't RTFA.

[FuzzyBad-Mofo]

I found that part of the article confusing.. first they stated that no compiling would be done, they they talk about "kernel hacking" to run some of the games. How do you hack a kernel without compiling? It would be nice if they'd gave a little hint as to what they meant by that comment.

Re:Apparently the poster didn't RTFA.

[Anonymous Coward]

They stated they did NOT do any "kernel hacking" (the 64bit Nvidia driver symbols didn't match the kernels used, which would require C hacking to fix).

Windows? 64-bit?

[ciryon]

Would be more interesting (and fair?) to see a comparison between 64-bit Linux and 64-bit OS X (Tiger).

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.

Re:Windows? 64-bit?

[NeoSkandranon]

You probably won't like to hear this, but:

benching a mac OS is irrelevant to a large part of the readership for various reasons (ie, it doesnt matter if its better, because that platform isn't an upgrade option)

Between Windows and Linux the majority of readers' taste in OS is covered

Re:Windows? 64-bit?

[Creepy]

I'm not sure if it would be a good comparison or not - the gcc compiler for OS X still isn't as optimized as much as it is for Intel based OSes (probably by Tiger release it will be pretty close), so I suspect that there will still be a bit of a performance hit from the compiler. OTOH, the 64 bit architectures are fairly new for Intel and AMD and haven't been optimized much in compiler, either. Come to think of it, Apple may have an advantage with compiled 64 bit PPC instructions using gcc because of 64 bit work for AIX (not that I find gcc compiled binaries on AIX particularly fast). I have no idea whether Intel is submitting code to the gcc compiler nowadays (since they're supporting Linux, it wouldn't surprise me if they were, but my compiler lore is about a year stale), but that may offset their side - traditionally, Intel's supplied its own compiler that is quite a bit faster than gcc.

In other words, it's really a crap-shoot that depends heavily on hardware optimizations and drivers. It wouldn't surprise me if the Apple video drivers are inferior to the Intel drivers, as well, so game performance is probably worse on a mac. Probably depends on how much work is done in software or in hardware, though.

Re:Windows? 64-bit?

[chrismcdirty]

Oh yeah. I guess I'm just a little stupid early in the morning.

Re:Windows? 64-bit?

[cozziewozzie]

Errr, I'm a bit confused...

Compilers are generally optimised for an architecture, not the OS. The OS simply provides the routines which the compiled code gets to call. The underlying architecture here would be the same, so the assembly the compiler generates would be extremely similar, regardless of the OS. A GCC-based Darwin vs GCC-based Linux on PowerPC architecture sounds like a very fair comparison.

The video drivers are written by NVidia, not Apple or Intel. It's possible that they work better on Intel-based machines because it's a more important market for NVidia, though.

Re:Windows? 64-bit?

[13Echo]

Sure, but OSX doesn't run on an Athlon 64. The article isn't about "which 64 bit hardware is faster", but is rather about "which OS makes the most of the AMD 64 bit hardware".

Including a PPC machine would make it a totally different type of comparision. They are not comparing Linux/Athlon 64 to Linux/PPC. They are comparing WindowsXP 64 to 64 bit Linux distributions. And besides, several programs in the comparison will not run on a Linux/PPC machine (UT2004 and ET come to mid specifically). You can't have a game comparison then. There are very few Linux/PPC games available. Linux Game Publishing's "Majesty" comes to mind, but why would anyone want to benchmark that (even though it is a great game)?

Re:Windows? 64-bit?

[leperkuhn]

you are correct - but the parent to my post had suggested a more interesting matchup might have been Linux vs MacOS X.

Re:Windows? 64-bit?

[Creepy]

Sorry I was confusing there, I actually attached this to the wrong parent and didn't catch it until after submitting.

Still, graphics drivers would make a difference, since they are written as an interface between the OS and the hardware and therefore you can see differences between them depending on optimizations to that interface. ATI is notorious for releasing functional but non-optimized drivers and updating them for speed later, although I think they've been working on their image as of late :)

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?

[Anonymous Coward]

What factor of raw "speed" faster would a 64bit processor be over a standard 32bit processor of the same clock-speed.

Clearly, 64 bits would be twice as fast as 32 bits. Not only that, but space for 64 bits means that you can use bigger bits for all of your old 32-bit applications.

I cook my Thanksgiving turkey at 900 degrees to shave the cooking time in half...

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?

[Anonymous Coward]

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.

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?

[DeafDumbBlind]

When running in AMD64 mode, the number of GPRs is doubled from 8 to 16.

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.

Re:Why?

[dpb]

Although not really tied to it being 64 bit, the AMD Opteron has a huge advantage in SMP arena in terms of memory bandwidth. Its hyper-transport memory I/O system lets bandwidth scale up linearly with each additional processor, while all other current Pentiums have memory I/O bus shared between all processors.

Re:Why?

[13Echo]

Some parts of the Dreamcast PowerVR graphics system and the Hitachi SH4 utilize an 128 bit wide bus. But yes, it's not a true 128 bit CPU core. That never stopped it from spanking the hell out of the PS2 though (from a technical standpoint, considering it was "dated hardware").

Re:Why?

[p3d0]

64-bit processors are rarely faster. They are usually slower. The advantage is memory addressibility.

AMD64 is slightly unusual in that it also has extra registers, which IA32 sorely needs, so it is possible that AMD64 code will run faster than IA32 code on the same box. However, it's still not because of the 64-bitness.

Re:Why?

[Phragmen-Lindelof]

Don't you wish DEC was still alive putting out new versions of the Alpha? More registers. Really good compilers. The best chips (at the time) in the world.
(Just curious; did anyone use this or this? (I do not use Pascal (anymore) or C++.) )

Re:Why?

[alexo]

> 64 bits should show improvements over 32 bits in two areas: high precision math, and large address spaces.

While I agree regarding the large address spaces, high precision math is done using vector units (AltiVec, SSE/SSE2, etc.) instead of the CPU's general purpose registers nowadays.

Re:Why?

[Anonymous Coward]

If high-precision means hundreds of digits in this context, then nope, it's correct. In RSA fast 64x64->128 multiply is much more useful than anything that MMX/3DNow/SSE/2/Altivec can offer.

Re:Why?

[lsdino]

I think 64bit systems are useful for certain applications. On the other hand, most individuals don't need 64bit systems.

I think large address spaces are more important than you give them credit for. Today there is an address space crunch for a large number of systems and it approaches the consumer market in some areas (video & photo processing being the big ones today) and it will only get worse.

There's also little gains you get from having a large address space. For example small (heh, 4gig and below) address spaces limit the effectiveness of burning absolute addresses into a program image. The OS will be required to fixup these addresses for applications making the memory non-sharable between processes. Net result: Increased memory usage where large address spaces would be able to share. The chance of a collision in 48bit address space range is much lower (for the time being). And in addition to using more memory, you have to actualy adjust the addresses which takes time and CPU power.

Consider that PCs today now typically have 1/8th to 1/4 of the total addressable space as physical RAM. It's a pretty tough ratio to contend with.

Re:Why?

[Hognoxious]

"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

Hmm. Do you have a kitchen, or access to one? I suggest you take a recipe, do it once as is, once halving the temperature[1] and doubling the cooking time, and once again vice-versa.
Hint: there was a clue that the person you replied to was, in fact, being ironic.

[1] Absolute if you wish.

Re:Why?

[Anonymous Coward]

Firstly, it's status, not stasis.

Secondly, how is "I've got a 64 bit computer, ner :P" economicically viable, indeed how can it be? Presumably you think it is, as you asked if there was another reason why.

Thirdly and finally, you are a 'tard.

Re:Why?

[p3d0]

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.

Where did you get that number? 32-bit pointers can address 4GB of memory.

With the AMD64 Opteron... You get a good clock speed.

Not really. The Opterons do a lot of work per clock, so they actually have a remarkably low clock speed compared with the equivalent Pentium.

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.

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:Wow, without recompiling

[ValourX]

Yeah, but Gentoo 2004.0 doesn't work correctly on a lot of AMD64 hardware. Gentoo needs a serious update before it can be usable.

-Jem

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:Wow, without recompiling

[Anonymous Coward]

Gentoo amd64 benchmarking with xmame.

You won't see dramatic speedups because, unlike ray-tracing or enterprise-level code, there are not many large-precision values going around. xmame is just vanilla C, single-threaded, extremely CPU-bound, and still brings the FX-53 to its knees on newer games.

The original benchmarks are here:
http://www.anthrofox.org/code/mame/xmame64_ bench.h tml

And the newer ones are here:
http://www.anthrofox.org/code/mame/xmame64_ bench83 .html

Be kind to the server please. (Wow, looks like slashdot inserts random spaces into plain text URLs.)

Please do NOT mod this up.

Re:Wow, without recompiling

[Prof.Phreak]

I got everything to work (gentoo on amd64) without any issues (gcc3.4, 2.6.7-mm kernel, X, etc., and ut2004 :-)

Tell your friend to visit IRC: irc.freenode.org, channel #gentoo-amd64

Most problems usually have simple fixes.

AnandTech stuffed the graphs up

[the_raptor]

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.

Re:AnandTech stuffed the graphs up

[Anonymous Coward]

Uhm, you didn't READ the graphs...

Some said Lower Is better ( Usually test exec time )

Others said Higher is Better ( Usually FPS for the games )

And in each case, the 64 bit proc did do better.

Re:AnandTech stuffed the graphs up

[the_raptor]

In the sound and 2d rendering 32-bit did better on all but one OS(FC2).

In 3d rendering 64-bit did do better.

In the games RtCW *did* do better in 64-bit, but UT2004 was the same or *worse*.

But I *did* mis-read the database tests, where lower is better (would have been helpful if Anandtech had of put that in a bigger font)

Gee, I feel for you. Really.

[Anonymous Coward]

As a Gentoo user what really stands out to me is that this test was clearly biased away from Linux.

Try being a FreeBSD developer and then ask "Gee, where was BSD in this test?"

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

[wongn]

> Besides, 64 being twice 32 justifies the upgrade cost... Depends on your needs of a computer - 99.99% of computer users have absolutely no need of a 64bit environment. Yet. But then MS are saying that they expect the average computer running Longhorn to have a dual 64bit system. At the current rate of growth in speeds of computers, I cannot see how this change will occur before Longhorn finally arrives.

Re:Speed Is Relative

[Zzootnik]

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

Re:Speed Is Relative

[cozziewozzie]

Yeah, but you get double the bits (32 -> 64) for only a little bit of extra cash (20%)!!! It's a bargain! The last such bargain was when Pentium2 came out.

Since then, the progress has slowed down. I mean, Pentium3 -> Pentium4 was only a 33% improvement, but the Pentium4 cost a LOT more. It goes to show that the innovation has slowed in the CPU market. But now we get double the bits!

At least other branches of IT are still showing amazing improvements: Win98 -> Win2000, more than 2000% bigger. nVidia GeForce4 -> nVidia GeForce FX 5200 !

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.

Re:Speed Is Relative

[YellowElf]

99.99% of computer users have absolutely no need of a 64bit environment.

Well, do you really even need 32 bits? The problem is that no one writes 16-bit software anymore, not that we need 32 bits. I'm sure Intel could make some super-zippy 16-bit computers now with 64MB of memory.

Eventually 64 bit machines will be common, that's all modern software will be written for, and then you won't be able to use a 32-bit machine if you want to because the desired software won't be available.

So, while it's not mandatory, I'd definitely say It's The Future. --dv

Re:Speed Is Relative

[drkhwk]

I hate to break this to you, but technically, 33 bit is double 32 bits.

No, it's not. Having double the number of possible values in a register does not mean that it is "double". A "33-bit" machine, if one existed, could only operate on slightly larger chunks of data than a "32-bit" machine. The original poster is correct.

Re:Speed Is Relative

[amliebsch]

I hate to break this to you, but technically, 33 bit is double 32 bits.

I hate to break this to you, but the parent didn't say that 64 bit is double the integer value of 32 bit, he said it was double the bits. Which it is. Why are you nit-picking something the parent didn't even say?

Re:Speed Is Relative

[Kjella]

"Yeah, but you get double the bits (32 -> 64)

I hate to break this to you, but technically, 33 bit is double 32 bits."

No, 64 bits (pieces of information) is the double of 32 bits. 2^33 = 2*2^32 yes, but it is not the same. If I have four dices, I have twice as many as two dices. With two I can express 6^2 combinations, with four 6^4 combinations, but I don't have thirtysix times as many dices...

Kjella

Re:Speed Is Relative

[KarmaMB84]

It is still double the BITS. Adding ONE bit does not double the amount of data. Adding another bit doubles the number of possible *values* for a set of bits. "11110000" contains double the data of "1111" but is indeed twice as large (16x) taken as an integer, but not everything is an integer. 64-bit can move twice the amount of data as 32-bit. The extra data can be used to increase numeric precision and expand the addressable memory and simply move more per clock.

Re:Speed Is Relative

[Anonymous Coward]

Err, that would be 16-bits = 64K of memory.

By all means, go get your C64 out of the closet and fire 'er up.

Re:Speed Is Relative

[Jeff DeMaagd]

Most other architectures in 64 bit mosw slows down code vs. 32 bit because of more addressing bits to load and store. The real kick is that AMD64 actually doubles the number of integer (and FP?) registers versus standard IA32.

Even if you never get more than 1GB of RAM, those registers help, usually more than offset the penalty of loading, storing and saving larger addresses. In some cases, they apparently help a lot.

Re:Speed Is Relative

[YellowElf]

I was making an unstated assumption, but I indeed miscalculated.

The old Intel 16-bit x86 architecture had 32 bits for addressing in a segment:offset format. However, 12 of those bits were redundant; each upper-word segment referred to a 16-byte memory line, so that A000:0010 addressed the same byte as A001:0000 (at 20-bit address A0010). In order to compare long pointers as equivalent, you had to first convert them to a canonical format.

I was presuming that any new 16-bit architecture would not have to be real-mode compliant in this way, so that you would still use segment:offset but then get 32 bits out of the address space, meaing the same as existing 32-bit architectures. Somehow the twisted calculation in my head came out as 64MB. I must have lost a few binary orders of magnitude on the floor somewhere.

Please forgive.

Re:Speed Is Relative

[fitten]

The Type R sticker is a better upgrade than the racing stripes as that is faster.

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

Re:Better article

[Anonymous Coward]

Check out the MySQL benchmarks comparing Mandrake Linux to FreeBSD on AMD64. Executive summary: Mandrake is faster, almost twice as fast as FreeBSD.

Here are the MySQL Benchmarks.

Re:Better article

[ValourX]

There was quite a discussion about that on the AMD64 list. I think it had to do with threading, and I'm pretty sure it's been fixed in CURRENT (which uses linuxthreads by default).

So 5.3-RELEASE should be closer in performance to Mandrake and other GNU/Linux distros.

-Jem

Re:Better article

[Anonymous Coward]

No, it is related to lock contention in the kernel, which is why nobody had any answers for them.

Reading further into that and related threads showed that this guy and a few others chipped in and offered IIRC $500 and access to their hardware for anyone willing to fix it. Their offer was not taken up.

Re:Better article

[Anonymous Coward]

FreeBSD on AMD64 is not ready for primetime. Threading is is still broken. It would not be fair to benchmark FreeBSD on AMD64 until all the problems are figured out. FreeBSD's KSE on AMD64 is the show stopper. There has been some talk of reverting to Linuxthreads of FreeBSD in order to improve performance.

Re:Better article

[chez69]

so FREEBSD 5, according to users of it the performance king for server work loads has broken threading?

Re:Better article

[Anonymous Coward]

You have to understand that in the BSD world, threading is considered a new-fangled feature (because they didn't have it in the nostalgic VAX days). That's also apparently why they don't have a good version of Java either (even tho Java is by far the #1 *nix server application).

Re:Better article

[Anonymous Coward]

Well, it is a tricky situation. It is better (faster, cleaner, better designed, more scalable, better networking, etc) than Linux. However when somebody shows otherwise, it is just a specific thing that will be fixed in the next release, or all the extra debugging checks, or due to unoptimised code.

This is why benchmarks are shunned in BSD fairy land: every time somebody runs a benchmark against Linux, it introduces a new bug or debugging check or unopimised code that needs to be fixed.

Re:It has to be done..

[Anonymous Coward]

Just imagine a Beowulf cluster of these! ...oh wait. It will actually happen..

Not completly correct

[Anonymous Coward]

True 64 bit, once optimised will be faster than 32 bit...but at the moment no one is creating the software for 64bit chips that is decent. I have to admit tho the benchmarks were promising for the windows xp 64bit fps.

_______________
ITIL Consultant

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:Windows XP 64-bit...

[bored]

There is definitly extra checking in the beta versions. Its not quite to the level of the checked builds (ie how to make your P4 behave like a 486) but its there. I've run a number of M$ betas in the past and each time i've been amazed when the final product came out how much faster it was than the beta. The 64-bit beta seems to be following the same path. I can say this about it though, I installed the M$ beta in about 1.5 hours, while installing Suse took about a week, and everything except one of my HW raid controllers is working in windows...

Re:Windows XP 64-bit...

[kmmatthews]

Ah, you seem to be confusing the checked beta builds with the public beta. Public beta has symbols stripped, but minor debugging info in place.

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.

Re:Windows XP 64-bit...

[TheNetAvenger]

Ah, you seem to be confusing the checked beta builds with the public beta. Public beta has symbols stripped, but minor debugging info in place.
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.

Either you are a newbie, or have no idea how beta products are produced.

There are LOTS of debug and checking code throughout the Windows OS for reporting errors, even in the non-checked builds.

The performance between a beta and RTM can be surprisingly different by just having the debugging code pulled from the OS. - Let alone the RAM and service usage that is removed from these debugging portions of the OS and services running removed.

Re:Windows XP 64-bit...

[lsdino]

ntsd.exe ships with the OS (since NT4? It certainly ships with XP), which most certainly is a debugging tool. It's the same debugging tool shipped in the Platform SDK (cdb.exe / windbg.exe). The difference between cdb.exe and ntsd.exe is that ntsd.exe opens a new window when you launch it. The difference between windbg.exe and ntsd.exe is that ntsd.exe doesn't have a GUI - it's all command line based. But make no mistake, they are all the same debugger.

For example you should be able to do:

ntsd.exe %windir%\system32\calc.exe
.symfix
.reload
x shell32!*

And you get all the shell functions listed out with names. Likewise x gdi32!* gives you all the GDI functions. If that's not an integrated debugging experience I'm afraid I don't know what one is.

(Note an internet connection is required for .symfix, but I think I can assume everyone here has one of those ;)

Re:Gee, I feel for you. Really.

[TTL0]

Try being a Solaris developer and then ask " Gee, where was Solaris in this test?"

Re:Gee, I feel for you. Really.

[Anonymous Coward]

Nowhere. The BSD community (and this includes the developer community) has shown their childish inability to restrain flaming anyone who mentions benchmark and BSD in the same paragraph.

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

[hey]

Hey, you never know.
Maybe the 32bit code is slower on a 64bit system... it would be good to know.

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

[Anonymous Coward]

The point is to know what kind of performance you will get if you buy a 64-bit processor NOW and start running applications NOW.

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.

performance boost?

[Anonymous Coward]

Generally speaking, is the idea behind 64 bit support that applications compiled for 64 bit will be a lot faster than 32 bit apps?
Or do you just get more address space?
In other words, is there an overall performance boost (not platform specific) to a 64 bit architecture?

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.

Re:performance boost?

[Anonymous Coward]

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.

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.

Re:But are they comparing

[Anonymous Coward]

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

Not quite. According to AMD, a 32bit program running on a 64bit is better because the 32bit program has a full 4GB of addressible space available (does not share with Kernel). I'm not sure about Microsoft's implementation though, as they've inserted "WOW64" (which doesn't make a whole lot of sense since 32bit binaries will run unaltered on the processor in 64bit mode).

Re:But are they comparing

[shawnce]

This isn't universally correct.

For example look at the PowerPC architecture. It was designed from the get go to support 64b capable instructions with 32b subset of that. So with a 64b PPC chip no emulation mode exists and you can run 64b/32b code side by side (of course the OS needs to set bits to adjust expected control register behavior, overflow for 64b is different then 32b, etc. but no expensive mode switch is involved).

You see no penalty when running 32b code on a 64b PPC. In fact running a 32b (addressing wise) application could actually be faster then running a 64b (addressing wise) application on 64b capable PPC. This can happen because of the reduced size of pointer in the data stream, allow improved L1 & L2 cache hits for data, as well as a smaller data set. Also note one can use 64b math without the need for 64b addressing.

Of course if you want to leverage 64b math capabilities when running on a 64b capable processor then you need to compile with those options so your code switches to using 64b math instructions, etc.

Re:But are they comparing

[lachlan76]

(which doesn't make a whole lot of sense since 32bit binaries will run unaltered on the processor in 64bit mode)

You have to have Windows on Windows for 64-Bit because even though the 32-Bit instructions will run on the processor, pointers need to go to the right memory.

If you try a

MOV eax, dword ptr [esp-2]

the processor needs to know which 32-Bit address space esp points to.

Excuse my assembly. No need to point out my mistakes. I'd rather not know. I normally write C++.

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.

Re:Okay, that review was kind of dumb

[Anonymous Coward]

Even more funny is this:

"The significant differences in frame rates have to do more likely with optimizations of NVIDIA drivers rather than optimizations of NVIDIA hardware. Although iD and NVIDIA has put forth valiant efforts into making Linux competitive with Windows, the benchmark above hints that either (or both?) companies run extremely inefficient code for Linux."

This is under a graph that shows the linux OS getting more FPS then the windows version - huh?

Ah, oh no, the switched the OSs around! Windows is now at the bottom! *grrrrrrrrrrr

How does that correlate to Opterons?

[FlashBac]

So the machine they had ran a Athlon 64 3500+ Socket 939 chip. And, generally kind of didnt do great with Fedora. (Well, in the DB tests, Suse rocked it, which is all I'm really interested in).
So, my question to those who know is:
Does that sort of mean that Fedora would probably recieve a beating (running on a dual Opteron box), relative to Suse? (running same)
Or do I have to run my own benchmarks :(
Does anyone else have some inter-linux benchmarks floating around?

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.

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:Biased, as usual

[Illissius]

Concur, on all points. This is, however, the only half-useful 32 vs. 64-bit review I've seen to date, which is why I submitted it. All the rest just use 64-bit Windows and 32-bit applications and do a weak attempt at acting surprised when there isn't any benefit.

Re:Biased, as usual

[Spacejock]

They had to use 32-bit binaries on Windows, they said there's no 64-bit compiler and they had trouble getting hold of the source code for most of the apps...

Re:Gee, I feel for you. Really.

[Anonymous Coward]

Uh oh, you just did.

The 64-bit OS is available

[Anonymous Coward]

Microsoft has been giving out betas for free for a while, do a search for them. That's what they used in the benchmark.

bad review for game part

[timts]

I think the video card driver probably determines it instead of the game itself.

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.

"Lays waste" to Windows?

[Martian_Bob]

Far be it from me to tout Windows for its performance numbers, but I think it's unfair for the article to say that, "both Linux distributions also lay waste to the 64-bit and 32-bit editions of Windows XP." It looks to me as though both editions of Windows were within 10% of the performance numbers of one or both Linux distros on encoding, rendering and gaming, and on DP performance when comparing 32-bit editions. Clearly the Linux distros had numbers up on Windows, but hardly the kind of numbers that I'd refer to as "laying waste". It's editorializations like this that turn off readers looking for a balanced review; I'd far prefer a review with less author bias.

Re:"Lays waste" to Windows?

[Anonymous Coward]

That's a good point. Some years ago I was reading some AnandTech articles on video card tests. And back when 1024x768 res was considered high, they would post something like:

Brand X 105 fps
Brand Y 96 fps

Then they would write in their conclusion, ... Brand X blew away Brand Y in the 3D performance... Now, in real-life, any user of either Brand X or Y would NEVER notice the difference between these fps in the end. They get too hung up on the numbers and not what it really means.

Re:"Lays waste" to Windows?

[Anonymous Coward]

However, the estimate of how much faster 64-bit code should be than 32-bit code (where the 32-bit code is completely adequate) is about 10%. Effectively, windows gets nothing from running 64-bit, where Linuc gets the full best-estimate benefit.

Note, this is in the same way as MMX makes some code 1000% faster, but was only expected to give 3-5% improvement overall.

What a worthless article

[dark404]

Most of the tests start out with "Well, this program didn't have a 64 bit version so we'll test it all as 32 bit!"

wtf kinda 64bit vs 32bit comparison is that?

Re:What a worthless article

[Anonymous Coward]

the kind that subtly concludes windows is no where near ready for 64bit computing.

and so what if it's "just a beta version"? that's all the great people of microsoft have released so that's what you're stuck with if you want anything 64bit.

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.

Re:SUSE is free

[Buelldozer]

Alas to my knowledge there is no .iso for the Pro version. Parent post referred to the Personal version so I thought I would chime in! :-)

However it is VERY possible to take the Personal version ISO, and after installing it use Yast to d/l all the "things" that you need such as Kernel Source, compilers, lib packeges, etc.

This is essentially what I have done at home, except I did an FTP install since the personal .iso wasn't available at the time I installed.

I actually DID order the 9.1 Pro, but after waiting for 6 weeks after it released Amazon still hadn't shipped it so I cancelled my order and did the way I described.

YMMV of course, but it worked for me.

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

Re:Linux on the Playstation "Cell" processor

[CURaven]

here here. where else but /. can we get the hype?

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

[Illissius]

Frown. I missed the "lower is better" part on the first rendering benchmark (despite double checking everything multiple times); this is the fourth (or maybe fifth?) comment pointing it out. D'oh. Guess I deserve it :/

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.

Re:As the poster...

[mindfucker]

Suse/Fedora did win, overall.

Of the two links you posted:

1) Suse came out on top of that one in 64-bit mode.

2) (Wolfenstien ET benchmark) The anandtech guys said that even though Windows won, it was only because the nvidia drivers are alot better on Windows (and it is implied that it is video card bound).

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:64-bit nVidia drivers under FC2

[Anonymous Coward]

Hello Brian. I have to say, I was very impressed with your post. You said some mighty fine things that my eyes enjoyed reading, to the point where I considered modding you up, from +3 Interesting, to something more deserving.

Then, just before the crucial moment, I went to your home page and saw a little icon stating 'Not online right now'.

Sorry, dude...but hey, at least you got this reply. ;)

Re:Gee, I feel for you. Really.

[Anonymous Coward]

Yeah, you know what I'd do then? I'd go and run some tests for myself instead of complaining that nobody else has done them for me.

This Is Pointless

[Anonymous Coward]

Most *nix users/sysadmins including myself build from source. Closed source Windows apps cannot be built from source. Opensource apps can. This is just another area where Linux trumps over Windows. Therefore, these results are not va.luable to me, or anyone else who doesn't run *BSD or Linux "out of the box"

Yes, I did RTFA...

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

Less is more

[gr8_phk]

"Interestingly enough, there are many places where the 32 bit versions outshine the 64 bit ones."

Are you sure that wasn't on the ones where lower numbers indicate better performance? Another poster said the charts seemed backward compared to the text. When measuring frames per second, longer bars indicate better performance. When measuring time to do something, shorter bars are better performance. You may want to check those ones again (so might I).

SMoked

[Saeed al-Sahaf]

The funny thing is they only simulated the AMD on a P4 because the evaluation team smoked the AMD chip by overclocking it and playing Halflife. Multen pool of silicon.

what we already knew

[bwthomas]

this article only circumstantally confirms what everyone already knew; (1) that linux has perennially bad driver support in the sense that, while there may be drivers, there's never any kind of optimization, which indicates a lack of focus or concern for the linux market, and (2) for most things other than gaming (and even sometimes gaming) linux is faster. the only interesting part of the review was the comparison between SuSe and Fedora Core 2, and that was crippled by the fact that there wasn't more information.

Whoops!

[Short Circuit]

QTA:

Unfortunately, you can't even try the Personal version of SuSE 9.1 without forking the $90 because the Personal edition does not ship with a x86-64 kernel.

So let the more savvy Linux users recompile their kernel...I don't see why Anandtech couldn't have tried that.

Unless other 64-bit binaries were needed that weren't included.

Re:Whoops!

[Short Circuit]

I don't see why Anandtech couldn't have tried that.

Darn it...let me reword that. "I don't see why Anandtech couldn't have mentioned that as an option."

wothless review.

[Anonymous Coward]

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.

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.

Nope, you're wrong

[lokedhs]

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.

I spent a lot of time porting over open source apps to Solaris when it got 64-bit support. There are a lot of things that can go wrong.

Oh and antoher thing: If you just recompile your 32-bit app in an LP64 environment, it is quite likely that the app will run slower, becuase it has to shuffle a lot of data around.

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.

Re:Nope, you're wrong

[lokedhs]

Right, but check how many of the apps are actually compiled in an LP64 environment. I think you'll be surprised.

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.

Re:Gee, I feel for you. Really.

[FuzzyBad-Mofo]

Does Solaris x86 work on the AMD 64 platform? The common element of the comparison was the hardware platform.

windows not ready for prime time

[Lawrence_Bird]

disclamier - i've not read the article yet

I just uninstalled the 64 bit windoze from a pc I built for a friend late this winter. While it seemed to be relatively stable, at least as far as beta goes, its not really usable.
We could not get sound drivers for the built in chipset; only very recently has ATI put out publicly drivers for the 9800. Windows update had no updates at all in regards to teh ongoing blight of security holes.

I'm no billyg fan, but it seems pointless to compare 64 bit performance when the OS is not yet ready for general distribution.

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.

Did they run X

[j_sp_r]

The question is of course if they ran X while doing mysql tests etc. If they did, Linux should be a bit faster. SuSE uses KDE and isn't that fast feeling at my AMD64 (running 32bit variant because they work better).

Re:Did they run X

[Anonymous Coward]

Bullshit. X makes it worse. Doubly so when you have terrible drivers, which I can say from experience the open-source radeon driver is awful at even basic 2D operations. That's why I had to swap out the R300 for an R100 during amd64 benchmarking and avoid DGA and Xv entirely.

Re:Did they run X

[Anonymous Coward]

Excuse me, how the FUCK does simply running X slow down MySQL in any measurable way?

Obviously running X AND doing stuff in X at the same time as doing the MySQL benchmark would slow things down, but anyone that uses a PC for something else whilst benchmarking is an idiot from the start.

So you've got X running, using maybe a couple of Meg of RAM, and probably never going near the CPU, since it's not DOING anything. HOW does that slow down MySQL?

Mencoder 3.3.1?!

[pantherace]

3rd page, they claim to be using mencoder 3.3.1... either they have a time machine, or the mplayer people have an unannounced release...

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

Doesn't matter in this case

[Anonymous Coward]

This was basically a test on out of the box software, what most normal users would use, as they don't tend to change things much. Thus lack of 64 bit programs and other such things are actual just all negatives for the windows 64. It being beta doesn't change the matter either, the beta is all they have to offer right now. If they hadn't wanted that, then they should have been quicker like the linux people with the 64 bit port.

So basically for a normal user these results are what they'll see in real life at this moment.

Quickshot

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.

Re:Worst... Benchmark... Ever

[Noksagt]

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.

I don't know--there's a case to be made for using as similar a compiler as possible when you're testing OS performance rather than compiler performance. If they wanted to throw the "big guns" at the problem, the Intel compiler gives excellent results & is available for free for noncommercial use on Linux.

I think most "real-world" benchmarks are pretty flawed & they probably should've used simpler number-crunching algorithms.

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:Pathscale compilers would be interesting...

[Wesley Felter]

The article is an "out of the box" comparison. If the PathScale compiler is so great, the application/distro developers should use it to compile their official binaries.

Also, hardware sites like Anand's seem to be too cheap to buy compilers.

This one goes to 11!

[cozziewozzie]

For tasks other than multimedia, the P4 was actually SLOWER than the P3, per clock tick.

Yeah, but 4 is a 33% improvement over 3, get it? :) I never intended for my post to be taken seriously.

The P3 design had hit the ceiling for speed, so the P4 was a redesign that was optimized for desktop stuff, like video, etc.

No, P4 was a redesign with the explicit goal of ramping the clock as high as it goes. The lower IPC measure was a tradeoff, as you cannot maximise both at the same time. The video performance has to do with extra SSE2 circuitry and associated registers, which are quite unrelated to the main pipeline/speed issue.

Java

[Anonymous Coward]

It's unfortunate that they didn't test Java in their benchmarks. Yes, I know that AMD64 Java is only beta (Java 5.0 beta2 - still getting used to that version number), but they tested a beta version of WinXP. Java has the advantage that with a 64-bit VM you get an instant improvement in all your code without recompiling - both because of the extra registers and because long values can be handled in a single access.

I have tried the beta version on my AMD64 (similar configuration to the benchmark machine) and it seems faster, but I'd like to see some real figures around that.

Re:Java

[Anonymous Coward]

Yea, and how come they didn't benchmark COBOL performance neither?

bahahe

[happyfrogcow]

Slashdot. "News for Nerds. Benchmarks that don't matter."

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:Don't forget future-proof code....

[mattACK]

Is that 4 hex or decimal?

Sorry. I just had a coworker ask me if a value of 1 was 1 binary or 1 hex. I don't yet regret killing him.

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

[Too Much Noise]

The difference between 32 and 64 bits is not significant anywhere but in the CPU.

You're wrong here. 64bit integers take up twice as much memory as 32bit ones. This is one of the reasons on dual 64/32 platforms (sparc64, G5) some apps are still 32bit - to reduce the memory/cache footprint. For AMD64, the 64bit mode brings several things: more registers (and wider), longer instructions (one extra byte), default integer size of 32bit (to skip the extra 64bit mode prefix) ... the net result of this is that 64bit code should be faster most of the time, but the speed increase depends on the app.

One day of compiling?

[alexborges]

:( Buahahaha....

Try 60 hours in my laptop. Hey if i let it work at 100% that long, it will probably melt (tibook 400, 1gb). I turned it of at about the 40th hour... it was still compiling the second package in the batch: openoffice.org

Re:One day of compiling?

[JTunny]

They have the openoffice-bin in portage, compilation isn't necessary.

I'd guess a 400Mhz laptop isn't your only machine, if that's the case distcc might be worth a look.

The authors didn't RTFA

[NoYes19]

Quick summary:
Meconder: SuSE(193,192), Windows(179,189), Fedora(83,78).
lame: Windows(282,281), SuSE(290,290), Fedor(295,205).
Mental Ray: Fedora(85.88,84.15), SuSE(86.73,85.29), Windows(92.08,91.97).
POV Ray: SuSE(1399,1762), Windows(1589,1592), Fedora(1700,1864).
RtCW: Windows(54.5,42.5), SuSE(40.2,37.3), Fedora(x,37.5).
UT2k4: SuSE(25,26), Fedora(x,26), Windows(24,24).
MySQL Select: Fedora(207,239), SuSE(215,289), Windows(259,264).
MySQL Insert: Fedora(489,515), SuSE(491,546), Windows(599,594).

Somehow tih thoose results they reach this conclution:
"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."

bah got to go...2 be continued.

Really?

[Phragmen-Lindelof]

"You must understand that the Gentoo people, at least on /., do not care if the app runs correctly, they just want it to run fast."
I am just a dumb Math Professor. I do care if latex or fortran or xfig or xpdf or sendmail or apache or gv or dvips or gimp or ssh or ... do not run correctly.

"That's why they use every gcc flag they can."
This is news to me. I am not doing heavy numerical analysis or scientific computing at the moment but I can assure you that correct answers are important and fast but incorrect answers are worthless. Who exactly do you think are the AMD64 users?

Re:Really?

[DAldredge]

Perhaps you are different, but read some of the /. gentoo posts! They don't know what the flags do, but if it runs faster IT MUST BE GOOD!

Re:Really?

[Phragmen-Lindelof]

Is there a chance you are overgeneralizing (is this a word?)?

Re:Really?

[DAldredge]

I did say some.

Re:Really?

[Anonymous Coward]

Fuck off and die, you miserable little troll. Do you still date boys?

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

Re:The largest deployed 64bit OS is OS X

[sad_]

too bad it is just running in 32bits, so i guess OS X is not the first 64bit OS to come out with nvidia drivers out of the box.

have you read grandparent? (nt)

[Anonymous Coward]

nt stands for "no text"

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.

SuSE has a 2.6.x kernel

[r00t]

Red Hat is still, even in RHEL3, using an old
2.4.xx kernel. SuSE has a 2.6.x kernel.

SuSE also employs the AMD64 hackers, while
Red Hat employs the IA-64 (Itanic) hackers.

Re:SuSE has a 2.6.x kernel

[FlashBac]

SuSE has a 2.6.x kernel.
So does FC2... aqui

Pointers to 2^40???

[mosel-saar-ruwer]

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.

So there are only 40 physical wires on the motherboard/chipset, and physical memory only lives from 0 to 2^40 - 1, yet algebraically the operating system is expecting 64 wires on the motherboard/chipset?

Wonder what would happen if you threw a pointer at the address 2^40?

Gosh, it's been a while since I wrote any C code, but something like the following:

#include <stdio.h>

void main(void);
{
long theLong;
theLong = 1;
theLong <<= 40;

char * theCharPointer = null;
theCharPointer = (char *)(malloc(64));

printf("The value at address 0x%X is %s.",
theLong, &(theCharPointer[theLong]) );
}

Presumably the OS would catch it, but it would be kinda funny if it didn't.

Re:Pointers to 2^40???

[Hoser McMoose]

Just as a FWIW, AMD64 supports 48-bit (or is it 52-bit?) virtual memory space, but only 40-bit physical memory space. From the operating system perspective the virtual memory space is all that counts. Changing physical address space is pretty easy in that it's completely hidden from the software side of things.

As for your bit of code, I'm pretty certain that would seg fault on any operating system, regardless of bitness.

Re:Pointers to 2^40???

[caspper69]

The pointers are actually 64-bit, and the non-used address space at this point is still reserved. They will increase the address space as necessary. So the code would compile and the computer would understand it, but it would point to non-existant memory.

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.

Not

[Wesley Felter]

The Power Mac G5 is 64-bit and ships with NVIDIA cards. This would make Mac OS X the largest 64-bit operating system.

Unfortunately for you, this does not follow. OS X is a 32-bit operating system.

Darn.

[mosel-saar-ruwer]

As for your bit of code, I'm pretty certain that would seg fault on any operating system, regardless of bitness.

Seg fault?

I was hoping for something more like a BSOD.

Darn.

Fake MEncoder/MPlayer version!

[Hyperbolix]

I hope I'm not the only one who caught this, but it appears the MEncoder version number used in the tests, 3.3.1 doesn't exist.

Anandtech page: http://anandtech.com/linux/showdoc.aspx?i=2114&p=3
I've used mencoder a lot with Linux, and I know the latest version, other than the CVS, is 1.0pre4. When the version is custom compiled, it appends your gcc-version number to the end of the version, so it could become 1.0pre4-3.3.1.

MPlayer/MEncoder page: http://www.mplayerhq.hu/homepage/design7/news.html
Curiously, the next page of the Anandtech article shows rendering tests with Mental Ray version 3.3.1.

Second Anandtech page:http://anandtech.com/linux/showdoc.aspx?i=211 4&p=4
Interesting! The very same version specified incorrectly for MEncoder! I think we may be dealing with a minor mistake in this article, though frankly, I can't imagine getting those kinds of speeds from MEncoder with decent quality and bitrate. My AMD Athlon XP 2100+ only gets 13 FPS, and I know that mencoder doesn't take advantage of the x86-64 instruction set.
Oh well, just thought I'd bring this to /.'s attention.

Links to mencode benchmarks for Gentoo on AMD64?

[Anonymous Coward]

It should get a big boost from gcc3.4 optimizations for amd64. It is stable in gentoo and so is mplayer.