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

[nil5]

wrong.

the conclusion does not follow from truth. a products capabilities do not always ensure its survival. stated another way, the world is not a fair place.

Re:Market Share

[Txiasaeia]

What kind of user base, though? A highly-specialised user base with a ton of cash to spare and who are interested in Linux? Linux has a relatively small market share as it is (compared with Windoze), although certainly early adaptors are included in this group. -1 Incoherent, sorry ;)

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

[Anonymous Coward]

You make it sound like a bad thing.

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

[spikev]

One must not reason out the ability of programming languages to evolve.

Are not all the C variants examples of this?

Re:Market Share

[Anonymous Coward]

What's wrong with having both OS's, or more? Am I the only one that partitions the HDD? Good reason, compare the various distros and OS's on the same box. Example: I have had some problems with my Debian partition, so I reboot into Slackware, or RHL 7.1, or perhaps Arachne 1.70 to see what's what. No, I'm not ashamed to admit that I have Windows 98 here, too, and often run to it for a quick check of something or the other. I've found that my firewall can foul up my dialup connection in Debian real quick. Sometimes I feel like all these distro's on this box is a little like trying to manage a herd of cats. Speaking of cats, I wonder where my little bastard of a cat is now. Inside or Out? (hold on while I check) Oh, there he is, curled up in the chair. Good.

Re:Market Share

[Anonymous Coward]

What's more relevant is that given the length of time the Opteron has been out, only one out of all the distributions could be considered adequate (SUSE 9.0)

Compare with the fact that FreeBSD has AMD64 support and has less people/companies/developers working on this.

Re:Market Share

[PastaAnta]

Well to extend that conclusion:

If GNU/Linux will _never_ lose market share due to evolution it will progressively gain marketshare due to the principle of osmosis.

The circle is complete ;-)

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.

Re:Market Share

[ackthpt]

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

While i realize this is made in jest, competition has proved to be a good thing for the auto industry. Look back on the cars of the late '60s and consider your present car not being much more innovative than that had the japanese gained such a foothold in US markets.

Pitting Linux against Windows is a good thing for Linux and _should_ be a good thing for Windows (though Microsoft has had a habit of innovating by exclusion, i.e. we hold the patents and copyrights.)

Re:Market Share

[Bert64]

Infact, microsoft didnt release a 32bit windows atall until well after other companies (DEC, SGI, maybe others?) had released 64bit OS's and hardware.

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

[Anonymous Coward]

G5 == old and busted. AMD Opteron == new hotness.

Unless Steve Jobs announces 50% price cuts on all the Apple desktop products across the board at Macworld in January I will be buying myself a shiny new Athlon 64 FX-51 setup soon afterwards. The system I can build with the Athlon 64 completely blows away the G5 tower.

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

[Dehumanizer]

You must be thinking about a Geforce FX 5800... :)

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!

Re:Well...

[Anonymous Coward]

It really slows down to 800MHz under light load? That's awesome! I've always wanted to have that in my desktop machine. Right now my CPU is running at 2400MHz and it doesn't need to be. I wish I could buy a 'speedstep' P4 and plug it into my standard motherboard.

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

[Tony Hoyle]

The biggest issue for me when I last tried out some 64bit betas was that the 64bit NVidia drivers suck. They don't have an ioctl32 interface, so if you use them you *must* run 64bit 3d apps - which rules out pretty much anything worth running game wise.

btw. what's the article on about 'new' NVidia drivers? They're dated September 23rd!

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!

Re:whats the deal

[mahdi13]

Might be talking about the 'new' beta drivers
http://public.pny.com/quadro/FX3000g/Linux/
I've heard they are not bad and now have a 'Linux control panel' that allows you to graphicly control all of those sweet little tweaks nVidia loves to brag about

Re:whats the deal

[EvilTwinSkippy]

A big step in that direction are source-based architectures like Gentoo. You don't have to worry about binary incompadibility because everything is custom-compiled.

I say it's a step, because a lot of programmer do unwittingly bias their code for a specific architecture. Inline assembler is also going to be a major pain in the ass, but fortunately we've gone through that before with the PPC ports.

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

[Anonymous Coward]

Sun? SuSE? Funny, I seem to remember hearing Sun had their own OS in development. Called Sol-something... I think it'll be big.

Re:Awesome

[IvyKing]

Sun? SuSE? Funny, I seem to remember hearing Sun had their own OS in development. Called Sol-something... I think it'll be big.

64-bit Linux for AMD64 is out now (mainly since GCC supports AMD64). The rumors are that Solaris AMD64 should be out Summer 2004 (at least summer in the northern hemisphere). The wait is due to developing AMD64 support for Sun's compiler collection (Solaris was written for Sun's C compiler).

Having Solaris support the Opteron may help Sparc sales as it could increase the market for 64 bit software on Solaris - should be a very simple re-compile to prt from one platform to the other.

Re:Awesome

[IM6100]

I remember hearing that Sun's Sol-something operating system is already tested and robust on a 64 bit architecture of some sort. Wouldn't that mean it shouldn't be hard to port over to a new processor, on whose 32 bit version they already have a 32 bit port?

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

Re:Awesome

[Doomdark]

They come with a SuSE derivitve distro. I couldn't tell if its real SuSE or a SuSE Sun optimized.

It's probably Sun's own distro, "Java Enterprise Linux" (and "Java Desktop Linux", or something along those lines), formerly known as Mad Hatter? It is based on SuSE, don't know if it's a spin-off (like Mandrake started from Red Hat), or if they'll stay related.

Re:Awesome

[bigjnsa500]

It was called Sun Linux. Sun shelved it in favor of SuSE (or SUSE, which ever you want to call it.

Re:Awesome

[Anonymous Coward]

and it ran at a useable speed ;)

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

[cgranade]

Well, 64 is better than 32. Just not in the way of faster, nessesarily. I mean, more memory address space, the ability to process 64-bit IDs in one cycle... just is better for those apps written so as to take advantage of it.

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

[Steveftoth]

That's just crazy, you can build a machine that can process 64 bit numbers that still only addresses 32bits at a time. In fact there are many, many vector units have long (64-bit) data handling capabilities. Altivec is a good example of it.

Re:Windows 64

[Anonymous Coward]

Not that I don't believe this could happen, but do you happen to have a link to a story on this?

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

[madprof]

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

Re:Windows 64

[kautilya]

I think the story itself should be modded as "flamebait" :)

Re:Windows 64

[nosferatu-man]

My kingdom for mod points!

'jfb

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

[Spoing]

Do you know if everything is recompiled, or is it bits and pieces, or is this another Win98 32 bit in places with 16 bit in others?

(Everything includes drivers, libraries, through to applets, databases, and Office itself.)

Re:Windows 64

[Steveftoth]

Why is it SAD that computers will need to address more then 32-bits worth of space?

I mean for simple word processing it's overkill, but then again so it anything more advanced then an electric typewriter.

As we move more and more content into the digital realm we realize that in order to effectively manuipulate it, we must have more power.

Tivo would not be possible with 16-bit processors. It requires more power then a Commadore 64 or any 16-bit computer can produce.

Re:Windows 64

[Anonymous Coward]

Office isn't integrated with Windows. You must be orifices? *G*

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

[Anonymous Coward]

Tivo could be done with 16 bit processors- it would just take more work, and more clock cycles to get the job done.

If I had a choice between a 16 bit processor running at infinite clock speed, and a 128 bit processor at 2 Ghz. Gimme the 16 bit one- and I'll do realtime raytracing.

Re:Windows 64

[Anonymous Coward]

Back to work, Microsoftie! Get busy on that 64-bit port!

Re:Windows 64

[Anonymous Coward]

well, sure, whoopedy do, wouldnt we love that...

dummy

Re:Windows 64

[kautilya]

Anonymous Coward.. Back to work..yepp! but to install Debian and run some simulations on linux cluster.

Re:Windows 64

[Anonymous Coward]

Sadly? wtf?
What is sad about machines dealing with more data?

Re:Windows 64

[ImpTech]

Funny about that console wars bit... of course, afaik there's nothing 64-bit about the latest consoles (certanly not the xbox anyway, and I'd be surprised if the gamecube is either). Just funny how that whole marketing gimmick kinda disappeared after the N64. And now AMD wants people to buy into it. Not that I'm complaining about 64-bit cpu's as a concept, just that stupid marketing crap.

Re:Windows 64

[Codifex Maximus]

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

I agree! While Intel is playing catchup, I suppose AMD Opteron *will* be taking over the server x86 processor based market. If a Windows server OS is not ready for those processors, I guess folks will just jump on the Linux or Solaris bandwagons.

