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

Market Share

[Hadur]

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.

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

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:Market Share

[kryonD]

Yeah....now that I think about it, the automobile industry hasn't really revolutionized much at all considering they still use that silly wheel invention.

Re:Market Share

[IGnatius T Foobar]

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.

Linux will gain user base because it's cheaper, and because some forward-thinking organizations are finally starting to see the benefits of not being chained to Microsoft.

Technology has nothing to do with it. Case in point: Intel shipped the 80386 in 1985, and it was ten years before Microsoft finally shipped a consumer-grade 32-bit operating system. (I say 'consumer grade' because Windows NT didn't count -- it required what was then considered high-end hardware that most consumers couldn't afford -- but even Windows NT was a good 5-6 years after the 386 shipped.) Despite the availability of a 32-bit processor that finally eliminated the stupid segmentation scheme of the 80286, there was no mass exodus to OS/2 or Xenix.

Don't count on consumers to be smart. They aren't. All they know is what the TV tells them to believe.

Well...

[i_am_syco]

I was always preferable to Linux over Windows on 64-bit processors. Of course, I'm talking about the G5...

Re:Well...

[zulux]

The system I can build with the Athlon 64 completely blows away the G5 tower.

Just the processor-fan alone in an AMD system can blow just about aything away - I use my old Athlon system as a leaf blower now and then.

Re:Well...

[truesaer]

Just the processor-fan alone in an AMD system can blow just about aything away - I use my old Athlon system as a leaf blower now and then.

This will always be a good joke, but people should be aware now that AMD's processors run cooler than Intel's. The thermal diode in the 64-bit chips also supposedly works well. So you should be saving heat and power with AMD over Intel now believe it or not!

Re:Well...

[10Ghz]

Athlon64's run very cool. Under light load, the CPU slows down (all the way down to 800Mhz). Hell, I have heard people using their system with the fan being dead-still! And XP's don't run particularly hot either. In fact, they run a bit cooler than equivalent Intel-chips do!

whats the deal

[nil5]

don't really understand why this shouldbe any different than supporting any other architecture. Linux does run other 64-bit architectures, eg64bit sparc and the antiquated among others. it's really just a matter of time before it's perfected.

big woop. so what else is new?

Re:whats the deal

[the_bahua]

Yeah, that's kind of my feeling. It's nice that it's working, but it looks like it still isn't quite there yet. Until I hear some better things about 64-bit performance in GNU/Linux with the Opteron, I'm going to stick with my athlon for now.

It'd be nice if some more practical benchmarks were posted, though, like I/O, database performance/stability, positive effects of the new memory access, etc, instead of, or at least in addition to telling us how well KDE works.

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.

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

Awesome

[bigjnsa500]

We went to a Sun demonstration on campus and they showed the new to be released Opteron servers with 1-4 CPUs. Price and performance is very, very good. They come with a SuSE derivitve distro. I couldn't tell if its real SuSE or a SuSE Sun optimized. Anyway, we are going to order a few of them for a BLAST cluster to replace our existing cluster.

Re:Awesome

[trentblase]

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

Re:Awesome

[Anonymous Coward]

Quake, of course! What else is there?

Re:Awesome

[skegg]

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

... they ran Java ...

Windows 64

[swordboy]

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. AMD serves to steal much of Intel's marketshare otherwise. Useful or not, console wars has caused "64 bits to be better than 32".

Re:Windows 64

[zulux]

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.

Actually, the delay in Windows64 was trying to come up with a new prefix for all the hungarian-notaion in their code.

I think they settled on the following for a 64 bit pinter to a string: pllpsexsfeString

Re:Windows 64

[jmauro]

An even better example would be MMX, SSE and SSE2 on the curret 32-bit x86 machines. All three of can process numbers that are 128-bits long. Sadly more and more machines will need to address more than 4 gigs of data at once, forcing the move to 64-bits for addressing.

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:Windows 64

[Nothinman]

I read a while ago that it comes with both versions of alot of applications because right now it's more of a development platform than anything else.

And frankly with how well Opteron handles 32-bit apps there's no reason to ship 64-bit versions of everything, a 32-bit userland with a 64-bit kernel and the option to run 64-bit userland apps as necessary is more than enough and infact that's how a number of Linux builds work, sparc64 comes to mind quickly since I have two of them.

The big problem is shared libraries, it's not a good idea (or not possible, I'm not 100% sure) to mix them so to run 32-bit IE on a 64-bit system you need a 32-bit copy of every library it depends on. And if you want to run a 64-bit version along side it you need both versions of all the libraries too. This is the biggest problem Debian is having right now, getting bi-architecture support to work cleanly.

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.

Re:Windows 64

[Zeio]

PAE already allows 32-bit x86 machines to have more than 4GB in the system. There are numerous 32-bit CPU systems with more than 4GB of memory.

You really mean to say is that each process may need access to more than that much memory, and if an application is written with PAE in mind, I believe even an application can have more.

64-bit machines are a good thing because it allows hardware people a new opportunity to slip in some good stuff (better IO comes to mind) while they are at it.

