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

Re:Market Share

[metallicagoaltender]

That conclusion is a bit of a leap of faith - what's to say people will take to Linux just because it adapts better? I'd guess that more people will wait for Windows to provide solid support for new technology than switch OSes just because they can be more cutting edge.

Re:Awesome

[trentblase]

What kind of demos did they show to bring you to the conclusion that "performance is very, very good"?

Re:Market Share

[ciaran_o_riordan]

A better conclusion would be that GNU/Linux will _never_lose_ market share due to evolution of technology.
(DRM, TCPA, etc. omitted)

hurdles

[potpie]

I think there is a general benefit to Open Source that we haven't been able to observe until now. It is a fact that Open Source is more easily ported and adapted, but the major systems haven't changed much for the past many years (Mac, X86, etc.). Now that an entirely new system is out, proprietary software developers will be stumbling over themselves as they try feverishly to make something from scratch, while Open Source developers will benefit from working as a group.

In a way, this has always been the way it worked, but now that there is a large jump in computing (32 to 64 bit processing is a pretty big jump, neh?) and the scale of development is made larger, the Open Source projects will show just how slow and inefficient proprietary software developing methods are.

Re:hurdles

[ergo98]

What a bunch of propaganda claptrap (you work for the Soviet communist party in a former life?) -- Lenin praises you comrade.

Microsoft has developed all of their code to be cross-platform for years (NT used to run on several processors, but when the same software was available on multiple platforms it strangely led people to Intel), and upwardly bit-scalable, and has been demoing 64-bit editions of Windows for years. Having the technical ability to toss a basic operating system out the door, and wanting to market and support a product homogenously in a product line are two very different things though.

Having said that, it is definitely true that this is one of those fulcrum moments -- Microsoft is still sitting on the can (I'm sure there's some imagery some can derive from that...cue the jokes), and it's one of those moments where a lot of IT directors may just decide to get in one of those Opteron boxes with Linux or whatever on it....and it grows from there. It is an opportunity for some of the unix variants now that AMD is ramping up their 64 bit processors.

Re:hurdles

[General Sherman]

What? The Mac OS has just changed recently, the classic OS is gone and it's now based on a BSD core with the mach kernel. That's a pretty big change if you ask me.

But If you're talking about 32-64 bit, then Apple has made the transition quite smoothly with the G5 if you ask me. While the OS itself is not true 64 bit, it supports 64 bit applications perfectly.

Re:whats the deal

[spikev]

It would be awfully nice of NVidia to open up its driver development process.

But I doubt that anyone would have spent the time to perfect them for the platform yet. AMD-64 has to prove itself before people will start moving toward perfection.

Re:Seti problems with x86-64 kernel

[Alphanos]

I currently run Gentoo, and while I'm quite happy with it, I think it's rather naive to say that the install guide accounts for all possible problems. I had problems installing Gentoo due to kernel problems, which are still problems even if Gentoo isn't responsible for them. As it turns out, I eventually discovered that the reason why the install process was repeatedly freezing (very odd for linux) was that an obscure bug existed in the driver for my sata hard drive controller. Switching controllers was no problem, as my motherboard has two, but there was obviously no reason why the install docs should mention this problem.

Anyway, I've ranted long enough. My point isn't that the Gentoo install docs are bad; I think they're very good. My point is that it's impossible to create installation directions for a source-based distro like Gentoo that will always result in no problems.

What's needed is a Killer App

[Ridgelift]

...my point is that Linux has 64-bit support and it has it now. Linux and AMD are a natural partnership.

What's needed is a killer game that runs on Linux-64. The must-have toy will drive Linux faster and further than any business app could. It's the reason I know most people overspend on a PC, so they can play the latest and greatest games.

Intel's known this for years. That's why they give early release processors to the top game manufacturers so that when the new processor hits the street, there's software that'll shine with it.

Re:What's needed is a Killer App

[NerveGas]

RDBMS systems are your killer app. Opterons are well-suited to RDBMS work, to the point of nearly seeming intended for it. Between the "big iron" memory architecture and the 64-bit address space, AMD has finally provided commodity hardware that can truly tackle real, heavy database environments.

The only reason I didn't buy an Opteron for our main RDBMS server this year was because they weren't ready for our peak season. This coming year, I'll be getting a minimum of a dual-opteron, more likely a quad - and getting it for a fraction of what similar performance would cost from Sun.

steve

Re:What's needed is a Killer App

[Cajun Hell]

The killer app is Gentoo Linux itself (well, gcc). There's no point in getting fast CPUs unless you're gonna use them. If you run Gentoo, you can show your friends, "Look how fast this is compiling! You would never have noticed this with Mandrake."

Re:Windows 64

[ctr2sprt]

Do you have any actual evidence to support this claim? Don't bother answering, I know very well you don't. For crying out loud, moderators, it's your job to weed out inflammatory, made-up nonsense like this! It's not being biased to mod down articles that make extraordinary claims with zero evidence - it's responsible moderation.