After all, initial adoption of these processors will not be by home users but by commercial entities. Delaying a release of Windows 64, to benefit Intel, would only hurt Microsoft.

> Useful or not, console wars has caused "64 bits
> to be better than 32".

True. 64bitness is long overdue. The Opteron may be the processor that causes the dyke, holding 64bitness back, to break.

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

[Anonymous Coward]

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.

Where did you get this? Last I checked, MMX could only process 64 bits of data at once.

Re:Windows 64

[umeboshi]

with an infinite clock speed, you can do realtime time :)

Re:Windows 64

[psavo]

Yeah, except that you can get 64bit windows for Itanic right now, but not such luck for Opteron.

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

[jmauro]

You're right, my bad. The idea is correct, but I shouldn't of lumped SSE/SSE2 with MMX.

Re:Windows 64

[Anonymous Coward]

I did mention that PAE only allowed 4GB per process. I agree it is a hack - but a useful one.

I think PCI-Express, Hypertransport and PCIX-133 are big steps forward - I think you will see more "real" slots in the Opteron systems than the mostly junk slots you get with today's P4 (Xeon systems seem to have decent PCI slots in them) and particularly the Athlon boards. I think in this transition they will have time to revamp how this all works.

I believe the underpinnings will be better mated to these new CPUs, just as Fire (and UPA) is in Sun GX in Power4/4+, we now get Hypertransport and a better pathway. It's getting closer to real IO - this is what I want out of the deal.

Think of it this way, SPARC and SPARC64 are a lot more than just 64-bits different. I think this is another evolutionary change in computing and it's more important that memory addressability alone.

I advocate the move to 64-bit, but hope to get a lot more out of it than just massive memory addressability, though this is a compelling reason to move.

PC's have been more than adequate for the roles they fill today for some time. The real stuff was done, and will continue to be done on heavier stuff. It is nice to see heavier stuff like the Opteron trickling down to being within reach of the common, more low-end server and computer. I think you get a lot more out of a heavy hitting box than a bunch of ram. I've proven it to myself with various boards and high speed network IO, all motherboards and the chipsets that surround a CPU are not the same, and it tends to be that the heavier hitting the CPU is (which also tend to be 64-bit, SB2000, Alpha ES47, Power 4+, etc) have a lot more beef to handle viscous amounts of IO. I can easily kill a desktop style PC and most 32 bit "servers" with IO, and a lot of it has to due with various inefficiencies I think the Opteron will alleviate.

Re:Windows 64

[MechaStreisand]

Exactly how can Intel make Microsoft do anything they don't want to do?

Re:Windows 64

[Anonymous Coward]

I run a few GB on my desktop alone, VMWare and VPC have 1gb limitations on virtualizations tho on the workstation editions.

When I go 64bit 2 way workstation, ill have min 4 gb.

Wait until we get shared networkable memory for distributed applications, watch the demand skyrocket for memory.

Serious power is indeed in the home and no longer in the coroprate desktop.

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

Re:Windows 64

[Slime-dogg]

I don't see any reference to the audio streams coming from the internet. Streams happen all over the place, and are used extensively for many different applications. An audio editing studio, for instance, will use audio streaming.

What they're saying is that with the increased bus, you won't see a clog in the bandwidth if you are working with high definition audio and video. It makes sense, and really isn't something to rant about. This looks more like an ad that is targeted to Hollywood / Weta Studios types of people, but could be interpreted as being for the consumer.

Re:Windows 64

[Steveftoth]

With infinite clock speed your electrons wouldn't be able to move. Thus you would never get any information in or out of the chip. (even if you could get infinite clock speed) Also clock speed is in no way related to the 'bitness' of a chip, so if you could have an infinite clock speed chip it wouldn't matter what 'bit' it was.

Regardless your point is nonsense because there are real limitations to how things work.

The reason that bits of chips keep increasing is because we keep doubling the transistor density, and lo and behold it's better to be able to actually process 128-bits of information at once if we actually want to be able to process that much information.

True, you can do math on 32-bit (or really any length of bits assuming lots of ram) numbers with only 16-bit ALUs, but its obsiously more efficient to do it with larger ALUs.

Re:Windows 64

[Anonymous Coward]

And for the "new IO" features of 64-bit computers, are there any?

The SMP Opterons (2xx, 8xx) have built-in routers for HyperTransport messages.

The only real reason for going to 64-bits is memory addressing.

One additional reason: double-precision floats can fit in the general purpose registers. That really helps reduce the insane register pressure in the IA-32 family, making math-intensive code run faster, and reducing the hairy register renaming stuff the CPU has to do behind the scenes.

moths

[Anonymous Coward]

A few moths ago

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

Re:moths

[Anonymous Coward]

eventually they'll work all the bugs out.

Re:moths

[Anonymous Coward]

Sure, you put the "n" back in and you get "months". The "n" is the last letter in "Opteron" which is, apparently, the last word in 64-bit processors. Microsoft doesn't need any Opterons around, or they might have to pronounce the resultant OS as having been developed by Nicrosoft. or perhaps in the spirit of Benefer, Micropteron. (Ok, I know this stuff is lame, but these one-liners are best presented by someone like Jay Leno. If you read his monolog from last night on the internet, then even his stuff seems lame, unless you are there when he tells the joke, etc. Believe me.) Ok, if you don't believe me, go out and buy an Emachines with a 64-bit processor and spend all eternity getting something worthwhile to run on it.

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

[timeOday]

I'm disappointed at the lack of any impressive benchmarks from the Opteron. I can only assume that the Opteron really isn't any faster than the P4. The extra address space might be nice though, for programmers at least.

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.

Re:FYI No benchmarks

[bluGill]

The extra address space is nice. However most apps aren't programed to take advantage of 64 bits, and many couldn't benifit from it. Don't expect any improvent in times to do 2+2, because on either both numbers fit into your native data size. Expect massive improvements when adding 6 billion to 6 billion though.

Re:FYI No benchmarks

[Serveert]

It could speed up searching if you can compare 64 bits at a time, so databases should in theory be faster.

Re:FYI No benchmarks

[donnz]

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!

Won't it be a capital expense and still be counted as taxable profit? Gotta love the taxman.

Oh, sorry, was that OT?

Re:FYI No benchmarks

[Serveert]

I just fiddle with computers and do what I'm told to do, who knows! :)

Re:FYI No benchmarks

[LWATCDR]

Are you running a prr compiled 32bit version of MySQL or a recompiled version or some new 64-bit version?
How much ram and how big of a db?

Re:FYI No benchmarks

[beguyld]

Won't it be a capital expense and still be counted as taxable profit? Gotta love the taxman.

Not necessarily. Up to $100K of capital equipment per year can often just be expensed for a small business. Used to be $25k, but it was just increased to $100k for 2003. This is called the Section 179 Expense Election. Some of the details of the recent changes are here

But of course, it's a tax law, and so there are lots of details to investigate. This overview can even seem misleading about the 100% deduction because it is taken out of context of the entire Section 179 rule. So the actual documents need to be consulted (or even better a tax professional). But the deduction is real, and almost every small business takes advantage of it (it starts to phase out over $400k of capital expenses).

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

[Anonymous Coward]

And it's all irrelevant. *BSD is dead!

Re:Opteron and *BSD

[Anonymous Coward]

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

Hold on a minute, there is no "other hand". AMD64 is not officially supported yet on NetBSD either:

It will be a completely supported platform in the next NetBSD release.

Gee, that's what FreeBSD says as well.

Re:Opteron and *BSD

[Ancient Devices King]

I am confused by that link... perhaps you can clarify. The only 64 bit x86 CPU out in 2001 was the Itanium, and in fact, that site says that the 64 bit NetBSD fork was originally called "NetBSD/x86_64" and only renamed to "NedBSD/amd64" this year. AFAIK, IA64 and Hammer are not the same instruction set. How does this work, since the original 64 bit x86 NetBSD could not have been based on AMD64?

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

[endx7]

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

So NetBSD supports it before AMD even -officially- released it? The specs and emulator(s) have been around for a while, but I seriosuly doubt you could even get AMD's 64bit processors before this year (or possibly maybe even last year, but still, 2002 > 2001).

Although, there could be a blurring of lines on what 'support' means. I look at 'support' as being able to be sure it's stable, and problems are minimal (or non-existant). This is basically what defines (as well as a few other factors) a tier-one platform on FreeBSD.

Check the release dates for the Athlon 64 and Opteron.

Re:Opteron and *BSD