Having used an AMD64 system in both x86 and native mode, I can say this is a very good thing. Nothing sad about it at all.

Re:Windows 64

[RALE007]

Amen. An ad on the back of the January '04 Popular Science ragazine reads:

My adrenaline fix isn't what it used to be. Double the dose.

AMD me.

Introducting the AMD Athlon (TM) 64 FX processor. Take your system to extremes. Double the data path from 32- to 64-bit and you more than double the thrill factor. Uninterrupted, ear-splitting, streaming audio and rich, razor sharp video make your pad a launching pad. What's more, you get all the power you need to edit, mix, and model your own digital creations with memory to spare. Prepare to blow minds. Get a dose of the AMD Athlon 64 FX edge at www.amd.com/amdathlon64fx

The ad really annoyed me. Apparently a wider data bus doubles the computing "thrill factor". Which is good because for a while there it seemed we were approaching a "thrill factor" barrier. *Whew* glad we found away to continue the growth of the "thrill factor". I'm happy to see the computing "thrill factor" will continue to grow at an exponential rate for the foreseeable future.

It's great they're acting like you need a multi-gigahertz 64 bit processor to stream audio. Yep, this new processor will really speed up my net connection.

Lastly, because the processor is 64-bit, apparently I will have memory to spare for "editing, mixing, and modeling my own digital creations". And here I just thought I'd have the ability to address more memory, but I was wrong, nope, it will *give* me memory to spare.

Marketing sucks.

Re:Windows 64

[jmauro]

But really look at PAE. While it allows a computer to have more than 4 GB total, it doesn't allow for any one process to address more than the 4 GB total, regardless of the total amount of memory in the system, since the largest memory pointer any one program can have is still 32-bits long. PAE doesn't get around that restriction for the process. (It's important to remember an OS's idea of a process is inherently built into the processor its self.) And with 64-bits all programs can automaticly take advantage of the new address space, just not programs specificly written with the PAE hoop-jumping in mind.

And for the "new IO" features of 64-bit computers, are there any? I doubt it since, they've already been applied to the 32-bit lines of computers and slipped into the newest chipsets for the 32-bit computers. Intel and AMD both continue to introduce new items like PCI-X and Hypertransport into their "older" 32-bit lines when ever they jump processes or major models. (You're still not running with the same IO systems on the 386 on your P4 now are you?)

PAE was really just a temporary stop gap to fill the void until Intel made its 64-bit processor. The only real reason for going to 64-bits is memory addressing.

Re:Windows 64

[gbnewby]

64-bit address space means that a PROCESS (loosely equal to a PROGRAM) can access > 4GB. In Linux, processes are limited by 32bit (i.e., 4GB - though in practice a process can usually not get quite that much).

So, the "big deal" about 64-bit is that (a) there will be *direct* access to the memory beyond 4GB, as the previous message mentioned; and that (b) individual processes will be able to access > 4GB.