I suppose I should spend some time demonstrating why this is stupid to avoid being flamebait. So first, Intel isn't working on a competitive processor, not in the sense you mean it. If they are working on one, it would almost certainly be a year or longer before they could roll it out, and there's no way MS would agree to wait that long. Second, there is no possible reason for MS to withhold Windows just because Intel asked them to. MS is allowing free operating systems to have a monopoly on AMD64 right now. Do you really think they'd do that voluntarily? Third, it seems clear that Intel is betting on there being no market for desktop 64-bit machines. I don't want to get into that particular flamewar, so let's just say that, right or not, that's what Intel believes, so it makes sense for their business decisions to reflect that belief.

Business Apps

[traskjd]

In my opinion the "killer app" that not only 64bits systems, but linux in general needs to make any serious headway is business applications. Another person who replied touched on this with mention of RDMS.

What linux needs more of is actual business systems (Point of sale, finance tracking etc - for small to medium sized businesses). If you could run your point of sales system on linux the savings of several hundred dollars per system would be a major advantage. I mean it was the spreedsheet that really brought pushed PCs mainstream (you start using one at work, then you think you should probably have one at home... story goes on).

It's just an opinion - but I think we have more than enough text editors and windowing environments.

- traskjd

Re:you're missing a lot

[bluGill]

Which is the situation I hate the most. I have to support several different OSes in one code stream, and if the OS can do it I have to support big files. That means positionInFile is a 32 bit number on some systems, and 64 bit on others, choosen by a #if.

Of course when I use a variable I don't trust that notation because often enough it is defined wrong. That is I have DWORD ulFoo or some such. Better than what I just discovered: I have a ulHandle used all over, that turns out to be a pointer to a struct cast to a unsigned long. The hungerian notation is absolutely correct (it is a ULONG), while being completely wrong (it is a struct containing a lot of data) - one place where it might be useful and it isn't.

I kleep trying to remind myself not to blame the bad code of others on the notation, but I get the feeling it would be easier to drop the notation and look at the definition when I want to know. Most of the time I don't really care what something is, (If it is an intiger it doesn't matter if it is a long, int, short, byte, or long long, all the math operators work, and I can mix and match) or I need to look anyway. (Sure it is a struct foo, but I need to see the definition of foo to know what the other members are, and that is the only time I care)

Re:whats the deal

[iggymanz]

Actually, if you read the fine print for, say, the UltraLinux port, you'll find that the kernel is 64 bit and userland is still 32 bit. Now the *BSD on the other hand are much cooler in that regard..... To be fair, don't even get me started on companies like Sun and SGI claiming they had 64 bit back in the mid 90's....their OS were 32/64 hybrids in many various and interesting ways also. Even in Solaris 8 there's issues if you run the 64 bit kernel, some commands don't work correctly when one hits the 32 bit limit!

64 bit ...not nescessarily for performance

[Chanc_Gorkon]

I have had a 64 bit AIX machine running for a while with the 64 bit kernel. While I have not really had the load yet to test it, I and many others in the AIX realm don't necessarily think that 64 bit is going to increase performance. How do you test a performance increase when it only increases by a few nanoseconds??

64 bit is all about memory addresability. You can directly address more memory on a 64 bit machine then you can a 32 bit machine. Period. When you would like to get the best performance you can out of your RDBMS, most shops like to load as much of the DB as they can into memory. DB's are getting larger then 4 GB now! :) So, the need for more memory is upon us.

BillG said 640 KB out to be enough for anyone..ha ha Bill. Very funny.

Re:64 bit ...not nescessarily for performance

[NerveGas]

.... but a 64-bit address space and very fast memory controllers do make for good performance!

Every year, as our business has grown, I've had to upgrade our DBMS server to keep up. We've gone from a 4xP3 Xeon to a 2x AthlonMP to a 2xP4 Xeon, and next year it will be a 2x or 4x Opteron.

In every case, when the machine is finally hit it's max capacity, the CPU's were nearly *never* at full use. Even though the entire operation was running from memory and cache(the disk lights rarely blinked), the memory bandwidth has always been the limitation. Between the Opterons having VERY fast memory controllers (and each chip having it's own controller), and the ability to address vast amounts of memory, it's a recipe for letting those CPU's fulfill just a bit more of their true potential! : )

steve

Windows applications

[Sheepdot]

If 40% of windows applications are going to have 64-bit support in the next year, isn't that a high enough number to actually *justify* getting the machine for a Windows-based system?

I mean, I understand that Linux applications will most likely have 64-bit support a lot sooner, but 40% of windows application support in the first year sure looks like enough of a reason to purchase the machines now.

I guess I don't see a huge argument in justifying that only %40 of windows applications are going to have 64-bit support when there's virtually no drawback to buying a 64-bit processor from AMD vs. an equally priced 32-bit processor from Intel.

Sure, you can argue that it's a "waste", but even if only three of the big players have 64-bit applications (Microsoft, Macromedia, Adobe) within the first year, that's still 90% of the applications that are used on Windows machines in a corporate or even personal environment for the average user.

The driving force is going to be the gaming community, and AFAIK, the major game software companies plan on having 64-bit games available too, so I fail to see what the real issue regarding support is.

If %40,%30,%20,%10 is a fair assessment of compatibility over the next five years, that means that in three years %90 of the Windows applications can be assumed to have 64-bit support, which is perfectly fine for the corporate or average 3-year life cycle of a computer.

Or am I missing something?