Slashdot Mirror
Intel Shifting 64-bit Plans
OS24Ever writes "News.com has an article stating that 'Intel plans to demonstrate a 64-bit revamp of its Xeon and Pentium processors in mid-February--an endorsement of a major rival's strategy and a troubling development for Intel's Itanium chip' Is this the end of Itanium?" Looks like the rumors were true.
No, this does not signal that Itanium is doomed. Have a look at www.spec.org and look at the CPU2000 scores. Itanium is starting to kick some serious tail.
However Itanium is not a desktop chip-- its too big. 64-bit x86 will be a consumer product for desktops.
People would rent time on huge (and hugely expensive) supercomputing centers; greatly simplify the models, knowing they introduce oversimplifications and errors; or, simply, not do the modeling they really wanted to do at all. A friend is working in a chip design company, and his simulations regularily run over an entire weekend, despite the hefty hardware they have.
In some areas (like climate modeling and some kinds of neural simulations), people can _still_ not do the kind of modeling they would really like to do, 64 bit clusters or not.
Trust the Computer. The Computer is your friend.
"The real question is have they finally dumped the stupid x86 instruction set in favour of a space/energy/coding efficient RISC set?"
Now, don't take this as a troll, cus it isn't. I have Sun boxen, and PowerPC boxen at arms reach ATM, and I love them.
RISC does not always mean fast! Nor does it mean anything else! In fact, for the sorts of problems that we are facing right now, X86 actually seems like a pretty sane choice of architecture.
The company in question - Intel - sells at least a zillion processors a year. They have substantial manpower and money to throw at optimisation.
Transistors are plentiful. 1.5 zillion transistors spent on the mutha of all instruction decoders equated to exactly one tenth of one percent of the number of transistors that will be used for cache.
Latency and Bandwidth to main memory suck. Big Time. A cache miss during a fetch can literally mean 100's of cycles spent waiting. CPU's are faster than memory bandwidth, even with deluxomatic DDR8 overclocked to eleven gagillion times faster than it ought to be.
So, given this information about the current state of affairs...
We want an ISA that has very dense code. Dense code means less bandwidth spent fetching instructions. Dense code means more code fits in cache = better apparent latency.
Also, it doesn't really matter how complex the architecture gets. Simplicity would help, but we would reach a point of diminishing returns.
Now, lets compare something sane like PPC or MIPS and something evil like VAX or x86.
The RISC architectures win on simplicity. If you are on a tight budget, or have limited staff, it'll be easier to optimise a RISC design. CISC architectures or only reasonably if you are big. (In this context, yes, VIA counts as big... SGI really doesn't sell many CPU's...)
Since RISC wins in simplicity of design, it'll also tend to win in tight transistor budgets. Need big transistors because you are doing rad-hardened work? Doing embedded design that needs to fit a whole system onto a paperclip? Doing a CPU for a price-sensitive home-console? Battery life your main concern? Heat output? You should probably seriously consider a RISC approach.
Now, lets think about a classical RISC architecture versus X86 in terms of code density. For one, CISC tends to use variable length instructions. So, a simple op like "increment a register" doesn't need to take 32 bits. On RISC, you tend to have fixed instruction lengths. (I'm terribly oversimplifying, deal with it.) So, any instruction will be the full word size, no matter how small.
X86 also has some godawfully complex instructions that are very long and ugly. These instructions can usually be accomplished only with multiple instructions on a RISC architecture.
So, as you can see, in a latency/bandwidth limited application, a CISC type instruction set essentially acts as a compression scheme for your code, which can be a Big Deal.
My own favorite ISA was IBM S/370. It had variable length instructions, but everything was relatively simple. You could read the machine code if you had to -- you just had to go op by op to figure out where one instruction started and the next began. It also had those cute little 24 bit memory addresses. They were cuter than pokemon.
So, my apologies for posting such a lengthy thingamajig, but I think I've managed to stay reasonably coherent... Yeah, X86 - she's ugly and horrible, but she can be made fast if you throw a billion dollars at her!
Looks like MS doesn't want two different 64-bit x86 extensions. I'm pretty sure Intel has cross-licensing agreements with AMD that will allow it to use AMD's x86-64 extensions. 'Prescott' may already have it
What differentiates Itanium2 from any Xeon is not the register width, but is the combintion the revoluationary EPIC architecture and auto parallelizing compilers.
IA64 can speed through tasks that deal with 32-bit numbers and 32-bit addresses with great efficiency, and it will beat a similarly clocked Xeon hands down running native compiled code.
Xeon + 64-bit registers is no threat to Itanium except in the minds of simpletons who look at the marketing bullets and say "gee, 64 sure is a big number!"
It is official; Netcraft confirms: Itanium is dying
One more crippling bombshell hit the already beleaguered Itanium
community when IDC confirmed that Itanium market share has dropped yet
again, now down to less than a fraction of 1 percent of all
servers. Coming on the heels of a recent Netcraft survey which plainly
states that Itanium has lost more market share, this news serves to
reinforce what we've known all along. Itanium is collapsing in
complete disarray, as fittingly exemplified by failing dead last
[samag.com] in the recent Sys Admin comprehensive networking test.
You don't need to be a Kreskin [amdest.com] to predict Itanium's
future. The hand writing is on the wall: Itanium faces a bleak
future. In fact there won't be any future at all for Itanium because
Itanium is dying. Things are looking very bad for Itanium. As many of
us are already aware, Itanium continues to lose market share. Red ink
flows like a river of blood.
Itanium 1 is the most endangered of them all, having lost 93% of its
core developers. The sudden and unpleasant departures of long time
Itanium 1 developers Jordan Hubbard and Mike Smith only serve to
underscore the point more clearly. There can no longer be any doubt:
Itanium 1 is dying.
Let's keep to the facts and look at the numbers.
Due to the troubles of Hewlett-Packard, abysmal sales and so on,
Itanium1 went out of business and was taken over by Itanium 2 who sell
another troubled OS. Now BSDI is also dead, its corpse turned over to
yet another charnel house.
All major surveys show that Itanium has steadily declined in market
share. Itanium is very sick and its long term survival prospects are
very dim. If Itanium is to survive at all it will be among OS
dilettante dabblers. Itanium continues to decay. Nothing short of a
miracle could save it at this point in time. For all practical
purposes, Itanium is dead.
Fact: Itanium is dying
For servers, addressing with more than 32 bits is crucial these days. The question is - how do you get performance improvement on a desktop ?
... well, it has 128 registers.
The real performance gain is in the change of ISA (instruction set architecture). True, calling it 64-bit vs. 32-bit is pretty much a marketing paint. The real issue with x86 is not even the fact that it's CISC - it's the number of registers. Few general-purpose registers means that you have to go to memory A LOT. x86 has 8 GPRs - the compiler can barely allocate 2 or (at most) 3 of them to variables.
It's much easier these to make register operations fast than memory ones. The x86-64 has 16 GPRs - you can actually do some useful register allocation with them and reduce the memory traffic. Itanium
That's why you get performance improvement just by recompiling an app that doesn't even use "long longs" to "64 bits".
The Raven
No it wasnt. Windows NT for AXP was 32bit.
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
As somebody who has worm a *lot* of tin foil hats...
.96 for AMD64 picked up my ethernet right off, and my sound seems to work for playing, but I haven't gotten it to record anything. The detonators are still a work in progress... I hear reports of people getting them running, but I have no luck.
The tinfoil hat crowd would happily tell you that the reason there's no 64 bit windows is because Microsoft knew about this a long time ago and deliberately held off releasing Win64 technology because of some shady business dealings with Intel.
I have to point out than Windows Server 2003 64 bit edition is currently a free download from MS's website, and comes with a one year free trial.
I have it installed. I rather like it. But, it's damn well not ready for prime time. It couldn't pick up the ethernet on my Athlon64 without some headaches. Lots of people are having trouble with SATA. There is no hardware 3D, even with the latest detonators. My sound hardware apparently has no driver support of any sort.
Seriously, it just isn't ready. MS is doing some respectable things with 2k3. No stupid luna theme, IE is way locked down by default, and it bitches at you if you try a weak administrator password. (it's even pickier than Linux about what it calls 'weak')
Linux is in a much better state. Fedora Core
And yes, I really do mean that I wear a lot of tin foil hats. I even visited the Periodic Table Table whilst wearing one. I got into a discussion with Theodore Gray about the purity of the aluminium in 'Tin Foil' Hats, while I was at Wolfram research. I own a VAX, an Athlon 64, and I've made a pilgrimage to the periodic table table. Do I get a Karma bonus?
One company is just usually faster to the market with one new extension or another because they developed it themselves. If it takes hold, they either license it to the other or give it to the other under a current license. It's in Intel's best interest to keep AMD around to avoid being called a monopoly, so rather than let AMD die due to lack of a standard it needs to survive in the marketplace, they throw it a bone. (Think Microsoft and Apple) Of course, Intel makes it difficult by not licensing socket and slot types anymore, but the basic architecture is still licensed.
It wouldn't surprise me if Intel asked to see AMD's specs in case they wanted to one day include their technology & then used that info to build a compatable processor. I'm sure that Intel could use 3DNow! instructions if it wanted to, but simply chooses not to. (Why give AMD any credit for making something useful when you have other extensions that can do the same job?)
3DNow is somewhat of an extension of MMX, SSE was a response to that, and then you have 3DNow Pro and SSE2, etc. etc.. They just keep evolving the multimedia extensions. SSE2 seems to be the latest thing, so both Athlon 64 and Intel chips support it. I'm sure Intel will have SSE3 and SSE4 out soon and eventually AMD will license those as well --- if it doesn't already have rights to any new technologies from intel for the next few years.
More info on x86 extensions at Evolution of Extensions
You must not be familiar with the x86-64 architecture. Simply recompiling your 32-bit app as 64-bit DOES increase performance. It has nothing to do with 64-bit vs 32-bit, it has to do with the fact that x86-64 provides more registers, and this itself increases performance.
You are wrong on both.
Windows 2000 was released as a release candidate for Alpha and it was a real 64-bit Windows with 64-bit pointers just like the current Itanium versions of Windows.
Lemme guess... you haven't even read the post you're defending. Right?
;)
The parent post very literally said that he needed 64 bit precision. Capisci? Not more registers, not a 64 bit architecture, not even 64 bit addressing. Precision.
In which case, yes, it's one mother of all bogus arguments.
Unless you're using _integers_, the x86 FPUs already gave you not only 64 bit floats, they gave you _80_ bit floats. Even in the 16 bit ages, since someone mentioned the 286, you still had an 80 bit FPU.
Guess it just shows that just because someone is an engineer and doing "real work" (and being snotty about it), they can still be computer-illiterate and/or riding the hype bandwagon
A polar bear is a cartesian bear after a coordinate transform.
Ahh, but in MY day, we used a 1-bit MC-14500 processor, *and* had to feed the damn DEER for the privelige of EATING them!