(a) provides a performance boost, by removing the need for "mapping" between 32-bit and 64-bit address space at the low level. [I haven't looked into the extent to which this actually happens in the Linux kernel - I hope to read some elaboration.]

(b) removes an important barrier to the many programs that want > 4GB, but can't get it (even on a system with well over 4GB). RDBMS, various simulation models, very large rendering, etc. are all great candidates, and we'll be seeing more. Before someone argues that they *can* get > 4GB on 32-bit: yes, it's possible to have multiple processes working together in a program. But each process has a max of 4GB.

There are lots of interesting byproducts of going to 64-bit addressing, notably that pointers move from 4 bytes to 8. So, today's implementations try to trade off, by allowing either compile-time choice of how large the address space should be, or space-saving techniques so that MANY aspects get the full 64-bit limitations, but not all (for example, 6 bit pointers rather than 8 bit; and limiting the # of file descriptors to 32 bit, since nobody needs 18446744073709551616 open files right now).

Nuff said... Greg

moths

[Anonymous Coward]

A few moths ago

Even 64-bit Linux doesn't prevent spelling mistakes on Slashdot.

Re:moths

[prockcore]

A few moths ago

Even 64-bit Linux doesn't prevent spelling mistakes on Slashdot.

No no, he's implying that it's buggy.

FYI No benchmarks

[civilengineer]

Benchmarking: Again, I do not have any benchmarks on CPU performance to show off. I did run the povray benchmark, but looking over the Povray benchmark page I see P4 3.0GHz machines getting beat out by Athlon 2800's and vice-versa, so I have little faith in the results (or at least in peoples postings to the site). Other sites on the net have run benchmarks on the Opteron, but without a 64 bit OS, and without 64 bit compiled benchmarks, I also have little faith in them. They should be used as a "touchy-feely-sort-of-may-bee" mark at best, in my opinion.

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:FYI No benchmarks

[BJH]

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.

Really? That's a neat trick ;)

Re:FYI No benchmarks

[Serveert]

Woops meant to say compared to a similarly priced Xeon.. eh I've been testing too much.

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.

Re:Opteron and *BSD

[DarkHelmet433]

While thats true, NetBSD's initial amd64 port was done years ago, the hardware hasn't been available in interesting quantities until relatively recently.

On the other hand, if you want to talk about bragging rights, FreeBSD's ia64 code hit the tree in September 2000. NetBSD still doesn't have support for that platform. Mind you, FreeBSD's 2000 version of ia64 support wasn't any more useful than NetBSD's 2001 amd64 code landing.

NetBSD's x86_64 support initially targeted the simulator, just like FreeBSD's initial ia64 support. Both were essentially academic curiosities at the time.

I've only had real x86_64^H^H^H^H^Hamd64 hardware since august 2002-ish.

Re:Opteron and *BSD

[pantherace]

IA64 is by no means x86. It is it's own instruction set (somewhat compatible with HP's PARISC (it can run the binaries natively (I not sure if the opcodes are the same or if there is a compatibility layer.)

IA64 is a new one which tries to explicity code parallel instructions. It is titled EPIC, as opposed to RISC, VLIW or CISC. It is one of only a few CPU instruction sets which were designed as 64-bit (alpha) and not had it tacked on (sparc mips)

x86-64 always has refered to amd's 64-bit extentions to x86 (aka ia32) It has NEVER refered to Itanium.

Re:Opteron and *BSD

[ninjaz]

The OpenBSD project isn't just working on amd64, they even wrote a song about it. :-)

Like other Barbarians before him, Puff has had to face some pretty crazy challenges.

This song is an allegory of the recent difficulties we went through dealing with Sun, who refused our request for documentation about their UltraSPARC III processors. We want documentation, because these are the fastest processors with a per-page eXecute bit in the MMU, needed to fully support our new W^X security feature.

In the meantime, the AMD Hammer has come onto the scene, and this processor supports an eXecute bit in 64-bit mode. And it is going to be faster...

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

Seti problems with x86-64 kernel

[Alizarin Erythrosin]

I don't know exactly what caused it, and it may not be much of a concern for other people, but the cpu time on my Seti@home units wouldn't increment using a Redhat beta for x86-64, with both the 64- and 32-bit clients. I liked the idea of using a 64-bit Linux distro but if I couldn't get Seti to run correctly on it, I'll just run a 32-bit version for now (Fedora Core 1 currently).

As much as I'd love to support Linux by purchasing a distro, SuSE wants $130 for their AMD64 distribution, which I just can't afford right now. And I'm too much of a noob to build my own from scratch using pure source, so I'll hafta wait.

But anyways, it's exciting to see more AMD64 distros, even if conspiracy theory says that Microsoft keeps delaying because of Intel pressure. I'm very happy with my dual opteron server, and will be even more-so when I can run pure 64-bit Linux.

Re:Seti problems with x86-64 kernel

[acidtripp101]

This is why I'm glad I started out using slackware. 90% of people think it's actually hard to compile your own software.
You have 2 options
1) use a source based distro (gentoo, sourcerer would be best)
2) make your own distro

I GUARENTEE that if you follow the directions on the gentoo install page, that you won't have one problem. Any of the serious obsticles I've had with gentoo are user errors (I get bored during an emerge, start reading ahead, and skip a step).
I never have been able to get sorcerer to install, but Gentoo works perfectly

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.

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.

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

[Hoser McMoose]

OS X has only VERY half-assed 64-bit support. It's support is barely better than Intel's PAE mode which has been supported in Windows for years (since NT4.0). The Macs have the minor advantage of being able to handle 64-bit integers through math libraries, but while that's nice, it's really a very distant secondary benefit of 64-bit processors.

To have proper 64-bit support you need to be able to give the application a flat 64-bit virtual address space to work with. OS X does not do this in any way, shape or form.

Don't get me wrong, OS X is a good operating system, Apple really seems to have taking the right approach to it's design IMO. But it's definitely not a 64-bit OS.

Re:hurdles

[HalfFlat]

I think you may have fallen for a little propaganda yourself ...

Microsoft has developed all of their code to be cross-platform for years

Not true I'm afraid. Windows NT 3.5 and 4.0 (and maybe 3.1 too?) were available for Alpha, MIPS and PowerPC. But other than these versions of the OS, and some associated server software (such as IIS and SQL server) everything was Intel only. In particular, the Microsoft Office software was only ever supported under emulation for Alpha.

and upwardly bit-scalable

Not really sure what you mean here, but at the time there existed non-Intel versions of Microsoft software, they presented a 32-bit environment, even on 64-bit platforms such as Alpha and MIPS. Given the win32 API, it actually seems like a serious problem extending it to 64-bits in a compatible way, given the frequent and intentional confusion between 32-bit int values and pointers.

demoing 64-bit editions of Windows for years

Working in the computing industry for many years now, I have to start with a low opinion of demos, having written too many myself. If Windows were written with portability in mind, why is it that the Itanium version of Windows Server 2003 lacks so many features of its 32-bit brethren?

