Intel announced today its line of Itanium products for high-end computing servers. Codename Montvale, the chip is an update to Montecito, the Dual-Core Itanium 2 chip which was launched in July last year, Eddie Toh, regional platform marketing manager of Server Platforms Group for Asia-Pacific at Intel, told ZDNet Asia in an interview on Monday.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-07-06
You have a lot of preconceived notions from a 3rd party overly superficial stand point, so be it.
3rd party overly superficial standpoint? What does that even mean?
However, EPIC for example, was an HP product not an Intel one.
The ideas behind EPIC originated at HP, but IA64 was closely co-designed with Intel.
And for the most part Intel never intended to replace its cash cow: x86 with IA64.
You're hedging with "for the most part" because it's quite clear Intel did have much higher aspirations for IA64 than it has achieved. You can argue about whether Intel ever intended to put IA64 in every $500 PC, but the early literature certainly suggests that Intel did intend to target it at least at the large swaths of the server and workstation markets that PPro-based designs allowed x86 to capture.
As EPIC-based products where intended from the get go for the high end and the enterprise side of things, two fields for which Intel at the time had little to no presence.
While that was certainly the initial goal of the Itanium line, it certainly wasn't the plan for IA64, as a whole, in the long term. It would make no sense for Intel to invest that kind of money into such a different architecture if they didn't have bigger plans for it, it just doesn't. You're basically saying that the guys behind IA64 were drooling morons, while I'm saying that they just misjudged the progression of technology.
You make a set of assumptions and requirements that are of your own bias, and thus move the goal posts and declare success or failure accordingly.
_I'm_ moving the goal posts? Where were you in the late 1990s? Ever since Merced started having problems, Itanium-apologists have been moving the goal posts. Now, their criteria for 'success' is ridiculously narrow. They're defending a chip that's basically only good for two things (HPC and mission-critical databases), and neglecting the huge monetary and intellectual investment that went into creating a design with such limited applicability.
The lack of proportionality is truly staggering. IA64 was an enormous proposition. It was not only a new architecture, necessitating all the things new architectures require (new toolchains, OS ports, application recompilations), but it was a new _kind_ of architecture. Even at the early stages it was clear that IA64 would require new compiler and software techniques to be developed. The end result just doesn't justify the magnitude of the investment and risk that went into it. If Itanium really was all that Intel intended for IA64 to be then their management was out to lunch when they green-lighted it. If they just wanted a good super high-end part with lots of RAS capabilities, suitable for very scalable systems, they could have achieved that goal at _far_ lower cost and _far_ lower risk by using a more traditional architecture.
There are also a couple of objective measures by which Itanium has failed. First, the project, as a whole, as failed to make money for the company. IA64 was a high-risk venture, and it has yet to provide a net-positive ROI. Second, IA64 has failed to prove the superiority of EPIC and VLIW. The compiler technology necessary to make it really useful just hasn't materialized, and the software world has largely moved on from the type of work loads that EPIC was supposed to be good at.
Second, EPIC, in theory at least. Was not to require recompilation of the whole code. But rather that programs will rely heavily of shared code which can be in the form of libraries, which can be then recompiled whenever advances in the compiler were available.
"Code reuse" is a myth, and always has been. Aside from a few HPC applications (BLAS libraries, etc) and some games (and only then recently), nobody reuses code to do computationally intensive work. I don't know what the mindset was at Intel when somebody put that forth as a good idea, but clearly there couldn't have been any historical precedent supporting such a notion!
Either way, what the rationale behind such ideas was at the time really is beyond the scope of my argument. At _this_ point in time, it's obvious that many of the things that EPIC depended on "in theory" just haven't panned out. Trying to extract large amounts of ILP statically from general purpose code is just not feasible, and its not clear that it's even possible. It's basically a dead-end idea, at least until there are fundamental advancements in compiler technology. Given the slow rate of progress of compilers (Proebsting's Law versus Moore's Law), counting on such advancements is just plain foolish.
Edited 2007-11-01 23:31
Member since:2005-11-10
Again, for the nth time... you set what the expectations for the IA64 were from an armchair. I am just pointing out that the goals and expectations from both Intel and HP were/are far different.
As far as HP is concerned, they get to sell Itanium systems which is making them lots of money. At the same time they got rid of PA-RISC and Alpha which were serious money drains and which they could no longer afford to develop. Intel gets a segment of the market that they had no access to before, and most of the development gets subsidized by HP. Itanium2 is an HP design BTW, and Intel is reusing the fab technology already had to begin with (which is what HP could not afford). There are a milliard of workloads, and for the ones that HP wants itanium for: HPC and transaction oriented processing. Itanium2 does remarkably well. So this whole nonsense of describing "workloads" as some sort of homogeneous entity is pointless. It may not be a sexy field, and it may be something fairly foreign to most people reading this thread, it is however a fairly important market.
There have been plenty of problems and issues with Itanium. But that is true for every other processor programme out there. Thus, as I said it is disingenuous to use the norm as if it was some sort of IA64-centric handicap. SUN lost hundreds of millions of the US V that had to be canceled, and now that their fab partner is gone out of the fabbing business they are up the creek without a paddle. IBM is trying to figure out what to do with POWER. Fujistu's SPARC64 is becoming a more expensive proposition with each generation. MIPS pretty much killed SGI. And even AMD is debating giving up the fabbing business because they simply can't afford to develop a successor to the Opteron and get their fab processes in order. Under that scheme of things, IA64 has weathered those waters relatively OK.
I just get a chuckle about all these armchair architect/computer tycoons, since what goes on inside of the beast is soooo different. :-)
Member since:
2005-11-10
You have a lot of preconceived notions from a 3rd party overly superficial stand point, so be it.
However, EPIC for example, was an HP product not an Intel one. And for the most part Intel never intended to replace its cash cow: x86 with IA64. As EPIC-based products where intended from the get go for the high end and the enterprise side of things, two fields for which Intel at the time had little to no presence. You make a set of assumptions and requirements that are of your own bias, and thus move the goal posts and declare success or failure accordingly. I was at intel until recently and that was not the light under which Itanium was casted upon (and the overall costs are much less than the $10billion as stated by the shareholder info I got :-) ).
Second, EPIC, in theory at least. Was not to require recompilation of the whole code. But rather that programs will rely heavily of shared code which can be in the form of libraries, which can be then recompiled whenever advances in the compiler were available. This was to offer a way to decouple silicon and compiler advances. When EPIC was conceived the silicon turn around cycle was nowhere near the speed it is right now, so a processor was expected to have a lifetime of a few years. Allowing speedups to come decoupled from the silicon during those few years, seemed like a sensible approach. At the time at least...
The main problem for the Itanium folks is not that it is a bad processor. But rather than the x86 folks have been fairly successful at not only keeping up but also commanding the performance curve. And that as far as Intel has been concerned is their main goal, as x86 is their cash cow.
Itanium for the most part has been subsidized, either by HP or by Intel's internal interests. Same can be said for any other non main stream architecture. POWER is only alive because IBM made a hefty investment in it, and even though a POWER chip for IBM is a money loser. They make it up in the long run with the services, which is their bread and butter. Same goes for SPARC, at least SPARC64 is a money loser for the microelectronics side of Fujitsu, it is the services attached to the primepower side of things that makes them money. The old adagio of "you got to spend money to make money" is also true in the micro electronics world.
Alpha died because it ended being a dead weight around the neck of DIGITAL first, and Compaq later. The size of the investment required to design and implement the AXPs was too much for Compaq to recoup with the services stream provided by the AlphaServers and AlphaStations. Same goes for PA-RISC that was at some point a significant drain in resources and money for HP. Heck, the only reason why MIPS lasted in the non-embedded side of things was because SGI poured shitloads of cash into a dying platform. Which in the end pretty much did the whole company in.
IBM, Intel/HP on the other hand are large enough that they can absorb the cost of their POWER, and IA64 investments. Because that gives them access to a market that other vendors are being locked out of, mostly due to the elevated entry fee required.
One has to understand the context under which Intel and HP see Itanium to better gauge its implications.