To: Tenchusatsu who wrote (60564 ) 10/26/2001 6:09:34 PM From: pgerassi Respond to of 275872 Dear Tench: Why Hammer's target market contains all of Xeon's target market. Anything that runs on a Xeon should be able to run on a Hammer. However, the converse is not true. The target market of Hammer is stated by AMD to be the entire PC and server space which is, in increasing power order, mobile, desktops, workstations and servers. The problem is that you and appently others think that there is some limit on the high end. There is not any limit present. You (and others) believe that this limit has to do with availability and time. How is this different than with IA-64? The real problem of IA-64 porting is that the compiler is not able to fulfill its original goal. That is to automatically do all of the changes required for high performance code without, at first, any requirements from the developer. The current version does not come close to this for an IA-64 system to get reasonably matching of any of it competitor's performance. Much rewriting needs to be done, some trivial, but a lot has to delve into assembly to fix performance troubles. This is very serious. This causes three major problems. First, the time it takes can overrun the budget and unless the desire is strong, it will be dropped. Second, the amount of people who can optimize the code for the IA-64 is small and the good ones will be smaller yet. Thus, the cost to obtain these resources are high (see the first reason) and there is a limited supply (growing, but slow). Third, even if the first two problems are overcome, any drop into the assembly portion will swell the time exponentially which gets us back to reason one. Lastly, reason 2 and 3 puts a limit on how much can be done within a certain time. All of this is caused by the inability of the compiler to optimize well. There is two ways around this. Both have been tried. The first is to simply throw it a faster CPU. And the second is to alter IA-64 so that it is easier to compile. This could be the reason that the problem is not that Itanium is slow, but that quickly generated code is slow on it. Although, the speeds of the hardware could just as easily be the thing to blame. If Itanium was running at 2GHz at inception, would as much scorn be placed on it? Probably not as performance is a good motivator. Then the compiler could perhaps reach stage 2 (equal poerformance) with far less optimization mitigating the initial porting requirements. From previous statements from Intel, this is what was envisioned 5 to 7 years ago when the design was started. Whatever delayed it those two or three years, really caused a problem that may not be solved. The problem is not that it costs 200% of a Xeon server port, but it is that the costs are 10 times or more, both in time and money. If a simple strip IA-32 stuff out of the code and compile were sufficient in most cases (>90%), there would be a lot less grumbling and retisence on the switch. And most of those increased costs are in the software. That is what happened when Intel decided to throw the debugged and battle tested baby out with the bath water. To show you a closer look of the current state, a legacy app runs at 100% speed on a Xeon server, at 150% on a Hammer server with no porting required, at 180% on a Hammer server with 100% of porting costs (baseline), at 10% on a IA-64 with no porting costs (x86 compatability mode), at 60% on a IA-64 with 200% of porting costs, at 100% on a IA-64 with 1000% porting costs and at 250% on a IA-64 with 2000% porting costs. Which would you use? If the Hammer server was 50% of the cost of the Xeon server and an IA-64 server is 200% of the cost. Now which? If you have to wait 12 months for a Hammer, 6 months for a IA-64 and none for a Xeon server? Pete