That there was a brief period of partial cross-platform support in Microsoft's recent history is more to do with from where they got the basis for Windows NT in the first place (ie Digital) than anything else. And word-size agnosticism has never been their strong point - one would have thought they would have learnt from 16-bit Windows 3.1, but no ...

The conclusion...

[joestar]

This lets you directly jump to the conclusion without having to read the 3-pages:


Conclusion:

The coming months (weeks?) should be interesting in that Mandrake is set to release the AMD64 version any time now, as they are taking pre orders for it in the Mandrake store. Recall, it was one of the best (if not the best) in my first review, and I blame the drive problems on the Asus BIOS update. Gentoo is nearing (from what I read) a really stable working system, and I have read repeatedly that others have it working fully (as a workstation with X windows) on other motherboards, so I again blame the Asus for my troubles with Gentoo. Red Hat is another story, having dropped the desktop edition, the "workstation" edition is well beyond my financial reach. A corporation may consider purchasing a copy for evaluation, but I would be tempted to wait on Mandrake or Suse.

FYI: costs as of 12-16-2003 for AMD64 Linux distributions:

Mandrake pre order $100
Mandrake corporate server $750 (standard support) $1500 (unlimited support)
Red Hat AMD64 workstation $792
Red Hat Advanced Server $1992
Suse Professional 9.0 $120 (distribution on DVDs, no CDs)
Suse Enterprise Server $767 (2 cpu) $1450 (4 cpu)

Looking at the above cost matrix and my experience, it is almost tempting to purchase SuSe just to have the DVDs (no CDs, strange). The enterprise/server editions seem to all be priced about the same, with no definitive mention of CPU capability from RedHat or Mandrake on the server editions. (I assume at least 2 CPU capability built into the kernel)