[Hoser McMoose]

IA-64 is in absolutely no way related to the AMD64 (aka x86-64) instruction set. In fact, it has absolutely zero relation to the IA-32 instruction set, depsite the similarity in names. IA-64 is a complete new beast. There currently are and only ever have been two 64-bit x86 CPUs, teh Opteron and the Athlon64 (and you can easily count those as just one chip, especially considering they come from identical dies).

The support for AMD64 was only first added to the NetBSD kernel in 2001, much like it was first added to the Linux kernel at about the same time. This work was done on simulators and it was in no way fully functional. In fact, the port is still not officially supported, though apparently it works reasonably well, even with 32-bit x86 code, which is the real tricky part about AMD64 operating systems. Simply porting to AMD64 is just like porting to any other architecture, but setting up some form of dual-architecture system is what has complicated development, both in Linux and in *BSD (a lot of the kinks are still being worked out). On the upside, once this work is done and working for AMD64 it should be much easier to get it working on other operating systems.

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

128-bit? quantum computers?

[Anonymous Coward]

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.

well?

Re:128-bit? quantum computers?

[auzy]

quantum computers are 255 qubits I think.. and thats per "transistor". On a true quantum computers, boolean logic is kind of pointless too because it only utilises 1 bit at a time, when more could be done at least from what I've heard

Re:128-bit? quantum computers?

[nil5]

ummm.. theoretically a quantum computer can have any number of qubits. we should draw the line between conventional computer architecture and "quantum computers", since the latter has hardly evolved to anything resembling a practical architecture. it will be some time before this becomes relevant.

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: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:128-bit? quantum computers?

[Ancient Devices King]

"640k should be enough for anybody!"

By that logic, it should have been 64 years between switching to 32 bit from 16 and to 64 from 32. When did x86 finally switch from 16 bit to 32 bit? I don't think it was in 1971.

More addressable memory isn't the only benefit of having more bits per CPU, and even if it were, I think your estimate for how fast things double is off by at least a factor of 2 or so.

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.

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.

Re:128-bit? quantum computers?

[Lumpy]

I'm still somewhat amazed that my office workstation has over 20,000 times more memory than my first computer.

no that is not amazing... What is amazing is that my Desktop workstation has 2,000 times more RAM than my first computer had in HARD DRIVE SPACE!

Yes that is a real wake up call... remember when you were thinking you were on top of the world with 10 meg of hard drive space with that 8 inch wide hard drive.

But then the Unix I was running (Cromix) fit on a 720K 5.25 inch floppy.

Re:128-bit? quantum computers?

[Anonymous Coward]

Sure you can do that NOW!

128bits...get the PlayStation2 dev kit. The GPU is 128bits. Mostly, tho, you use 2x64bit words in parallel.

RISC MIPS is kewl.

JoeR

Re:128-bit? quantum computers?

[Space cowboy]

I'm not an expert on these things, but I'm not exactly clueless about the PS2.

The MIPS R5900 is a 32-bit chip, but that's not where the heavy lifting happens anyway - it's just there for game logic and overall control. Trying to define "the CPU" of a PS2 is an exercise for drunken engineers, anyway :-)

All the real work goes on in the vector units (vu0 & vu1) which are decidedly 128-bit. They can pack 4 32-bit floats into a single register, and process those registers in one clock cycle (with a 4 clock-cycle latency within the pipeline).

I'm also not sure why it should take longer to access a 64-bit value in RAM than a 32-bit one, assuming a commensurate increase in data-bus size for the new processor... Unless you mean that you could fill the L2/L3 cache with 2 32-bit values within the same time-frame as a single 64-bit value, now that you've got a larger bus width...

Simon.

Re:128-bit? quantum computers?

[Anonymous Coward]

http://www.eetimes.com/issue/semi/OEG20030317S0034

Transmeta has a 256-bit CPU for the "mine is bigger than yours" crowd.

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

[nexex]

You're basing you decision on whether or not it can run Seti@home?? I don't see how something like that could possibly be a deal breaker...

Re:Seti problems with x86-64 kernel

[Anonymous Coward]

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.

Just curious what average times you are getting with the AMD64 to complete each SETI packet, and also exactly what model of AMD you are running? Not looking to get an AMD64 for running SETI@Home here, just curious on how much of an improvement it might get with the new processors, for down the road possibly. Also, I always like looking at the best times for SETI@Home. Get about 3.5-4.0 hours average on my AMD 2000+ XP systems :)

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.

Re:Seti problems with x86-64 kernel

[(H)elix1]

You're basing you decision on whether or not it can run Seti@home?? I don't see how something like that could possibly be a deal breaker...

This is not as bonehead as it seems. I'm still digging though a bunch of C++ code that compiles on the 64-bit zSeries Linux, but segfaults on this platform. Something as silly as an Apache module - go figure - that works just fine on x86 and ppc. When 'normal' stuff does not run transparently, it makes you start second-guessing everything. A deal breaker if reliability is a must... never forget the first in get to coat the 'bleeding edge'.

Re:Seti problems with x86-64 kernel

[ComputerSlicer23]

Wait a second... You can't afford a $130 distro, but you can afford a dual opteron based computer? Hell, you probably dropped $1.5-2K on the server, and didn't consider what you'd do for an OS.

I thought that Fedora had a development version of a 64bit version for the AMD processors. I could be wrong.

Kirby

Re:Seti problems with x86-64 kernel

[Alizarin Erythrosin]

A few months ago, I bought the parts for the server and put it together (it was $3500 btw). I was (and still am I guess) a Linux administrator noob so I didn't know if I would be able to configure the server in the way I wanted to (it's a file server for my home network and will eventually be a way I can get my files at work too).

That was then, this is now. Bills (new car, Christmas) dictate that I can't spend money on something I don't know will absolutly work first. Plus, the stuff is still mostly in beta. After the new year when I get more of a choice I'll probably get one.

Re:Seti problems with x86-64 kernel

[AvitarX]

You must have some pretty intense file serving demands at home to be using a 3500 dollor computer as your file server.

Re:Seti problems with x86-64 kernel

[Anonymous Coward]

two words of advice:

plan better.

also, if you're a noob in something, ask around, and try to get people to give you serious answers, not pie-in-the-sky, "it would be cool if..." answers. don't pay any attention to linux admin wannabees who haven't run > 50 machines and had > 1000 users and most importantly a tight budget. a dual opteron machine is extreme overkill for home fileserving and most business file service. i've served terabytes of data to tens of thousands of active users off less. file servers don't do much processing. they wait on IO. your money would have been better spent on storage (fast SCSI disks, RAID controllers, backups, whatever).

you can run most linux services for personal use off computers you can find on the street. if you want things a little zippier, buy something used. there's no point in buying new equipment if you have less than a dozen users.

take the dual opteron and make it your workstation or something. the typical use for such a box would be as a DB server (you can put lots of RAM in it), but i doubt you could stress it enough to warrant that.

Re:Seti problems with x86-64 kernel

[bersl2]

Slackware gives you the compile scripts it uses to build its base packages. How hard can it be to bootstrap a two-pass, "Pure LFS"-Slackware hybrid distro? You'll need some time, 'cause it won't be automated...

Personally, I'm currently lusting over a dual Opteron box for my next comp. <drool />

Re:Seti problems with x86-64 kernel

[Anonymous Coward]

SUSE 9 AMD 64 is even free as in beer. Read this: http://www.x86-64.org/mailing_lists/list?listname= announce&listnum=0

Re:Seti problems with x86-64 kernel

[Anonymous Coward]

pr0n!

Re:Seti problems with x86-64 kernel

[Anonymous Coward]

Naw, he just bought Apple hardware.

when dual-64 will hit the shelves?

[Janek Kozicki]

I'm anxoius to buy myself a brand new dual opteron toy (it will be worth replacement for my good 4 years old abit VP6 with dual P3).

now, I just wanted to ask if anybody has a clue when I could expect them in my retail store...

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: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:when dual-64 will hit the shelves?

[DrMindWarp]

About 2 months ago in quantity. I have one running 64-bit SuSE with more to come in January.

Systemax, for example, are selling dual Opteron servers/workstations off-the-shelf and will tailor the equipment to your needs. Least they did for me. Was much cheaper than the equivalent dual Xeon too.

Re:when dual-64 will hit the shelves?

[Anonymous Coward]

I know you probably don't consider it retail, but boards that support dual Opterons are already out there.

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.

Yes, bu...

[The Human Cow]

...Oh. Nevermind.

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

[Ancient Devices King]

