64-bit Linux On The Opteron

JigSaw writes "A few moths ago Robert Minvielle put to test AMD's Opteron regarding its 64-bit Linux compatibility. The results back then were not very positive but he is now back testing more 64-bit updated distros: Gentoo, SuSE, Mandrake, Red Hat and Fedora. And this time the results are more positive with Linux offering good Opteron support where Windows-64 doesn't seem to. FreeBSD also lists the AMD64 platform as a tier-1 architecture."

Comments

Opteron and *BSD

[BattleBlow]

I think you'll find that FreeBSD has only made amd64 a tier-1 architecture starting with FreeBSD 5.2 which isn't out yet and has been recently delayed until January.

On the other hand, NetBSD has had amd64 support since 2001.

OpenBSD is reportedly working on it, but I haven't seen anything hit the tree as yet.

Opteron support could perform better

[Suicyco]

The linux opterons we have run SuSE but since the opteron compiler support is still not up to par performance wise they have yet to make a big impact on run times. AMD needs to fund some good compiler development for this architecture, as it CAN perform incredibly, it just doesn't due to unoptimized compilers. Thats why IA64 still beats the pants off Opteron IMHO. The Madison chips from Intel are insanely fast, and their compiler is top notch. PG's compilers just aren't optimized as well as Intels, and it really shows. The numbers I've seen from AMD compared to the numbers I get, are two different things, obviously due to poor optimization at the compiler level.

I suppose I dont even know the purpose of this post, just some observations :-)

www.aceshardware.com for some benchmarks

[slash-tard]

http://www.aceshardware.com/read.jsp?id=60000275

They have 32 and 64 bit apache benchmarks along with some others compared against single and dual xeons.

Re:FYI No benchmarks

[Serveert]

I've been benchmarking the opteron for the last week, it is at least 26% faster on high mysql load vs a comparably priced opteron system.

Tom's Hardware, Anandtech and aceshardware have all benchmarked the opteron on linux. Tom's hardware's benchmarking isn't that great, aces hardware does the best job.. The Opteron kicked butt in all reviews.

This is by far the best review so far IMO:

http://aceshardware.com/read.jsp?id=60000275

We're going to order a bunch of them by the end of this year so the government doesn't hit us with too many taxes, woo hoo!

Re:whats the deal

[wafflemonger]

It is the difference between porting the kernel and porting a distro. There may be some apps in a distro that do not work well on the new architecture. Also each of the apps has to interact with the others and those combinations can cause problems. There could also be issues in the libraries that cause dependent programs to crash in 64 bit mode. Yes in time it will be perfected, but if there are problems now they need to be smoked out and fixed.

Debian port infomation.

[bjarvis354]

Debian has not released its port yet, but it is coming. Here is the official Documentation (FAQ and HOWTO)

Re:Windows 64

[PCM2]

Windows has a native 64-bit version but Intel have prompted MS to delay the release until they can come up with a competitive processor.

What you say may be true behind the scenes, but would you care to cite a source? Last I heard, Microsoft's decision to withhold its Windows 2003 update would impact both AMD and Intel. At any rate, it's not like Microsoft isn't working with AMD.

Re:Windows 64

[quantum bit]

Er, there are 32-bit processors out there that can address more than 4GB of RAM.

Usually via bank switching (e.g. PAE) which is slow and cumbersome.

Re:Market Share

[NanoGator]

"Interesting revelation in the tests: Linux, while not having a great share of the market now, will progressively gain user base simply because it is so capable of evolving with new technology."

I can see this for customers such as Hollywood. This isn't necesssarily true in the consumer world, however. Too many variables to make that a reliably true or false statement.

Frankly, I find this statement a bit overrated. Nothing personal, but a little bit of clarification would have sounded less like 'pat-linux-on-the-back-karma-whoring' and more like something informational.

Re:What about 4GB?

[Anonymous Coward]

Thunking? You don't need a thunk to support a 64-bit integer on a 32-bit processor, any more than you needed them to support 32-bit integers on a 16- or 8-bit processor.

A 64-bit integer takes two 32-bit registers, that's all. Two back-to-back add instructions instead of one. Might make a difference if you have an unholy hell of a lot of 64-bit integers to add and that's about all you're doing, but if you're talking about doing a few large integers on a spreadsheet, you'll never notice the difference.

A "thunk" is a mechanism for making a procedure call in the face of some annoying obstacle that prevents the normal processor call instruction from "just working". Typical examples would be a stub procedure that maps in one of several possible overlays before jumping to the actual code, or the little dance you get to do in Windows to call 32-bit DLLs from 16-bit apps, or vice versa. The word has nothing to do with the size of a single integer.

PathScale

[bstadil]

Pathscale by former SGI'er does just that.