Side note: the Mandrake pre-order in question is Mandrake 9.2 (pre-order is at http://www.mandrakestore.com)

Speed vs Memory

[ArkiMage]

The whole idea of a CPU with more bits of addressability is memory... MORE memory... 4GB of addressable RAM on a 32-bit processor is simply not enough today. Speed is a side-issue, they're already fast, some of us just want more RAM.

We have a couple of Opterons with 8GBM RAM each running as MySQL/INNODB backend database servers. With that much RAM databases that would crawl on IA32 are very fast since so much more of it can be cached in RAM.

The only real problem is memory technology hasn't kept up. 1GB DIMMs can be had at almost reasonable prices but 2GB density ones are out of range of most everyone. 4GB are on the distant horizon.

I'd have gladly stuffed 16 or 32GB of RAM in the boxes we have if it had been affordable. More for less!

Re:Speed vs Memory

[IvyKing]

The only real problem is memory technology hasn't kept up. 1GB DIMMs can be had at almost reasonable prices but 2GB density ones are out of range of most everyone. 4GB are on the distant horizon.

Crucial is listing their CT51272Y265 DIMM's for a measly $6999 - these are 4GB PC2100 registered with ECC. The price (ahem) may be a bit high, but if you really need the memory...

Hal Computers had an interesting "benchmark" back in the late 90's. Their Sparc box was capable of handling 3 GB (at close to 80 grand per GB), one chip simulation took 40 hours with 2 GB and 1.5 hours with 3 GB.

Re:Speed vs Memory

[Nothinman]

If you're letting the OS do the caching you could get an IA32 system that handles >4G memory and the performance would probably be close, I'm not sure how much of a performance hit PAE in the kernel has but the price difference might make it worthwhile. And since you'd be relying on the normal Linux page cache the applications don't have to be 64-bit aware to have all that memory used for their caching.

Compatibility-performance fallacy

[scd]

The Opteron may have compatibility for 32-bit programs, but it won't be as effective as its native 64-bit mode.

I'm sick of people making the mistake that a '64-bit' processor will automatically perform poorly at apps compiled for 32-bits. In the case of the Opteron, a 64-bit app will probably run better due to more general purpose registers (32 vs. 8), but by his tone, the author of the article seems to think that 32-bit app performance will be unimpressive (like Itanium).

This just ain't the case with Opteron or Athlon64.

Debian port infomation.

[bjarvis354]

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

What about 4GB?

[localman]

Doesn't seem the article tests the system with >4GB. That seems odd since that is one of the most compelling reasons to go 64bit (other than pure bragging rights).

My company upgraded to SuSE on Opteron a few months back, and had some random memory corruption with our 8GB setup. Turned out it was some bad interaction between the Tyan motherboard, the BIOS, and the stepping 1 of the Opteron. What a pain.

We're stable now with 4GB, but the memory was the only reason we upgraded in the first place. I'd like to see more tests with lots of memory.

Cheers

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.

Re:What about 4GB?

[Junta]

I've been working with an Opteron platform as well and I've seen several issues when the memory gets above 4GB. A lot of it has to do with them recycling the 32-bit code used for BIOS operations before that breaks under those conditions. In our case, the problems are mostly solved. We have seen a couple of dirvers, however, that had issues (some really picky portions that really relied on addresses being 32 bit values). The 32-bit capability is a double-edged sword, gives greater compatiblity, but someimtes companies take shortcuts with what they have since it at least gives the initial impression of working, when the reality is that the shortcuts break things in some obscure ways.

heh?

[DashEvil]

"The only questionable aspect of the Suse distribution is the choice of kernel, which is 2.4.21. I know that 2.6.x is beta for now, but it does seem (from the Gentoo installs) that it is faster and able to play nice with the ACPI, unlike 2.4.x on this motherboard."

Can someone tell me why using a stable kernel over a development kernel is a 'questionable' decision?

I stopped reading the article there, that is just stupid.

Re:heh?

[EMN13]

That's not so stupid at all. Although i have no experience with 2.3; I've heard it said that the general stability of 2.6-test is quite beyond that of the early 2.4-test - so much so that it's quite useable.

Furthermore; Before a kernel is "stable" it's going to have to be stable on most arches that it's to run on; support all the hardware correctly etc etc etc. For a distro specifically targetted at one arch, it can be much simpler to target a good stability because the problematic hardware interactions are far simpler.

Finally, it seems entirely normal, and indeed the opposite rather "questionable", for a _beta_ distribution to include that software that they intend to ship with. 2.6 Is definitly nearly at that point; as such it's the obvious choice to use. By the time AMD64 under linux is ready for prime time, i bet that 2.6 will be too.

--Eamon

Re:heh?

[nofx911]

According to the Gentoo folks: "The 2.4.x kernel line is being deprecated for amd64. As of 2.4.23-pre7 devfs has been disabled (hardcoded in kernel), stating memory corruption as the reason. Please see this message on lkml for more info: Re: Oops linux 2.4.23-pre6 on amd64. We at gentoo have not experienced any such problems, but 2.4 is not a good solution on Gentoo without devfs." You can read more about Gentoo and Opteron here: http://dev.gentoo.org/~brad_mssw/amd64-tech-notes. html

Anyone know about the maturity of NUMA support?

[Serveert]

I believe the latest 2.4 Linux kernels have NUMA support but is it mature or will it get any better? Are other unix OS'es better at taking advantage of NUMA compared to Linux and will this change in a future Linux version?

.NET

[MrBlack]

That is one of the interesting benefits of virtual execution environments. AFAIK the JIT compilation process can take advantage of the target system's architecture, so .NET apps would not need to be recompiled to see a beneift. I don't have access to a 64 bit CPU so I haven't investigated but I did notice 64 bit versions of the .NET framework in the latest Whidbey betas. I'm not sure if there is a 64 bit version of framework 1.0 or 1.1. I did notice at least one Tech-Ed presentation from this year was on writing .NET apps to target 32 and 64 bit platforms.

Re:.NET

[Keeper]

Microsoft currently doesn't have a 64bit version of the .Net runtime for 1.0 or 1.1. Whidbey (.Net 2.0) is supposed to ship with a 64bit version.

Re:when dual-64 will hit the shelves?

[Alizarin Erythrosin]

I've seen plenty of them online (I got mine from googlegear.com, now zipzoomfly.com, but have seen a few at newegg). I got a Tyan retail box server board for my file server from ZZF. (I hate that new name)

Don't be afraid to shop around online... both ZZF and newegg (I buy parts from them all the time) are great retailers if you live in the US (I know, US centric but you don't specify where you live :-P)

I'm sure your local computer parts store wouldn't mind ordering you one though, for a small fee ;-) And I don't work for either company.

Re:128-bit? quantum computers?

[Anonymous Coward]

Let me consult my crystal ball...

Yes, we will. Keep in mind, "near future" is relative. The universe is really, really old.

Re:when dual-64 will hit the shelves?

[BJH]

What are you talking about? Dual Opteron boards have been out since pretty much Day 1 of the Opteron's release.

A few examples:
Tyan Thunder K8W
MSI K8D Master-F
Rioworks HDAMC

Re: Hungarian Notation

[mountiealpha]

S mi a baj magyarral? Szerintem egy nagyon szep nyelv, de lehet hogy egy kicsit eloiteletes vagyok ebben az esetben...

(What's wrong with Hungarian? I think it's a very beautiful language, but I may be a little prejudiced in this case...)

MT

BTW, there should be accented and tilded characters in the above sentence, but I don't know how to submit them using the Slashcode engine.

Radeon drivers

[Fnord]

I've been very happy with Suse on my opteron system, but there's one thing that keeps a 32 bit installation on another partition. ATI, though they've made several press releases about how they "fully support the opteron", has not felt the need to release 64 bit versions of their drivers (either for linux or windows), and the open source radeon driver doesn't support the radeon 9700 pro that I own. I'm almost tempted to get an nVidia card simply because they have 64 bit drivers, even though this generation of cards just isn't as good as ati's.

Re: Hungarian Notation

[bluGill]

The language is fine. The notation as used in programing (like MS does) is a pain. I have to use it, meaning I'm always making up prefexes for each class and structure I have. I have yet to see any benifit to it. I try to be kind and remember I've only worked on this code for a couple months, but I still hate it.

