Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : All About Sun Microsystems -- Ignore unavailable to you. Want to Upgrade?

To: rudedog who wrote (27550)	2/10/2000 10:47:00 AM
From: Charles Tutt	Read Replies (1) \| Respond to of 64865

Thanks for the insight. It sounds like you've looked at Itanium fairly closely.

To: rudedog who wrote (27550)	2/10/2000 11:07:00 AM
From: QwikSand	Read Replies (2) \| Respond to of 64865

The biggest problem I see with merced performance is the lack of hardware support if the compilers do not find and exploit parallelism - that was an assumption of early merced design which did not prove out, and the silicon won't really address those shortcomings until McKinley, so there will need to be a lot of hand-tuning of merced implementations. Given the short life of the product, it seems doubtful to me that more than a handful of ISVs (the ones being heavily supported by Intel) will take the time to do that for merced. That implies that merced sales will be narrow in focus, probably mostly in areas where there is already a shift to Intel technology. I would expect the database vendors and perhaps the ERP guys to do something, but I expect broader optimization for IA64 to be in the McKinley timeframe, which I think is probably mid-2002 or so. Dog, this situation sounds so familiar to me. Does it to you? The current release has a bad problem. The next release (we hope) fixes it. The time difference between the two is short and could perhaps be reduced. The resources required to work around the problems in the first release and to go through two product life cycles, one on the heels of the next, are substantial. The benefit of deploying them questionable. And there's no question those resources are badly needed elsewhere. This is an archetypal Fred Brooks "plan to throw one away, you will anyway" scenario. Intel, now late and heavily committed, faces the very, very tough choice of either a) burdening at least some of their most major partners with a crippled first iteration (both OEM and ISV partners, since you yourself said McKinley and Merced require different machines as well as application tuning) that promises minimal return and is followed immediately by a second iteration that requires substantial further investment b) facing up to reality, dumping Merced, taking the hit, doing what they can to focus on and accelerate McKinley so that as many customers as possible come out with real machines and real applications as soon as possible. We've probably all had to face that choice many times. To me the choice seems clear. (In this case there's the addded system software factor that everyone keeps brushing aside, but if you really believe that a 64-bit Microsoft W2K operating system and a 64-bit enterprise-ready Linux will be "ready when Merced ships", I've got a bridge you might be interested in). You say the Register article about the growing rumor that choice b) above will be the one taken is wrong. I say it has to be right; if it isn't right, a lynch mob should and will descend on the office of "ship-the-shit-Andy". There will be various PR maneuvers and straw men, but IMHO Intel has no choice but to shift their focus to McKinley at the expense of Merced, and to do so in a big hurry. Of course, I've been wrong before :-). --QS