That was confusing for me too, but I think s/he's saying that the Mac and x86 hardware haven't changed much in a long time, but now we're getting 64 bit Macs (G5) and x86-64 (Opteron/Athlon64), which the closed source software makers (ie Microsoft) are having trouble with, while the open source ones (Linux developers and Apple through Darwin) aren't having the same issues.

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

Re:hurdles

[bmajik]

this is horse shit. linux has been working to get 64 bit clean for almost its entire existance. dont pretend that AMD releases a chip and that over nite, linux is magically 64 bit clean and running error free on it. surely you remember the 64 bit alpha ? the majority of 32->64 issues were hashed out on that architecture..

IRIX was 64 bit clean before linux was. And Windows was running 64bit native on AMD64 before you knew there was an AMD64.

Both of these are closed operating systems.

Re:hurdles

[potpie]

Perhaps "feverishly" was a bit misleading, but it is also a matter of demand. Only now that the chip is on sale in your local CompUSA will there be an actual demand for systems that can run on it. While they may have all been working on it before, now they're going to be finishing it. Well, the closed source producers will be finishing it; the Open Source developers will always be updating it.

What I'm trying to say is that the jump from 32 to 64 is going to be a very important moment in the history of Open versus closes Source development. Stop focusing on the timing of it.

Re:hurdles

[Anonymous Coward]

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

You know absolutely nothing about what you are talking about.

The Mac OS has gone through several major changes in the past ten years. The first one was a port to a completely different architecture (from m68k to ppc) complete with full emulation for applications written for the old architecture at their original, a feat that has been rarely duplicated (such as DEC's FX!32.EXE for WinNT for Alpha) and has never AFAIK been reproduced by open source. Then there was this little merger with a company called NeXT that led Apple to replace its entire OS code base with Mac OS X's BSD/Mach underlying structure. That's hardly nothing changed, yet all m68k code could be simply recompiled for the PowerPC with only a change in configuration files, and over 90% of Mac OS 9 code could be recompiled on under Mac OS X via the Carbon libraries without a hitch.

You also rapidly forget early Windows NT, which was designed to be ported and had versions running and sold on x86, Alpha, MIPS, and PowerPC. Let's not forget that NT was also a completely new core to replace the old core of Win 3.11/DOS, yet porting between Win16 and Win32 code was only about as hard as porting from Win32 to Win64 will be.

Now, if you think porting an app only designed for the 32-bit version of Linux or some UNIX variant to 64-bit version is trivial, you should get your head out of the sand and try it sometime. OSS has no inherent advantage over proprietary software in doing 32-/64-bit ports. The only real advantage you can have is the age of your code and how many legacy APIs it calls.

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)

Re:The conclusion...

[Anonymous Coward]

Suse Professional 9.0 $120 (distribution on DVDs, no CDs)

That is a bit misleading. Here are some quotes right off of SuSE's website:

Scope of the Personal edition ($39.95): 3 CD-ROMs, 1 manual (User Guide), 60 days of installation support

Scope of the Professional edition ($79.95): 5 CD-ROMs, 1 double DVD, 2 manuals (Administration Guide, User Guide), 90 days of installation support

If it took him 2 hours to install SuSE using an FTP server then it would take even more time to download 5 ISOs. It would make more sense to either buy the CDs right from SuSE or make copies from someone who did buy them. The last option is legal as long as you aren't charged any money for the copies.

FYI.. SuSE 9.0 is available on the bittorrent network..

http://66.90.75.92/torrents/450/SuSe_Linux_9.0_C omplete_5_CDs.torrent

http://69.93.27.190/~suprnova/torrents/704/Suse Linux v9.0 Professional DVD Version DVD1_seeded_by_inside.nrg(1).torrent

http://69.93.27.226/~suprnova/torrents/712/Suse Linux v9.0 Professional DVD Version DVD2_by inside.nrg.torrent

With that being said, I bought SuSE Professional. Please support your Linux distribution whether it is SuSE, Debian, Slackware, Gentoo or Mandrake. If they offer free ISOs then buy their CDs anyway. Stop being so damn cheap =P

That's because

[Anonymous Coward]

64-bit users can use longer words...

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.

Re:Speed vs Memory

[Anonymous Coward]

It seemed weird to me, too. Hurl all that expensive nice hardware at what's really a software problem.

Re:Speed vs Memory

[ArkiMage]

Not OS caching, I wasn't clear previously.

set-variable = innodb_buffer_pool_size=7000M

Re:Speed vs Memory

[Anonymous Coward]

How about SPEED OF MEMORY.

Even with LESS than 4GB of RAM, SMP Opterons can significantly perform better than their 32bit x86 SMP counterparts. Mainly, this is due to their Integrated Memory Controllers...

Rather than sharing a "single" dual channel memory path, EACH CPU get's a dual channel memory path, with hypertransport links between the individual CPUs. Couple that with a full 1MB of clock speed L2 Cache (not L3) and a NUMA aware OS (Linux, Win2003/32bit), and the common x86 memory bottleneck can be significantly relieved (not to mention the lower latency to memory).

For 2-8 way systems, Opteron is the most scaleable x86 system on the market.

Re:Speed vs Memory

[chez69]

Windows is not NUMA ( non uniform memory access) aware out of the box.

skimps on redhat and fedora details

[buck68]

The article mentions near the beginning that he tried Fedora, but says nothing more as far as I can tell. He says scarcely more about Redhat. In the Suse rant section, he does complain about Redhat's pricing model being out of reach, but since he's a Ph.D student, I must assume that he is unaware of Redhat's recently announced educational pricing (which is pretty cheap).

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

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.

Re:Compatibility-performance fallacy

[Anonymous Coward]

In fact the old 32 bit programs will NOT make use of those registers- unless they are recompiled with a compiler that know about them.

In general 64 bit code can move more data in one operation than 32 bit code, twice as much. And 64 bit integer math can be done faster than on a 32 bit CPU, and of course it can address more memory without crude hacks like segment selectors and descriptor tables. (though it may have them for compatability and OS security)

Anyway I'll be upgrading as soon as I have the money- Linux all the way baby!

Re:Compatibility-performance fallacy

[Anonymous Coward]

Riiight! From the article...

Benchmarks so far have showed only a small difference between the Opteron and the Intel Pentium 4/Xeon.

But what he neglects to mention is the clock rates. The benchmarks I have seens were with Xeon 3 GHz against Opteron 2 Ghz and, yeah, they were neck and neck. To me, this says that the Opteron is performing about 1.5 times better, clock cycle for clock cycle. The Opteron is brand new and at the beginning of it's life. The Xeon is, at best, midway through its lifecycle.

Re:Compatibility-performance fallacy

[Hoser McMoose]

To me, this says that the Opteron is performing about 1.5 times better, clock cycle for clock cycle

Whoop-dee-shit! Who the hell cares what clock speed the chip runs at. The only thing that is important is either the maximum performance where cost is no object or the maximum performance for a given price point (and also sometimes the maximum performance for a given power consumption level). How the chip manages to achieve that performance is of basically no relevance at all.

The P4/Xeon's NetBurst core was simply designed to clock high. On a 180nm fab process Intel managed to clock their P4 up to 2.0GHz with little trouble at all. On the same 180nm fab process, Intel was only able to get their PIII up to 1.13GHz, and that took quite a bit of work (the first 1.13GHz PIIIs actually had to be recalled). AMD's Athlon was designed to clock higher than the PIII, but not as high as the P4, so it managed to get up to 1.73GHz if my memory serves me correctly.

We're seeing the same thing now with current 130nm manufacturering processes. The P4 and Xeon are able to clokc to 3.2GHz, while AMD has only managed to clock the AthlonXP up to 2.33GHz (and that only in small quantities, only available through one specific HP machine). The Opteron/Athlon64 core might end up clocking a bit higher (especailly since they're using a very advanced 130nm SOI process as compared to the bulk CMOS process that was used for the AthlonXP and all of Intel's processors), but for the time being it's limited to 2.2GHz. It's likely that AMD will be able to hit 2.4GHz and maybe even 2.6GHz, but that's about it. The chip just wasn't designed to clock as high as the P4/Xeon.

Design decisions were made by both AMD and Intel. Intel chose a sort of "narrow and fast" design, and took a "wide but slow" design so to speak.

Debian port infomation.

[bjarvis354]

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

Re:Debian port infomation.

[Ian Bicking]

No reason to use HTTPS for this link. Be nice to the server: HTTP link

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?

[Aviancer]

