Dear Tench:
The smart compiler on a dumb machine refers to the design goal of EPIC (Explicit Parallel Instructions Computer). The Itanium is an in order processor. That is easier to do than a harder but smarter out of order processor. The explicit in EPIC means that the compiler schedules the tasks of each functional unit in the Itanium. This removes even more intelligence from the CPU and gives it to the compiler. Thus the compiler must optimize the instructions to each functional unit in order to get the maximum performance. This is why the compiler must be very smart. Thus the statement is accurate in comparison to P3, P4, K6, and Athlon.
Designing the CPU, Itanium, should be easy since it does not need to do out of order execution and schedule functional units. That logic is where much of the complexity of logic in the mainstream processor goes. Thus, it should be easy to design. The problem is that neither the hardware (how Intel missed the frequency is hard to understand) nor the compiler (this is much easier to see as this is typically the achilles heel of EPIC) is ready. The only way to have these problems is they are trying to put back some smarts into the CPU to help the compiler out.
The problems with EPIC are many. Here is a few:
1) Because the compiler must optimize for the functional units in a given EPIC CPU, every program must be recompiled for each different EPIC CPU. If one adds or deletes a functional unit or changes the latency of an operation, the program is no longer optimal. Many stalls will result in too few units and more units are not used at all. Doubling L1 or L2 cache would also produce this effect. Also, the memory subsystem must be recognized by the compiler as you must take this into account as well. Thus a recomile of all applications each time a change to the hardware configuration is performed is required for optimal performance. This will be hard given the way software side of things is architected (also why Linux and open source is a necessity for Itanium).
2) Since the optimization is done at compile time, if the assumptions made are wrong, there is currently no way to fix it. For example, if two consecutive runs invert the probabilities of most branches taken, and the first case was considered typical by the compiler, the second case will be frought with stalls, delays, bubbles, and run very slowly compared to the first run. Thus run times become very difficult to predict and fustrating for users. In addition, any real time processing that is required will have a difficult time in making sure that response times are within specifications. This is the the kinds of loads commonly found in applications such as web serving and heavily loaded multi-tasking computers.
3) Multi-tasking, and interrupt driven software, will cause disruptions to many optimizations performed by compilers for EPIC CPUs. They act like many mispredicted branches, cause major thrashes of the caches, and frequent pipeline stalls.
These tasks are performed by a majority of the servers that is the intended market of Itanium. The best market for EPIC CPUs is the embedded market as the problem can be very narrowly defined and does not change over time. The opposite of the things one expects from a general purpose CPU.
Pete |