Apples to oranges

[PCM2]

Man, you're getting confused. The "bits" that the current generation of processors can sling around have no meaningful comparison to the qubits of quantum computers.

Ultimately, part of the problem here is that people are still trying to find one single, meaningful number that can tell them whether one processor is "better" or "faster" than another. There just isn't such a thing anymore. Yes, megahertz really is (at least partly) a myth. Processor vendors are doing a lot of things with their chips now that make any single figure pretty much irrelevant. You have to look at a whole bunch of things, like pipeline depth, cache design, the things being done to make chips more efficient at lower clock speeds (a la AMD's chips and the Pentium-M), the number and workload of actual function units on each chip, etc.

A "64-bit chip" isn't automatically "better" than a 32-bit one, just like a 2GHz chip isn't automatically better than a 1.8GHz one. One thing remains true: processors are getting better all the time, and will continue to do so.

Re: Hungarian Notation

[rhinoX]

That's why you use a handful of well-defined and strictly used prefixes.

s - struct
a - array
str - string (stl)
sz - string (c)
csz - CString

etc. Making up new prefixes for everything is just about as useful as not using them at all.

Re:Fallacy fallacy

[scd]

I know. That is why I said that 64-bit apps will probably perform better. I was commenting on the fact that the author of the article seems to be under the common assumption that a 64-bit processor will automatically perform worse on 32-bit apps than a 32-bit-only processor (despite the fact that Opteron does run 32-bit apps natively, rather than emulated like Itanium). For an example of this (not Opteron-related, but thematically the same), check out some Mac boards from before the release of the G5, where some posters insisted that every app would have to be recompiled for 64-bits or else they'd perform badly.

Sorry for the misunderstanding.

64 bit is more about memory

[stabiesoft]

I ported my software to the opteron a few months back. It was quick & easy (I used a beta red hat distro). The main reason I got the box was to provide customers an alternative to sun. I work in EDA (we do the software to make the chips) and 4GB is not enough for the big chips. I'd encourage other developers to give the opteron a try. I think it took all of 2 days to do the port. Performance has been good, but since I can't afford a fast sun box, I can't really compare.

Re:Linus and BIOS usage?

[Anonymous Coward]

The BIOS initializes the hardware and then Linux uses it as it has been initialized.

On many systems only the BIOS knows how to do things such as set the speed of the IDE connection. Linux can then query and use that speed but it cannot set the speed to anything else. This can be true even though Linux goes to the hardware directly and does not use the BIOS.

PathScale

[bstadil]

Pathscale by former SGI'er does just that.

Re:128-bit? quantum computers?

[sundling]

I doubt I will see 128 bit computing in our lifetime, but then again I might live longer than I expect. Why would we need it? The memory
addressing situation will take probably over 100 years, if you think of the amount of memory doubling every 2 years, to take up that next 64 bits of address space, that's about 128 years, right?

So, short of some new technology requirements or ram moving much faster (it will probably advance slower) it doesn't sound likely.

Re:4GB of addressable RAM ...is simply not enough

[SparklesMalone]

I want to play Civ IV with 18 million terrabytes of addressable memory. Paris is is researching Creme Brulee, Liverpool is building the mod haircut, and there is a coppertone shortage in Pismo Beach.

Is there a word for a mega-terrabyte?

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:Fallacy fallacy fallacy

[Anonymous Coward]

All modern processors have way more physical registers than architecural registers. Dynamically at run time the registers are renamed. So an increase in physical registers can help even 32-bit code that uses 8 architecural registers....assuming the scheduling window is big enough. Those 8 x86 registers are dynamically mapped to 128 physical registers. Not bad.

Re:128-bit? quantum computers?

[Just Some Guy]

a bit offtopic, i know, but i can't help wondering whether we'd see 128-bit cpu's in the near future... possibly with quantum computers.

Don't hold your breath. The jump from 8-bit to 16-bit was important; CPUs could address a whole 64KB of memory with just one index register. 16-bit to 32-bit was equally big, since it increased the addressable single-address-byte memory space by a factor of 2^16 (from 64KB to 4GB).

However, with the jump from 32-bit to 64-bit, you're increasing the addressable map by a factor of 4 billion. Put another way, the relative increase is 2^16 times bigger (4 billion fold instead of 65 thousand fold).

I'm still somewhat amazed that my office workstation has over 20,000 times more memory than my first computer. I do not anticipate being alive, though, when an off-the-shelf PC has 4 billion times more memory than this.

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:skimps on redhat and fedora details

[Erwos]

Good place to bring it up: the academic pricing DOES include the x86-64 version of RHEL, too.

When we were discussing this at a system admin meeting, several people who were running Linux clusters got VERY big grins on their faces.

-Erwos

Should of benchmarked kernel 2.6

[Billly Gates]

2.6 supports many more processors, more chipsets including the new 64 bit ones which 2.4 is buggy when apic or apci is turned on, Serial ATA hard drives and cdroms, etc.

Of course alot of it has to do with the gnu C compiler being optimized but the newer kernel will better take advantage of the newer chipset and other features.

Re:128-bit? Why would we need it?

[Mr. Frilly]

uh, no.

floats are 32 bits.
doubles are 64 bits.

Most modern CPU's handle floating point as 64 bits internally (with a couple extra bits for rounding stuff off, etc.). If the CPU is compliant to the IEEE specs (almost everyone is) you should get the exact same results running on one architecture as another.

The main exception is Intel, whose math processing uses 80 bit internally and is not IEEE compliant. While technically Intel's floating point math is a little more accurate (we're talking about the last bit here), it can be annoying that your results from a IA32 processor will be slightly different than from a Sparc...

Note that while Intels are 80 bit internally, as soon as you move off the CPU, you're back down to 64 bits. Someone correct me if I'm wrong, but I believe there's an option in gcc to force IA32 code to be IEEE compliant, and it works by inserting a load and save before every floating point operation (forcing the value off chip, which kills performance but causes things to get truncated to 64 bits).

And I've never heard of anything using 96 bits.

Re:128-bit? quantum computers?

[Hoser McMoose]

In the near future? Not unless you use a very broad definition of "near future". The main reason for this is quite simply that 128-bit CPUs would be SLOW as compared to 64-bit chips and add absolutely no meaningful features.

Every time you increase your bitness of the machine, you increase the size of your pointers, and bigger pointers take up more memory, take longer to load from memory (or store to memory) and they fill up your cache faster. All else being equal, 64-bit code is usually about 5% slower than 32-bit code, and 128-bit code would probably be 10% slower than 64-bit code. Of course, all is rarely equal with 32 vs. 64-bit code (ie the AMD64 instruction set doubles the number of registers when running in 64-bit mode, and that usually more than makes up for the 5% performance hit of running 64-bit code and actually makes things faster since x86 is so register-starved). With Apple's G5 though we might see this 64-bit performance hit. The IBM PowerPC 970 and the PPC arechitecture in general is exactly the same in 64-bit mode as in 32-bit mode (warning: before anyone jumps on me for this, I'm kind of oversimplifying here :> ).

There are, of course, exceptions to this rule. Any time you need to access more than about 2GB of memory, then 64-bit is the only way to go. While 32-bit chips can, at least theoretically, support up to 4GB of memory, things start getting really messy by around 2GB and typically you can't actually use more than 3GB. Quite a while down the line (40+ years?), 64-bit processors might run into a similar memory problem and then 128-bit chips will be worthwhile. However, since 64-bit chips can natively address 10^19 bytes of memory, this is still quite a ways off even if we continue the trend of doubling memory requirements every 2 years or so.

There is also the issue of large integers. If you need integers with a range of more than 4 billion (maximum that 32-bit allows), then using 64-bit integers is faster. You CAN deal with 64-bit integers on a 32-bit chip, it just takes at least 3 times as long. If you only need to deal with one 64-bit integer every ten thousand instructions, than this advantage is negligible, but if you deal with very large integers regularly it will help performance. The advantage of using 64-bit integers is very rare though (remember that most complicated calculations use floating point numbers instead of integers). Going from 64-bit to 128-bit integers helps even less. It's got to be extrodinarily rare that an integer range of greater than 10^19 is required.

In short, the need for 64-bit CPUs in here now for some and will be very beneficial for many people in the next 2-5 years. The need for 128-bit chips is pretty much non-existant now and likely won't exist in any meaningful quantity for 30+ years. Beyond that, who knows.

Ohh, and before anyone makes some clueless comment about how game consoles are already 128-bit, they aren't. They are measuring a totally different bitness related to video processing. The CPUs of the three major consoles out there today are all 32-bit. The Nintendo64 used a 64-bit CPU, mainly for marketing purposes, but it was rather useless from a technical point of view.

FreeBSD/amd64

[DarkHelmet433]

I threw together a 30 second screenshot in case anybody is interested. http://people.freebsd.org/~peter/desktop.png

FreeBSD/amd64 is a pure 64 bit OS. There is no 32 bit code at all. The kernel, userland, ports/packages etc are all 64 bit. None of this hybrid 64/32 stuff. :-)

Actually, this is probably our greatest liability. While we can run 32 bit binary applications (can you say perforce?), it isn't perfect. Much more work is still going to be done in this regard.

If anybody is interested in giving FreeBSD/amd64 a whirl on one of these machines, we'd appreciate folks trying out the 5.2-RC1 ISO images. See the ftp link on the story above. Since RC1, lots of bugs have been found and fixed. Most notably for support of KDE and gnome environments. If you do try it out, do be aware that its still a little green in this area.

I personally, have been running a FreeBSD/amd64 desktop for about 2 months. I do subscribe to the 'eat my own dogfood' mantra. I do not have any x86 unix machines left except for my 486 firewall and a laptop. That goes for both home and work. My work desktop is FreeBSD/amd64 too.

Anyway, it's nice to see a FreeBSD reference here for a change.