Nope, that's not the only reason for 64 bit native. Where I work we do a lot of financials. To do that accurately, we typically count pennies in an integer type. It's very easy to go over 2.1 gigapennies, so we try to use a 64 bit type. In a 64 bit archetecture, we don't incur thunking overhead.

Re:What about 4GB?

[Jeff DeMaagd]

The ability to flat-address more memory is nice, but not necessary to take advantage of A64 performance.

Most 32/64 bit hybrid architectures lose speed when going from 32 to 64 bit software due to losing bandwidth to storing pointers.

AMD64 actually has an advantage to offset that in the fact it doubles the number of registers in 64 bit mode, so even code that doesn't break the 4GB barrier has a chance of running better.

Re:What about 4GB?

[Nothinman]

>4G physical memory isn't always the selling point, you can cram more than 4G memory into many 32-bit systems right now. The big thing is the >4G VM space of the 64-bit architecture which doesn't always map to physical memory, things like mmap()'d files, shared libraries, etc take up VM space too, so an app can need more VM space without needing more physical memory.

Your problem was hardware related and I doubt their 'findings' would have been any different unless they were testing things like Oracle that would actually use that extra memory.

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?

[Saeger]

So you're an online shoe salesman? I have a joke! ... No, that would be too easy.

--

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.

Re:What about 4GB?

[pD-brane]

Do shoe salesmen really earn that much to be able to buy Opterons with 8 GB of memory?

Seriously though, why do you need more than 4 GB (!) of memory in a computer in a shoe shop?

Re:What about 4GB?

[Anonymous Coward]

At my company we built a 8 processor 4 node cluster of opterons to run finite element modeling. Big Memory being the motivation. The limiting factor was finding a fortran that ran in 64 bit and the only one out there ran only with the SUSE distro. We also had a motherboard burn out. I think the main hurdles to a 64 bit world is catch up right now theres only one choice when it comes to alot of things.

Re:What about 4GB?

[localman]

But you can easily do 64 bit math on a 32 bit CPU. I do this all the time. It won't be quite as fast, but unless you're doing a whole hell of a lot of calculations it's just a mild bottleneck.

The memory issue is a real dead end, though. You can't (in my knowledge at least) get past the 4GB limit on a 32 bit CPU (or more specifically a CPU with 32 bit memory addresses).

Well, I guess if you count virtual memory you can. But the penalty there is much larger than for doing 64 bit math on a 32 bit processor.

Cheers.

Re:What about 4GB?

[localman]

Oh, and actually, to correct myself: even if you can get past the 4GB thing with virtual memory, 32 bit Linux at least won't let a single process to exceed 2 GB (or with some patches 3GB). Get too large and the kernel shuts you down. Bang. This happens pretty easily with MySQL.

Cheers.

Re:What about 4GB?

[localman]

Yup. I'm the Al Bundy of the internet :)

Oh, and I'm employed and the company is doing great :)

Re:What about 4GB?

[localman]

Right -- the real problem was that our MySQL process couldn't be configured to stay under 3GB and perform adequately in our setup. If it goes over 3GB the OS takes it down.

We eventually found workarounds, but in any case the first round of Opteron offerings were very green. "Duh" says me after months of trouble. I'm usually not the type to take the plunge on untested hardware/software/whatever for anything critical. Now I remember why :)

Cheers.

Re:What about 4GB?

[localman]

Let me be the first one to say that I laughed my ass off when I first interviewed at Zappos.com. They made me a good offer and I took the job thinking the company might last six months.

That was in the summer of 2000.

Since then they've doubled their business every 8 months. We've been profitable since Q4 2002.

Our DB handles > 200 queries per second, and that's after substantial webserver caching.

Crazy but true :)

Cheers.

Re:What about 4GB?

[cabbey]

If you want address space get the heck off of intel related processors!!

http://www.penguinppc64.org/

I've got a system at work with 12G of physical memory right now. I've had accounts on test systems with as much as 32G of physical memory. I think the max is 512G. Yep, http://www-132.ibm.com/content/home/store_IBMPubli cUSA/en_US/eServer/pSeries/high_end/pSeries_highen d.html
shows 512G of mainstore max.

p.s. the sandels I bought from zappos a few years ago are still with me, great site! :)

Re:What about 4GB?

[p3d0]

Ok, so you're reduced to a 32-bit physical memory space, so you think you could have used a Pentium. Take solace that (a) the Opteron has twice as many registers as the Xeon, (b) it has a 128k L1 cache (versus around 32k for Xeon), and (c) assuming you have a 2-way SMP, you have more memory bandwidth than a Xeon.

I'd be surprised if your machine doesn't outperform a similarly-priced Pentium box, even with only 4GB of ram. (Wow, did I just say "only 4GB of ram"??)

Re:What about 4GB?

[localman]

Clock for clock it does outperform. We went from a dual Xeon 2.4Ghz to a dual Opteron 1.6Ghz (fastest at the time). The performance was roughly the same: some operations were faster, some slower.

But we were never CPU bound, so even if it was faster it wouldn't be much help.

In the end, I think we'll stick with the second generation Opteron setup for the coming year (as opposed to moving to IBM or Sun) but the memory issues were quite a let down nonetheless.

Cheers.

Re:What about 4GB?

[p3d0]

Yes, clock for clock it outperforms, but that's not surprising as there are few modern processors that do less per clock than a Pentium. They survive on stratospheric clock rates.

Too bad about the memory size. Hopefully, you have a good upgrade path to hardware that lets you get past the 4GB mark.

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?

[Tony Hoyle]

I'm actually surprised he got gentoo amd64 to compile.. the last time I tried (just last week, actually) it couldn't even compile a stage 3 due to compile errors, let alone get as far as X.

Debian is months away from a stable distro (waiting on dpkg and apt upgrades to support multi-arch installs) and I'm damned if I'm going back to RPM... it's 64bit hell out there :)

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

Re:heh?

[loki-yo]

Suse's kernel version is only 2.4.21 inthe numbering, it's a very heavly pathched kernel. With lot's of backports from 2.6 that are not on the vanilla 2.4.23. (as a side effect it's was already pathched against the brk() bug when it was discovered )

Re:heh?

[Luyseyal]

Cause Debian is the only dist bothering to do it Right[tm]. :)

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

[Anonymous Coward]

Not just .NET, of course. Java will benefit equally from its virtual machine architecture and just-in-time compiler.

Re:.NET

[Keeper]

You're assuming someone ever gets around writing one...

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

[Anonymous Coward]

Gotta love coward moderators who mod anything slightly MS related down. To the mod responsible: nice one you coward.

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.

Linus and BIOS usage?

[Anonymous Coward]

The article says the author blames a BIOS update on his ASUS motherboard for Mandrake's troubles with the 80Gb disk drive. ??? - I thought Linux bypassed the BIOS for I/O, that only the bootloaders use BIOS calls for disk access..

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.

Re:Linus and BIOS usage?

[Anonymous Coward]

Umm... perhaps you are forgetting hdparm? You indeed can tweak the speed of IDE data.

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.

Fallacy fallacy

[hacksoncode]

Ummm... those 32-bit compiled programs aren't exactly going to be making use of those extra general purpose registers, you know... register allocation is (mostly) done at compile time.

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.

Powerspec 64 bit machine anyone?

[Dove19]

http://microcenter.com/search_results_e_compare.ph tml?coordinate_group=E1A6+E1C6 Hey, not sure about this, but how is powerspec related to emachines... cause apparently they are releasing a 64 bit machine too.... check it out

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.

I believe its because of testing/porting

[Anonymous Coward]

They want to port every task to 64-bit and test it. That takes time. Compare this to Apple's system, where only the kernel was changed.

Me, I'd rather have a 64-bit system through and through with 64-bit APIs a little later than have a lousy solution right now.

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.

SuSE? Beta Software?

[Czernobog]

I just stopped reading there. This was the last thing I will ever read OSNews. Until I hear they have got rid of their dogmatisms and their heads out of their respective asses.

Re:SuSE? Beta Software?

[Anonymous Coward]

I tested the _beta_ version of Suse 9.0.

And you will never read OSnews again because
of that? Heh, probably for the better in that
case...

Re:SuSE? Beta Software?

[Anonymous Coward]

What on earth does this mean?

Not Opteron's Linux Compatibility...

[Alphanos]

Robert Minvielle put to test AMD's Opteron regarding its 64-bit Linux compatibility.

I don't mean to nitpick, but probably the story submitter meant linux's Opteron compatibility? I don't think it's the job of the Opteron to support linux:P.

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.

Opterons and SSE2

[OneArmedMan]

