SI
SI
discoversearch

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 : Advanced Micro Devices - Moderated (AMD)
AMD 213.43+6.2%Dec 19 9:30 AM EST

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: jcholewa who wrote (59404)10/20/2001 1:29:51 PM
From: pgerassiRead Replies (2) of 275872
 
Dear Jc:

A few points to pick with your response:

Re: "> First, Itanium itself has not been around for
> close to a decade. Wen-Mei had an Itanium
> timeline in his presentation that showed Intel
> and HP as announcing the Itanium project in
> late 1997 - 4 years ago. That is pretty
> typical for a processor architecture. However,
> work related to advances in ILP compiler
> technology can be traced all the way back to
> 1987. In 1995, Intel and HP first began their
> alliance, but work on the architecture
> infrastructure began long before the processor
> did.
I think that your argument is contradictory. The Merced was initially expected to come out in 1997. Creating a microarchitecture based on an already existing architecture seems to typically take two years. Creating a microarchitecture and an architecture in tandem should take longer. I fully expect that work on the architecture began in 1995, as soon as Intel and HP could start to compare notes.
Comb was exaggerating by saying that it was worked on for close to a decade, but it definitely was not a short perior of time, either. I think that it's really not fair to test the philosophies of the architecture in the first generation or even the second. We should really wait for, say, the followup to McKinley before judging the viability of VLIW.
My objection, though, is that there is no longer a control in this experiment. What are we comparing it to? x86? That's made primarily for a lower end market, and nobody is going to make an x86 chip measuring 300sqmm+ to compete in the high end server market. IBM? No way, they're committed to using Itanium. HP? They made the Itanium's architecture! Compaq/Alpha? ...heh. SGI? They decided to become an all Intel chip shop without even looking at mature samples (and proceeded to slowly die).
There is no real competition against the Itanium save for Sun, a company who really serves a different angle of the market. I dismiss the claim that these companies just blindly assumed that the Itanium would be faster than anything else in the universe. They support IPF because of its strong impending market pressure, not for any technical reason. This really, really causes my blood to boil. Itanium now stands a chance of dominating not because it was the best technological choice, but because the competition had no other marketing choice. Grrr! I wanted an all out battle between IPF, Alpha, Power, SGI's chips, and everybody else! A market without competition is a market that dishonours the end user. Of course, that's probably why I started using Mandrake 8.1 as my primary operating system this past week. I can't stand it when marketing beats innovation. So, in a way, you can consider me biased against antitechnologists."

If the compiler problems are not fixed soon, they will bail out of Itanium faster than they gave support. If Hammer or any other x86 CPU out performs IA-64 by a factor of two or more, Itanium is dead, period! If Hammer merely is as fast on Itanium optimized applications, Itanium with its far higher costs will die. The Itanium has to deliver at least twice the performance of any other CPU, to keep the mind share it has. Notice that all of the supposed supporters have back up plans, if Itanium fails to perform, except Intel (they may have one under wraps as a JIC). The initial concept of VLIW is that by removing the scheduler stages and simplifying the execution pipelines, you could make the CPU run really fast and more efficiently. The compiler could be made to abstract the complexity so that ordinary code and normal paradigms could still be used.

Intel has failed in all three parts, but says that it will be solved really soon now. Itanium is far slower than its cousins in terms of speed at any given die size. A P3 or even the P4, as bad as it is, would out run the Itanium if given the resources of a die 4x P3s or 2x P4s. There is even some DSP cores that have 16 32 bit ALUs (SIMD anyone?). Many of the mobile CPUs can shut off parts of themselves when those parts are unused. So Itanium is also inefficient.

800MHz would have been a leading speed in 1997 and would have been quick even in late 1999. It hasn't cut the mustard as far back as 2000, not to mention how slow it is now. The only times the Itanium has come close to its potential is when the code is hand assembled and built using code that understands the limitations and strengths of the architecture. SPEC is there because the code is fixed and thus many orders of magnitude less complicated to get good enough. This is not the state any of the supporters can live with. I give Itanium at most, 2 more years to get to the promise, else it will quickly be buried like a toxic waste barrel.

Hammer, IBM's Power 4, HP's PA-RISC or Sun's SPARC (in decreasing order) could unseat Itanium, especially if one of them beats Itanium in both performance and price on typical applications (Hammer has the best chance of this). VLIW's achilles heel has always been the compiler. IBM tried it, HP tried it, TI tried it (it works better as a DSP where compiler is a nicety, but not a necessity) and now Intel has tried it. It still hasn't worked in a general purpose environment to this day.

Re: "> As for AMD's processor lines, Intel will have
> their 2nd generation McKinley processor 2-3
> quarters before the Hammer even launches
Hmmm. Is Intel skipping McKinley's pilot production stage and going right to full fledged introduction? If not, then McKinley and Hammer may come out at the same time (I have not seen any recent IPF roadmaps)."

Last time I saw something, McKinley was scheduled for Q3/02. This is also Clawhammer's debut time frame.

Re: "> The 2.5 generation Madison will be out in the
> first half of 2003, meaning that AMD's 2GHz
> Hammer will compete with Intel's 1.5GHz+ Madison
2.5 generation? Is Madison a McKinley shrink?
Anyway, if the Hammer is introduced at a maximum frequency of 2GHz, I will orally gratify anybody who expected as much. A 180nm K7 could probably come close to 2GHz. A 130nm K7 will likely be able to reach higher than 2GHz. The K8 has a longer pipe than the K7, and I would be utterly shocked if it were unable to ramp better than its parent.
Incidentally, won't the Hammer be much cheaper than the McKinley, in both chips and motherboards? I know that it won't be competitive from a marketing standpoint (because a Pentium II is more attractive than an Athlon MP), but from a performance standpoint, it'd really be more like a four-way 2.5GHz K8 competing against a one-way 1.5GHz (or whatever frequency) McKinley."

Hear, Hear! Actually going by die size plus the NB for McKinley (to compare 1:1 in functionality), 4 Sledgehammers (4 way dual core dual memory channel glueless 1MB (32GB PC2700) at 2GHZ (stated speed at MPF (playing worst case for AMD here)) would totally blow 1.2GHZ single Mckinley (8GB PC2100 or 4GB PC1066 RDRAM)(again stated speed at MPF) away and leave Intel/HP coughing in the dust storm of OEM opinion from its passage.

Re: "> Itanium has a good future, and competition
> isn't going to bury it any time soon.
That's because the competition gave up before the cards were dealt. :p"

Promise from a monopolist only goes so far. If the reality doesn't meet the promise, the former monopolist loses the monopoly, respect and the ability to do it again (In Intel's case the monopoly was slipping before the riot act was read).

Pete
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext