Slashdot Mirror
Microsoft Commits to Using Opteron
the_1000th_Monkey writes "According these articles at The Inquirer, Infoworld, and The Register Windows XP and Windows Server 2003 will support AMD's 64-bit Opteron processor. Beta releases can be expected in the middle of this year. Here is MS's official press release."
Linux already supports it...has for over 6 months now
"Some things have to be believed to be seen." - Ralph Hodgson
Yes, Itanium versions of XP and 2003 have already been made.
It will be annoying when they do release the opterons and there is no (64bit) software to run on them. Sort of buy a system, install a 32bit os and then a few months later reinstall it.
Also I think many people will be dissapointed with the 32bit performance and AMD might get a bad name for it.
Mouse powered Chips, Open source Processors and Lego
Really?
Where exactly is this rock that you've been hiding under?
Even more interesting is that your volume license version of Window 2003 enterprise or datacenter can be installed on either 32 or 64 bit platforms.
Lauching same time as 32 bit and available on the 24th WOO HOO!!
Windows 2003 web server and standard server are 32 bit only.
WinXP 64 was just announced.
And does this make AMD part of the Axis of Evil now?
Once upon a time, Windows NT ran on Pentium, Alpha, MIPS, PowerPC and possibly other CPUs. AMD will be a member of the Axis of Evil until Microsoft decides the time has come to cut its throat, as it has with so many other of its "partners."
WMD = Windows of Mass Destruction?
When all you have is an axe, everything looks like a grindstone.
Actually I think the programs be ready before the OS's. The inquirer has a long list of 'The willing'.
For instance, there are five varieties of Linux, three BSDs, Beowulf and Windows in the offing. Most of them have either already been released or are due to be released at the Opteron launch.
Database support is strong with IBM's DB2 leading the field; CA Ingres, Oracle and MS SQL Server are all set to follow.
Mouse powered Chips, Open source Processors and Lego
This is no news to me. I remember reading that AMD was delaying their 64-bit processors until next fall, the reason was apparently that they wanted to have a version of Windows to run on it.
It is therefore no surprise that Microsoft announces an appropriate version of Windows in the same time frame!
Microsoft was the primary development partner with AMD on the x86-64 instruction set. What MS wanted, AMD delivered. And it's great! Not like that crappy HP/Intel Itanium fiasco.
The whole point of AMD's 64 bit chip is to allow both 64 bit and old/current 32 bit apps to run together smoothly.
Can't wait for the desktop version.
-"The early bird catches the worm, but the late bird sleeps the most"
2^32 times the addressing space of 32 bit, so goodbye 4 gig limit. And greater speed / precision ratio. Those are the two biggest points.
-Reid
Just imagine if the only 64-Bit servers you could buy were non-MS based...
They have been non-MS based for years, I run a 5 year old HP-UX 11.0 64-bit server at my job.
64bit RISC based processors have been available for about 10 years now (just a guess, maybe longer)
"Some things have to be believed to be seen." - Ralph Hodgson
A game compiled for x86-64 will run significantly
faster since there are more general purpose
registers available to it. So even if it doesn't
make use of 64-bit ops, it will still run faster.
The same game compiled for x86 and run on an
x86-64 will not see the same improvement since
it won't take advantage of the extra registers.
According to an interview posted on Slashdot
recently (karma op for anyone who wants to hunt
down the link), several current games recompiled
for x86-64 but not tweaked in any way, experienced
a 30% increase in performance because of the
extra registers.
*sigh* back to work...
Although there are Xeon-based servers that support more than 4GB of RAM, it just doesn't handle it very efficiently by having to use windows and page addressing extension (I think that's what PAE expands to) to address anything beyond the 4GB 32-bit memory addressing limit. Xeon's support 36-bit memory addressing.
With the AMD Hammer's handling > 32-bit memory addressing natively and without hacks like PAE, it will definitely help improve high-memory use applications like databases, large rendering jobs (think Unreal II, future movies), or scientific crunch jobs.
Microsoft has committed to the Itanium/Itanium 2 with their initial release of Windows Server 2003. I think Microsoft is already working on getting Exchange Server and SQL Server (both would benefit greatly with non-PAE > 32-bit memory addressing) ported and running on the Itanium/Itanium 2 platform. I haven't heard of any announced release dates or public betas yet.
Two reasons. 4gig limit, only 2 can actually be used, this is starting to become a real problem blah de blah de blah.
The more subtle one is that the x86 instruction set is as broken as a broken thing, as we all know, and x86-64 goes some way to fixing that. Particularly in terms of having more registers.
Dave
I write a blog now, you should be afraid.
64 bit instruction set for faster low level functions, faster 64 bit pipes
This is just plain wrong. 64-bit words at the CPU level has no direct effect on instruction speed, unless you make tricky optimizations, like packing 32-bit variables into a single 64-bit register and doing operations on them simultaneously (which, in general, isn't that useful, BTW). Yes, there are a couple places where wider registers could be useful (bulk data transfers, etc) but there really aren't that many. Some people have mentioned higher-precision arithmetic, but IMHO, if you need that, you're using the FPU anyway, and thus have had 64-bit (80-bit internally) precision for some time now.
The main reason the Opteron is a good thing is because 1) it provides MORE registers, allowing the compiler to make smarter register allocations, which can provide drastic performance improvements, and 2) it provides access to a larger address space, meaning you can finally have >4GB of memory without nasty paging hacks. Of these, only the first is really that useful to your average Joe, which is why you're only going to see the Opteron in higher-end workstations and servers for the immediate future... at least, IMHO.
They're going to support Opteron/Athlon64. Nothing in the press release says they're going to be using it to run their sites
Actually, I believe (2^32)^32 != 2^64
2^64 = 2^(32*2) = 2^32 * 2^32 = (2^32)^2
... but not (2^32)^32
The hardware specific code is contained in the Hardware Abstraction Layer, which is layered under the kernel. Remember that NT has been available for several different architectures in the past. The fact that only IA-32 remains has to do with market realities, not with the design.
Yep, I knew all that...still why was it so much easier to port Linux?
It would still be pretty easy for MS to provide NT for other 32-bit platforms. Now, porting to a 64-bit platform isn't the same thing.
So your theory is that Microsoft has been sitting on it's hands all these years without porting to any of the readily available 64-bit platforms? Including Itanic, which has been around in beta incarnations for several years?
Sorry, I don't buy it.
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
If you have a real need to address that much memory, you'd be a fool to cheap out and buy inferior hardware like Intel or AMD.
Nonsense. Intel/AMD smoke memory I/O and SPECInt, and in terms of price performance do so in a manner which is breathtaking. Putting a DB on a x86-64 using quality system parts (like, say, a rackmount Compaq (move fast before HP fucks the rackmount Proliants up!)) with large memory makes a lot of sense. If you wanna start doing quad-bank interleaving, 64bit lets you do so with large memory quite nicely. Business computing for the most part only cares about stability, I/O and int performance.
I look forward to 4/8-way smp opteron rigs with quad-channel DDR400 support, featuring 4-16 DIMM slots and multiple 64bit/66mhz PCI, multiple gig-e on hypertransport.
"Why is it that they won't support existing 64bit technologies (Itanium, Alpha's back in the day), but their gung ho for yet another x86 hack?"
Huh... Windows 2003 supports the Itanium already.
Everyone rails on the x86 instruction set. Yeah it's not pretty, it's not fun, hell it's downright ugly. But what are the top SPECint machines these days? Wanna guess? That means something is ok with x86. Yeah it might be hack-on-hack-on-hack but this collection of hacks seems to be working. (They'd be pretty near the top SPECfp's except for Itanium, everyone else's favorite Intel punching bag -- give me a break it has stellar FP, which is what it was made for!)
More seriously, there are some academic studies around that show that variable-length instructions of the x86 ISA actually are improving performance over fixed-length RISC-style ISAs. Why? Because the instruction density in the cache can be higher, and therefore the I-Cache fill rate doesn't need to be as high. Sure, the I-Decode is a b*tch to design and build, but apparently Intel and AMD are able to run it in about 500ps (~2GHz, or better) in 0.13u and below technology. Not bad, not bad.
NT has been running on Alpha's since NT4 (or maybe even 3.51 AFAIK).
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
The article was at Ars Technica, and it was about the Counter-Strike server, not the actual video game.
However, the 30% speed improvement was NOT over an Athlon. They took the 32-bit binaries, benchmarked them on the Opteron, and then they recompiled the code for the x86-64 target (without changing a single line) and benchmarked it again, and there was a 30% speed improvement.
That's pretty impressive if you ask me. Granted, the server side does most of the physics logic and such, and not graphics, but I'm optimistic about just how much the increase in raw CPU power is going to help gaming out.
Windows NT 4.0 shipped (on a single CD) in Alpha, x86, PowerPC and MIPS form.
No a single execution thread being register starved CAN be a significant slowdown on x86. This has been known for some time but there was no good way to extend the register set without a re-arch and hence a break with backwards programs. What AMD did was essentially layer two API's on top of one set of execution units, one backwards compatible with x86 and including all of its limitations and the other a new fresh and fully modern. The 30% speed improvement was from a simple recompile, which means that is not a change to any datatypes or anything else, but rather just from improved register and execution unit use.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.