If X doesn't work on Gentoo/Opteron...

[Brane2]

How come I'm using it on my dual Opteron 240 (on Tyan S2885) ?
It's true that many things doesn't work in 64-bit mode (loke OpenOffice, Abiword etc), but system WORKS ! By "system" I mean X, cups, samba, KDE, Gnome etc. It works so well that I have bought two dualCPU machines (update of two aged workstation machines-P4 2 GHz and Tualatin 1.4 Ghz @ 1.7 GHz) and I'm waiting for a third to arrive- that one will replace fileserver/printeserver/firewall/etc machine.... Gentoo on Opteron works, and unpolished details are getting its shine rapidly. I use: Motherboard TYAN Thunder K8W S2885 2x Opteron 240 2 Gb of PC2700 ECC Reg (512 Mb modules) GeForce 4 Ti4200 HDD EIDE 120 Gb WDC

Re:If X doesn't work on Gentoo/Opteron...

[Brane2]

I'm using it because: -I need 64 bit integer ops
- I need performance increase due to 1 Mb L2 and much bigger register count than in x86
- I need better scalability than with Athlon MP.

Current Athlon MP offerings are pale compared to Opteron.
With Athlon MP, there is some performance penalty to be paid when going SMP, due to different factors.
One is pure frequency of available CPUs, other is sharing of the bus bandwidth between two CPUs, yet another is relatively old chipsets for SMP Athlon MP systems, compared to uni CPU Athlon boards...

Besides that, poor old Athlon can't even begin to compete with Opteron regarding bus bandwith. Even more, Opteron needs memory bus only for memory comunication. Everything else goes through HT ports, while old AThlon has to scram it all through one bus.

So, even though I only use 2 Gb per system at the moment, 64 bit architecture shows real speed advantage. After prices of RAM fall a bit, I'l probably go to 4 or 8 Gb and/or faster Opteron, but neither is criticall at the moment.
I can certainly wait a year or two with that...

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

Re:128-bit? Why would we need it?

[calidoscope]

floats are 32 bits.
doubles are 64 bits.

Sez who?

On the CDC-6600 and 7600, single precision reals were 60 bits and double precision reals were 120 bits (well 1 bit for sign, 11 for exponent and 96 bits for the mantissa).

Sun Fortran has support for 128 bit reals (IIRC copied from DEC) although handling of those beasts is done by software.

Note that while Intels are 80 bit internally, as soon as you move off the CPU, you're back down to 64 bits. Someone correct me if I'm wrong, but I believe there's an option in gcc to force IA32 code to be IEEE compliant, and it works by inserting a load and save before every floating point operation (forcing the value off chip, which kills performance but causes things to get truncated to 64 bits).

Dunno about the Pentia, but the original 8087 implementation had a control word that would force rounding to either 32 or 64 bits. Also bear in mind that the SSE facilities in the latest Pentia do not use the 80 bit internal representation (which probably disgusts Kahan, but...).

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?

Re:Windows applications

[kbsingh]

Where exactly did you get this figure of 40%?

Correct me if I am wrong, but 40% of all applications on Windows translates to a few hundred thousand apps.

Re:128-bit? Why would we need it?

[raxx7]

Besides the single and double precision formats, the IEEE 754 also loosely defines two classes of extented formats.
A few I know that exist: 80 bit (x87, IPF), 96 bit (Cray), 128 bit (SPARC, Alpha, PowerPC).
The thing is that, as you mentioned, to get IEEE 754 complian behaviour out of x87 you need to store and load back the results. This is because x87 only has operations on 80 bit formats, that yield results rounded to 80 bit. If you want 32 or 64 bit precision, you need to round those results to get IEEE compliant results. And the store/load cycle is the (painful) way to do it. Any IEEE 754 compliant compiler should be able to do this, its not a a GCC specific feature.
SSE/SSE2 extension and other architecures don't have this problem: they have operations that yield properly rounded results to the intended precision, no matter how they work internally.

Re:16 bit raytracing???

[jmauro]

A computer of 16-bits or any arbitrary size can emulate a computer of 128-bits or any other arbitrary size with no difficult (especially at an inifinite clock speed.) It just make take more than one instruction to do the same thing.

C types

[WhiteDragon]

I suppose this is really more of a gcc question, but here goes. Does the amd 64 use a 64 bit pid_t, time_t, uid_t, etc? In my opinion, that is one of the more important reasons to switch to a 64 bit processor.

Re:4GB of addressable RAM ...is simply not enough

[mduell]

A petabyte would be a kilo-terabyte. A mega-terabyte would be and exabyte.

Linux

[Exter-C]

I have recently built up a system based on an opteron processor in a dual processor configuration. I had more problems than i had ever had with other systems initially. However once I upgraded hardware bios's and other things like that it became a good task. Ive since replaced several systems with opterons and all is working well and stable.. note these are servers and have no X.. DB servers and Web / Mail servers. The increased performance is noticable over the last hardware that wasnt that old as well (Dell PE-2650 Dual XEON's 2400mhz etc).