|
|
|
|
|
|
|
Drowning in a Lake That's Six Inches Deep |
|
|
|
| |
|
|
|
|
It is easy to ignore secondary performance effects during the course of the design. Apparently infrequent events such as overflowing a store buffer, context switches, execution time for character movement instructions, etc., can easily become primary problems in certain applications environments. These applications "drown in a lake that's (on the average) only six inches deep," since the weighted average of their frequency times their delay can dominate the total execution time of a program. The designer strives for high performance in, for example, a scientific user state. The fact that the system behaves significantly differently from this, or that a new release of the operating system behaves differently from the last, can present unfortunate surprises. There are numerous episodes where designers have ignored one or two presumably infrequent events, only to findsadly, too latethat the events were not quite as infrequent as they had assumed. Such cases include: |
|
|
|
| |
|
|
|
|
Store buffer overflow. In a particular processor, a store buffer was designed so that, statistically, it would rarely overflow. (See also Chapter 6 on the statistical design of store buffers.) How-ever, on calls to the operating system, all of the registers are stored by the system. This event was not anticipated to be frequent, so that the delay on a buffer overflow was significant and the delay on storing 32 registers was truly formidablesignificantly degrading the overall processor performance when applications made frequent calls to the operating system. |
|
|
|
| |
|
|
|
|
The small I-cache. In another processor design, a small I-cache was added to enhance performance. Early releases of the processor worked well. Unfortunately, a later version of the operating system had a primary service loop that exceeded the cache size by several bytes, causing almost every reference to the I-cache to cause a cache miss. The operating system had been tested on an older, but compatible, version of the processor, and the problem was not uncovered until outcries from the marketplace reached the development team. |
|
|
|
| |
|
|
|
|
Processor design consists of a series of complex tradeoffs. The designer must be vigilant that all aspects of current program usage and future possible usage are covered; maximizing the minimum performance is an important goal. Coupled with that is a thorough understanding of what the minimum performance could be. |
|
|
|
|
|
|