I thought I read at some stage that people were compiling 64bit + SSE2 optimized code on the Intel Itanium CPU's then running the code on Opteron servers and seeing insainly large performance benifits.

Sound familiar to anyone?? Or did i just imaging the whole thing.

Re:Opterons and SSE2

[Anonymous Coward]

It would be really impressive if they managed to do that since the Itanium and Opteron instruction sets are radically different. Some did use the P4/SSE2 optimizations of a recent Intel compiler to speed up the Opteron, but that was all about 32-bit code.

PathScale

[bstadil]

Pathscale by former SGI'er does just that.

Country Of Origin

[paranerd]

I don't want to be a jerk about another OSNews article but will somebody please either tell me that OSNews is published in a nonEnglish speaking country or explain to me why Slashdot continues to link to thier articles? I consider content more important than style, but I find OSNews articles barely readable.

Re:Country Of Origin

[Anonymous Coward]

ya i agree, thoze nonEnglish have probleems with thier speeling, rendering them barely readable, an all.

Re:Country Of Origin

[paranerd]

Did you read the article? Who gives a crap about spelling? I'm talking about comprehendible writing. There's at least 5 postings on this page complaining that the author has said exactly the opposite of what he meant to say, or that the article contains numerous sentences written so poorly that they have become meaningless. My veiled complaint: That seems to be the norm for OSNews articles. And I don't like being directed, through links, to such a poorly written journal.

You're a troll to try and make this out to be a cultural issue.

If OSNews is published by people for whom english is a second language then fine, I'll not complain about the difficulty I have reading thier articles. Otherwise, I'd really rather Slashdot not link to OSNews, Cowardous Troll.

Re:Country Of Origin

[-tji]

I've never been particularly impressed with OSnews articles. But, this one seems unusually poor. The writing was terrible, and his testing (or at least his description of his testing) was useless.

you're missing a lot

[Anonymous Coward]

h, l, etc.

Hungarian also included prefixes for the size of the item. Which pretty much led to the downfall of Hungarian. You had to rename all your variables every time you changed what type they were. Pretty dumb.

Re:you're missing a lot

[Anonymous Coward]

Actually, the need to change your code when you changed the type was kinda the point. It was a sort of type safety measure, which is complete stupid since we get that anyway when using type checking compilers and prototypes. Maybe it's some sort of weird Pascal thing.

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:you're missing a lot

[Anonymous Coward]

Pascal is a very strongly typed language. Hungarian notation was a response to the deficiencies in C. [K&R] C is not a strongly typed language.

Re:you're missing a lot

[Ben Hutchings]

Many people at Microsoft seem to have adopted a form of Hungarian notation without really understanding it. As you say, prefixes like "dw" or "ul" are quite useless; the prefix on a variable name should convey the purpose of the variable and not its concrete type. File positions should have a prefix like "pos". Handles should have a prefix of "h" plus something indicating what type of thing they are handles to.

Re:you're missing a lot

[chthon]

SPOT : Single Point of Truth

I have been using Hung. not. a year or ten ago, and the first thing I noticed was that if I changed the type, I must change the name of the variable everywhere.

Second, there are some languages which do not use explicit types.

Third, when using a variable its semantic context is much more important than its type. This falls into the category of using descriptive names. HN obfuscates this.

Fourth, it is silly to add the type of variable into its name when you are using a compiler which checks for type conflicts.

Jurgen

Re:you're missing a lot

[sleepingsquirrel]

Most of the time I don't really care what something is, (If it is an integer 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)

Although not caring leads to integer overflow security exploits.

Re:you're missing a lot

[mamba-mamba]

Hmmm, yes and no. It is important that the variable on the left hand side of the equals sign be big enough, but the variables on the right side will be promoted.

So if the OP was saying he doesn't care about the left hand side type, then you are right. I get the feeling that he was. ;-)

Then again, as the phrack article says, these problems are subtle and much more difficult to exploit than standard buffer overflows (e.g., gets() or scanf("%s", ...).

MM
--

Re:you're missing a lot

[sleepingsquirrel]

But better safe than sorry, right? How many times have you seen this...

tmp=malloc(strlen(s)+1);

Which works okay until "strlen(s)+1" overflows. BTW, anyone know the theory of why malloc(0) doesn't return NULL?

Re:you're missing a lot

[Anonymous Coward]

How do you plan on copying a string of memory so big that its size causes an overflow anyways? I think we have much bigger problems to worry about than strlen(s)+1 if you're programming anything...

Re:you're missing a lot

[mamba-mamba]

Pretty hard to overflow that. strlen() returns a size_t, which is always a very large type.

Oh, to be totally anal and pedantic, unsigned types (which size_t is) don't overflow. The ISO
c standard imparts special meaning to "overflow" and specifies that it is only possible for signed types.

But there are plenty of other scenarios where it could be a concern. Chiefly, anywhere that user input directly specifies the length or number of items for which space must be allocated.

As for why malloc(0) doesn't return NULL, I can't say with certainty, but it is clear from the wording of the standard that its writers deliberately left open the door to returning non-NULL. I guess they wanted to support the concept of empty objects. Returning NULL is also allowed, and I'm sure some implementations do this.

MM
--

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?

repeat after me...

[7-Vodka]

repeat after me...

testicles testicles testicles testicles
testicles testicles testicles testicles
Obstacle.

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:What's needed is a Killer App

[Anonymous Coward]

Let me count the advantages/disadvantages:

Compile Gentoo for a new system: compile time is vastly reduced from 32-bit processors, but STILL TAKES DAYS FOR A WHOLE DISTRO.

Download and install binary packages: install time is negligible. Performance is slightly less than compiled code, BUT IS STILL BLAZING FAST.

I'll pick the one where I can use the software today, not next week.

Re:What's needed is a Killer App

[awol]

Mmmm, 64 bit integers. I don't know about you folks but AFAIC there is much to be gained from being able to handle big and precise floating point numbers as integers. The math is so much more pleasant. As Kronecker said, "God made the integers; all else is the work of Man" and so it is particularly true with computers. Oh to be able to store price x quantity in an integer, yummy.

Re:What's needed is a Killer App

[sql*kitten]

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.

Sun being overpriced is a piece of FUD these days, they are competitive on price and performance.

Re:What's needed is a Killer App

[Anonymous Coward]

I'll pick the one where I can use the software today, not next week.

Yes, but that's because you (and the moderator who marked CH's post "interesting") didn't get the joke.

Re:What's needed is a Killer App

[NerveGas]

They say their server ran $5k for two 1GHz chips, 4 GB memory, two 10K drives, four ethernet ports, and hardware SSL encryption.

I priced out the componants to build a dual Opteron 242 with the same trimmings (including redundant power supplies), sans the SSL encryption. It came to about $2500. In other words, half of the cost of the Sun system.

Now, the omission of the SSL encryption may make you cry foul. I don't believe it should, very few DBMS servers use significant amounts of SSL encryption. But, hey, let's throw one in anyway at $1,000. That still means the Opteron cost 30% less than the Sun.

Now, that's significant, but not an order of magnitude. There is one other catch, however: Sun's chips have a 128-bit PC2100 memory controller on each chip, where the Opteron has a 128-bit PC2700 memory controller. And a 25% improvement in memory bandwidth on a DBMS server is a very significant thing.

Now I don't have the two systems handy to benchmark, so I can't definitively say which would come out on top: But it's going to be very hard to turn down a system that has 25% more memory bandwidth, 60% higher clock, and costs half as much. There's always a chance the Sun will still come out a little ahead of the Opteron, but it's not going to come out THAT much ahead.

steve

Re:What's needed is a Killer App

[soybean]

Yea, I think you are right.
I think that 64-bit is such a strong partner to databases that I wouldn't be surprised to see oracle drop 32bit support down the road a couple of years.

Re:What's needed is a Killer App

[sql*kitten]

But it's going to be very hard to turn down a system that has 25% more memory bandwidth, 60% higher clock, and costs half as much. There's always a chance the Sun will still come out a little ahead of the Opteron, but it's not going to come out THAT much ahead.

Think about TCO tho'. In 10 years time, the Sun will most likely still be working perfectly and will still be supported by the manufacturer, parts available if it does break, OS certified on it, etc etc. In 5 years time if that PC breaks you might as well scrap it, because parts will be hard to come by. The whole Linux-on-x86 thing isn't as cheap as it appears up front.

Re:What's needed is a Killer App

[NerveGas]

"TCO" is one of those things that gets thrown about with wild numbers, and can be used to prove any or both sides of nearly any argument, depending on how you look at the numbers.

Here's how the TCO has worked out for me over the past 10 years: I build white-box servers for our company, and they have just as good of performance and stability as any x86 from a "big-brand". We've saved a LOT of money right there.

Then, we've used Linux instead of purchasing very expensive OS and software licenses. We've saved even MORE money there.

As for drivers and OS support, I've got machines that are far, far too old to be of use for anything, and the drivers and OS are still there. I've even got some RAID cards that are (IMHO) too old to be of use for anything but a curiosity, and the drivers are still under active maintenance!

Overall, it's been a decade of "linux-on-x86" being just as cheap as it's touted to be.

steve

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: Hungarian Notation

[mountiealpha]

It was a joke. Sheesh. I, personally, find Hungarian notation to make things a little easier when I code. That way I don't use an int where I meant to use a string, or somesuch. MT

Ahem...

[Anonymous Coward]

I believe it is "SUSE" now, not "SuSE".

Re:Ahem...

[Nasarius]

Maybe, but their logos still say "SuSE". Example:

http://www.suse.com

Re:Ahem...

[NighthawkFoo]

I'm happy as long as it's easier to type than S.u.S.E.

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

[yellowcord]

I believe that would be a petabyte.

Er....

[brunes69]

Did you even read this guys comment? He is talking about APPLICATIONS, not the OS.

With Linux, FreeBSD, etc, everything is open, and all I really need to do to change my system into a 64 bit version is re-build it (which is a joke with Gentoo :O). I can run one command on Friday, let the machine sit, and have a 64 bit version of every application on my system by Monday at the latest.

Now try going down to Best Buy and picking up a 64 bit version of Microsoft Office or Macromedia Dreamweaver. You'll be sorely out of luck. As will be the case with *many* of your favorite apps once 64 bit windows comes out... you'll be forced to either run them in 32 bit emulation mode, or pay for a new verison which may not exist for months, if it is even created at all.

16 bit raytracing???

[dave1g]

While I admittedly don't know much about the calculations in ray tracing I would guess that if you wanted it to look nice and behave well you would have to use floating point numbers larger than 16 bits to get all the precision in the angles of reflection/refraction

Re:16 bit raytracing???

[Anonymous Coward]

While I admittedly don't know much about the calculations in ray tracing I would guess that if you wanted it to look nice and behave well you would have to use floating point numbers larger than 16 bits to get all the precision in the angles of reflection/refraction

And you can't do that with a 16bits CPU?

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.

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:128-bit? quantum computers?PlayStation?

[ratfynk]

just buy and hack a japanese distributed playstation!

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

[ChrisMaple]

80 and 96 bits are standard lengths for "floating point" formats. With 64 bit loads two cycles are required to load these numbers.

Imagining the whoe thing...

[Junta]

As Itanium is ia64, an entirely different instruction set. That statement is akin to saying code compiled for Sparc runs better on Pentium processors..

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?

[Hoser McMoose]

Err, says who? IEEE 754 standard floating point defines a single precision floating point number as 32-bits and a double percision floating point number as 64-bits. In fact, x86 is about the only architecture I can think of off the top of my head that even allows 80-bit floating point numbers, but they are pretty much never used.

Yes, 80-bit and perhaps even 96-bit floating point numbers DO exist, but they are very rare in the real world.

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.

I don't even know where to start

[davegust]

So JigSaw reads an interesting write up about the struggles in getting several 64 bit distros to boot, and spins it Linux offers good Opteron support where Windows-64 doesn't seem to.

Here's a summary of the "good support":

• Couldn't get X to work at all on Gentoo. Wouldn't even compile.
• Mandrake wouldn't install - failed to recognize the partitions even of a freshly formatted disk
• Suse 8.2 random lockups - no support for the network card on the ASUS board
• Suse 9 - failed to load kernel until ACPI was turned off - did eventually boot and run after 2.5 hours of install
• A lot of standard packages crash hard, or even fail to compile
• No NVIDIA support at all

Please stop...your spinning makes me nauseous.

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.

Re:FreeBSD/amd64

[Anonymous Coward]

Hmmm, 64 bits... And yet the fonts still look like total garbage!

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

[Anonymous Coward]

If you only have 2GB of RAM then what is the point of using a 64 bit CPU? You would be much better off with Athlon MP. Bumdass!!

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

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

[OoSync]

>other is sharing of the bus bandwidth between two >CPUs,

While your points are quite valid, I do wish to correct this one error. Intel x86 chips use a shared-bus architecture for their multi-processor offerings. However, AMD Athlon MP SMP offerings use a point-to-point architecture in which each processor has a dedicated bus to the memory. So, they do not share bus bandwidth.

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

[Luyseyal]

I bought a dual Opteron solely because it's cool. :)
-l

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

[Anonymous Coward]

While your points are quite valid, I do wish to correct this one error. Intel x86 chips use a shared-bus architecture for their multi-processor offerings.

However, AMD Athlon MP SMP offerings use a point-to-point architecture in which each processor has a dedicated bus to the memory. So, they do not share bus bandwidth.


But they share memory bandwidth. Athlon MP chipsets do have those two Athlons on separate busses, but both CPUs access the same memory and hence share memory bandwidth, just like with Intel CPUs.

This arrangement helps Athlon to relax electrical constraints, so that signals on the wire can be point-to-point and get less noise and reflections in dual CPU systems and it can also have some degree of paralelism.

So, one Athlon could (chipset permitting) communicate with graphic card while other is doing some heavy operations with memory, but they can't both access the memory at the same time.

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

MOD PARENT DOWN

[Anonymous Coward]

Anti-linux sentiment detected. Sheepthink mod-bots please mod down immediately. TIA.

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

Ah - imagination.

[Anonymous Coward]

If I had a choice between something that is impossible according to the immutable laws of physics, and a 128 bit processor at 2 Ghz. Gimme the impossible one- and I'll conjure up fairies to rub me off whilst I mentally calculate realtime raytracing.

There. I made it just as realistic and much more colorful.

Re:Ah - imagination.

[Anonymous Coward]

You don't need imagination for that. So go over to San Fancisco and you can have all the fairies you want to, to rub you off.

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

[Anonymous Coward]

Average 3 year life cycle? Perhaps you missed the news that MS is just finally pulling the plug on windows 98 support... and the large numbers of companies that still have it deployed? That's more like 6 years by my math.

Not to mention that this is a platform which had 16 bit applications for how long after getting full 32 bit apps working?? (I've not looked lately, but I wouldn't be surprissed if there are still 16 and even 8 bit thunks available in windows xp.)

Re:Windows applications

[Sheepdot]

It's from the article in the story, do you read before you post?

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: Hungarian Notation

[Anonymous Coward]

It's called "strong typing." Learn it, live it, love it...

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:C types

[randombit]

Does the amd 64 use a 64 bit pid_t, time_t, uid_t, etc?

Short answer: no

Long answer: Depends on the kernel. On Linux, uid_t is always 32 bits (you really have more than 4 billion users?!?) pid_t/time_t: I forget. You can find out the size of pid_t in the kernel headers (types.h or posix_types.h or something like that). Again: you need more than 4 billion processes? Opteron is a nice CPU, but doesn't scale *that* well. Actually, I think right now on x86 at least pid_t is 32 bits, but only the low 16 are used (though I may be thinking of 2.2 behavior, and this in fact changed in 2.4 or 2.6).

time_t: I think this depends almost entirely on libc. Mostly, anyway: all the kernel has to do is not wrap when 2038 hits (not hard). libc has to actually know what to do with time values greater than that. One would hope glibc's time handling has already been tested, but I really don't know.

size_t/off_t are (or, at least, damn well should be, I actually haven't looked yet) 64 bits. So support for >2gb files is automatic. This is one that I would consider important.

Anyway, of the three you mention, the most important to move to 64 bits is time_t, and that isn't really a problem until at least 2020 (and that gives 18 years to upgrade).

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

[mduell]

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

Cannot resist

[DeBaas]

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.

Cannot resist, must build leaf blower from AMD fan...

Motherboard name

[Ed Avis]

Motherboard: Asus SK8N, BIOS upgraded to 1004

Am I the only one who thought of Avril Lavigne when reading that?

Re:Motherboard name

[Anonymous Coward]

Yes.

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

2.1 Gigapennies?

[WoTG]

I think I've found my new retirement goal... =)

AMD64 in 32 bits

[dbIII]

I have an AMD64 on a MSI board. It currently has stock RedHat9 and Mandrake beta for AMD64 on it. Some things, like ffmpeg and avifile, I have not yet been able to compile in Mandrake, (the Mandrake avifile libs wouldn't place nicely with transcode) hence RedHat9 (in 32 bit). The machine still performs incredibly well with a 32 bit OS. Getting up to 60fps converting DVD quality mpeg2 to xvid is pretty astounding performace. With good compression, subtitiles, de-interlacing etc. the frame rate drops down to not a lot slower than real time.

With more time (and less video to watch) I'll get that going in 64 bit.

Re:GNU/Shut GNU/The GNU/Fuck GNU/Up you GNU/Faggot

[Anonymous Coward]

That's GNU/Informative, damnit!

Comments disabled

[Pervertus]

Please stop writing journals with comments disabled - it's really not nice. Thank you.

I do.

[Svartalf]

X isn't needed for operation if you're doing server duty.

Mandrake RC1 went on FINE on my Athlon64 machine- no hassles whatsoever.

SuSE is installing as I type this- no glitches past having to do this over an FTP session so far...

A lot of standard packages seem to compile and run just FINE.

NVidia support is there and works just fine for 64-bit apps.

There's no AMD64 version of Windows64 currently available for end-user OR developer use.

The only spinning that I see is the spinning you're doing right at the moment.

64 bit ...is for performance...in this case...

[Svartalf]

The register store on an AMD64 machine doubles. That's about a 20% or more speed boost right there.

There's more than that to be sure, but do not compare 64-bit experiences other than with the same architechtures- each one's going to be different.

Re:64 bit ...is for performance...in this case...

[Chanc_Gorkon]

Yes but my point is that 64 bit is not the end all be all just like 32 bit processors were not. There will always be apps that need more bits and apps that peform better with more bits. Eventually, 64 bits won't be enough and we'll need 128 bits for some things. The fact is that today 64 bit technology isn't for eveyone. If it was, then we'd all be running Alpha's now.

So, where to find a motherboard for the Opteron?

[mwood]

Preferably without any Nvidia (unsupportable) or VIA (never saw a VIA chipset that didn't need weird secret tweaks to work at all) parts?

64bits is about virtual address space not RAM

[branchingfactor]

The principle benefit of a 64bit OS is that each process gets its own essentially infinite address space, which greatly simplifies coding in many applications. 64bit hardware makes the OS run fast because it provides hardware support for 64 bit pointers. You don't need a lot of RAM to benefit from a 64bit virtual address space. All you need is a large swap partition and an application program with locality of reference. Under such conditions nearly all of the memory references in RAM or cache, and the program will fly.

Not true.

[emil]

There are a number of architectures that do not fit the C language very well. I also understand that processors that do not have a "power of two" word size (32, 64 bit) present extreme difficulty for gcc.

Re:Not true.

[EvilTwinSkippy]

Where did you pull that figure out of? C is a compiled language, it will run on any darn architecture that a compiler exists for. And do it well because it is converted from human-reable code to object code and finally to machine code. There are not 1 but 2 places for architecture specific optimization.

The 32/64 bit limitation on GCC is hogwash. I also challenge you to find an architecture that doesn't have a "power of 2" word size, for starters. Remeber that includes 4, 8, 16. Are you saying there is a 15 bit platform out there somewhere? And if so why would you be messing with C, you have 32Kb of memory to play with. If you want to do anything worthwhile it would have to be in assembler.

Re:Not true.

[emil]

You challenge me to find an architecuture that has a non-power-of-2 word size? You haven't been around very long, have you?

Quick scan of google: PDP-10 emulator. The PDP-11 also had some interesting word size limitations: PDP-11 addresses were 16 bits, limiting program space to 64K, though an MMU could be used to expand total address space (18-bits and 22-bits in different PDP-11 versions). I see that an early design by Seymour Cray was 60-bit. You probably also know that the Itanium has a variable instruction bundle size.

Here is a link on porting gcc, including a warning on the word size. Not the best evidence, but it will have to do.

Re:Not true.

[DrDoug]

While I agree that the original post is "hogwash", there have been many architectures based on word sizes that were not a power of two. A few I recall are: PDP-8 (12 bit), Univac 1100 (36 bit), and the early CDC machines (60 bit). I know the CDC machines evolved into a 64-bit architecture. The PDP-8 architecture evolved into the PDP-11 (16-bit, I believe). I'm not sure if the Unisys 2200 retains the 36-bit architecture or not. In any case, one could write a C compiler for any of those architectures.

Re:Not true.

[EvilTwinSkippy]

Some of the Unisys machines would be odd ports for other reasons. Some of them use a stack architecture instead of registers. I really don't know the specifics, but they were showing off one of their Mini's when I interviewed there in the 90's.

Re:Not true.

[Anonymous Coward]

I also challenge you to find an architecture that doesn't have a "power of 2" word size, for starters.

Some of the PIC family of microcontrollers have 14-bit instruction words, and 8-bit data words, each in an independent address space. Oh, and their serial port hardware can handle 9-bit words.

Which is why I call 8-bit values octets, not bytes.

Re:Not true.

[norwoodites]

Easierly, s390 is 31 bits (yes 31) and GCC supports that.
s390x is 64bit though.

Re: Hungarian Notation

[vadim_t]

Hungarian can be useful in limited amounts. For example, for VB it can fairly nice. I use hungarian for the controls on a form, because there it removes a source of confusion. For example:

optPrintRange - option box "Print range"
txtPrintRange - text field for specifying the range
PrintRange - some random variable

This can make things noticeably easier when used with code completion if you know you have a checkbox somewhere for printing the selected text, and don't remember exactly if it's chkPrintSelected or chkPrintSelection.

Now, for variable names, I almost never use it, excepting for the 3 or 4 global variables to make it absolutely clear when I read the code that they are global.

What about C, I only write command-line programs in it, and never use this kind of notation.

Re: Hungarian Notation

[hayriye]

my favorite is lpsz prefix, which means "Long Pointer to C string"

LPSTR lpszString; /* The string variable */

Be careful of bus connections for memory.

[emil]

IIR, A number of dual Opteron boards attach all the memory to one of the CPUs. The other CPU has no attached memory, and must make Hypertransport requests of the other processor for all memory accesses.

Re:Be careful of bus connections for memory.

[Alizarin Erythrosin]

The Tyan Thunder board (K8S I think) I have has 4 slots for CPU0 and 2 slots for CPU1, which allows for each processor to have it's own stock of memory. But yes, there are others that have only one collective memory store attached to CPU0. You just need to investigate the board you buy first. IIRC there's an MSI board that has separate banks also.

FREE DOWNLOAD for SuSE 9.0 x86-64

[TelevisioSledgicus]

As you can tell by looking here SuSE 9.0 x86-64 Free FTP Install and following the appropriate links (when they're not overloaded).

Re:Should HAVE benchmarked kernel 2.6

[Anonymous Coward]

Learn to spell, even if you must go one word at a time.

Re: Hungarian Notation

[Anonymous Coward]

And how does this help those of us using polymorphic languages like C++ and Java where you don't know exactly what type you're using until runtime?

Re:So, where to find a motherboard for the Opteron

[0x1337]

NVidia has now for a LONG time supported the AMD64/Opteron platform (as well as IA-64, but who cares - UT2004 sure isn't going to appear on IA-64)

Here is a link if you're too lazy to check it for yourself -

The only thing you could POSSIBLY accuse Nvidia of not having done is providing 64-bit Drivers for FreeBSD (or drivers for any of the other BSDs). But even then

My current set up is an Athlon XP 2400+ pared with a KT266A-chipset motherboard. I had NO problems with the chipset under Linux or FreeBSD - ever, ever, ever. Sure - VIA has issues with new chipsets, but hey, they're human too - who doesn't. If you stick with the A-releases you should be more than fine.

I have, however, encountered it impossible to run Windblows XP without SP1 - without the harddrive being unusably corrupted within the first 30 minutes of uptime. But thankfully - that horror is over. No more Mr. Balmer and Microsoft on MY computer - or any computer within my proximity, ever.

Anyways - I can't wait to start porting my home-brew kernel onto x86-64 whenever I come across a cheap Athlon64.

Re:Opteron on X-Box

[Anonymous Coward]

I like the size of the controller :P

Less to do with a "need" and more to do...

[Svartalf]

...with an expense. Alphas were dramatically faster than the machines of their era. They were also ferociously expensive, costing $5-8k compared to the $750-2k for a PC. Which do you think people will buy unless they need every drop of speed available?

If Alphas were as cheap as PCs and you could easily get software for them like you could Macs and PCs, what do you think people would have bought?

The AMD64 series is an expression of most of that raw power at cheaper prices for all.