计算机系统设计原理概览

3星 · 超过75%的资源需积分: 10 12 浏览量更新于2024-07-29 收藏 4.89MB PDF 举报

"Principles Of Computer System Designs - MIT课程，介绍计算机软件系统设计的基本原则，探讨系统复杂性及其管理" 在"Principles Of Computer System Designs"这门课程中，主要关注的是计算机系统设计的基础理论以及如何应对设计过程中的复杂性问题。以下是该课程的一些关键知识点： 1. **系统与复杂性（Systems and Complexity）** - **系统、组件、接口与环境**：一个系统由多个组件组成，这些组件通过接口相互作用，并存在于特定的环境中。理解这些元素之间的关系对于设计高效且可靠的系统至关重要。 - **复杂性**：随着系统规模的扩大和功能的增加，复杂性也会显著上升。复杂性可能导致设计的难度增加，维护成本提高，以及系统性能的下降。 2. **复杂性的来源（Sources of Complexity）** - **级联和交互的需求**：系统需求往往不是孤立的，一个需求的变化可能引发其他需求的连锁反应，增加了设计的复杂度。 - **保持高利用率**：在设计系统时，往往需要确保资源的高效利用，但这可能导致系统内部的相互依赖性增强，进一步增加复杂性。 3. **应对复杂性策略I（Coping with Complexity I）** - **模块化**：将大系统分解为可管理的小模块，每个模块有明确的职责，可以降低整体复杂性，便于理解和测试。 - **抽象**：通过隐藏不必要的细节，抽象出高层次的概念，使设计更易于理解和实现。 4. **系统概述（Systems Overview）** - 这部分可能涵盖系统设计的基础概念，包括系统的层次结构、系统建模、以及设计过程中的决策制定。 5. **组件和接口的设计** - 设计良好的组件和接口是构建可扩展和可维护系统的关键。接口应清晰定义，以减少组件间的耦合度。 6. **环境适应性（Adaptability to Environments）** - 系统必须能够适应不断变化的外部环境，如硬件升级、新法规或用户需求变化。 7. **复杂性管理（Managing Complexity）** - 可能会讨论一些管理复杂性的工具和技术，如设计模式、重构、以及使用形式化方法进行验证。通过学习这门课程，学生将掌握如何分析和设计复杂的计算机系统，理解如何通过有效的设计策略来降低复杂性，提高系统的可靠性和可维护性。这些原则不仅适用于计算机科学，也广泛应用于工程、管理和其他领域中涉及系统设计的问题。

16 CHAPTER 1 Systems

well in any of the intended modes of transport. To help counter excessive generality,

experience suggests another design principle:*

Avoid excessive generality

If it is good for everything, it is good for nothing.

There is a tension between exceptions and generality. Part of the art of designing a

subsystem is to make its features general enough to minimize the number of excep-

tions that must be handled as special cases. This area is one where the judgment of

the system designer is most evident.

Counteracting the effects of incommensurate scaling can be an additional source of

complexity. Haldane, in his essay “On being the right size”, points out that small organ-

isms such as insects absorb enough oxygen to survive through their skins, but larger

organisms, which require an amount of oxygen proportional to the cube of their linear

size, don’t have enough surface area. To compensate for this incommensurate scaling,

they add complexity in the form of lungs and blood vessels to absorb and deliver

oxygen throughout their bodies. In the case of computers, the programmer of a 4-bit

microprocessor to control a toaster can in a few days successfully write the needed

code entirely with binary numbers, while the programmer of a video game with a 64-bit

processor and 40 gigabytes of supporting data requires an extensive array of tools—

compilers, image or video editors, special effects generators, and the like, as well as

an operating system, to be able to get the job done within a lifetime. Incommensurate

scaling has required employment of a far more complex set of tools.

Finally, a major source of complexity is that requirements change. System designs

that are successful usually remain in use for a long time, during which the environment

of the system changes. Improvements in hardware technology may lead the system main-

tainers to want to upgrade to faster, cheaper, or more reliable equipment. Meanwhile,

knowledge of how to maintain the older equipment (and the supply of spare parts) may

be disappearing. As users accumulate experience with the system, it becomes clearer

that some additional requirements should have been part of the design and that some

of the original requirements were less important than originally thought. Often a system

will expand in scale, sometimes far beyond the vision of its original designers.

In each of these cases, the ground rules and assumptions that the original design-

ers used to develop the system begin to lose their relevance. The system designers

*Computer industry consultant (and erstwhile instructor of the course for which this textbook

was written) Michael Hammer suggested the informal version of this design principle.

A complex system that works is invariably found to have evolved from a simple system

that works.

— John Gall, Systemantics (1975)

1.2 Sources of Complexity

may have foreseen some environmental changes, but there were other changes they

probably did not anticipate. As changes to meet unforeseen requirements occur,

they usually add complexity. Because it can be difcult to change the architecture

of a deployed system (Section 1.3 explains why), there is a powerful incentive to

make changes within the existing architecture, whether or not that is the best thing

to do. Propagation of effects can amplify the problems caused by change because

more distant effects of a change may not be noticed until someone invokes some

rarely used feature. When those distant effects nally do surface, the maintainer

may again nd it easiest to deal with them locally, perhaps by adding exceptions.

Incommensurate scaling effects begin to dominate behavior when a later main-

tainer scales a system up in size or replaces the underpinnings with faster hard-

ware. Again, the rst response to these effects is usually to make local changes

(sometimes called patches) to counteract them rather than to make fundamental

changes in design that would require changing several modules or changing inter-

faces between modules.

A closely related problem is that as systems grow in complexity with the passage

of time, even the simplest change, such as to repair a bug, has an increasing risk of

introducing another bug because complexity tends to obscure the full impact of the

repair. A common phenomenon in older systems is that the number of bugs intro-

duced by a bug x release may exceed the number of bugs xed by that release.*

The bottom line is that as systems age, they tend to accumulate changes that make

them more complex. The lifetime of a system is usually limited by the complexity that

accumulates as it evolves farther and farther from its original design.

1.2.2 Maintaining High Utilization

One requirement by itself is frequently a specic source of complexity. It starts with

a desire for high performance or high efciency. Whenever a scarce resource is

involved, an effort arises to keep its utilization high.

Consider, for example, a single-track railroad line running through a long, narrow

canyon.

†

To improve the utilization of the single track, and push more trafc through,

one might allow trains to run both ways at the same time by installing a switch and a

short side track in a wide spot about halfway through the canyon. Then, if one is care-

ful in scheduling, trains going in opposite directions will meet at the side track, where

*This phenomenon was documented by Laszlo A. Belady and Meir M. Lehman in “A model of large

program development”, IBM Systems Journal 15, 3 (1976), pages 225–252.

†

Michael D. Schroeder suggested this example of a railroad line in a canyon.

Een schip op’t droogh gezeylt, dat is een seeker baken. (A ship, sailed on to dry land, that is

a certain beacon. Learn from the mistakes of others.)

— Jacob Cats, Mirror on Old and New Times (1632), based on a Dutch proverb

18 CHAPTER 1 Systems

they can pass each other, effectively doubling the number of trains that the track can

carry each day. However, the train operations are now much more complex than they

used to be. If either train is delayed, the schedules of both are disrupted. A signal-

ing system needs to be installed because human schedulers or operators may make

mistakes. And—an emergent property—the trains now have a limit on their length. If

two trains are to pass in the middle, at least one of them must be short enough to pull

completely onto the side track.

The train in the canyon is a good illustration of how efforts to increase utilization

can increase complexity. When striving for higher utilization, one usually encounters

a general design principle that economists call

The law of diminishing returns

The more one improves some measure of goodness, the more effort the next improvement

will require.

This phenomenon is particularly noticeable in attempts to use resources more ef-

ciently: the more completely one tries to use a scarce resource, the greater the com-

plexity of the strategies for use, allocation, and distribution. Thus a rarely used street

intersection requires no trafc control

beyond a rule that the car on the right

has the right-of-way. As usage increases,

one must apply progressively more com-

plex measures: stop signs, then trafc

lights, then marked turning lanes with

multiphase lights, then vehicle sensors

to control the lights. As trafc in and out

of an airport nears the airport’s capacity,

measures such as stacking planes, holding

them on the ground at distant airports, or

coordinated scheduling among several

airlines must be taken. As a general rule,

the more one tries to increase utilization

of a limited resource, the greater the com-

plexity (see Figure 1.2).

The perceptive reader will notice that

Figures 1.1 and 1.2 are identical. It would

It is impossible to foresee the consequences of being clever.

— Christopher Strachey, as reported by Roger Needham

Subjective complexity

Utilization

0 100%

FIGURE 1.2

An example of diminishing returns: complexity

grows with increasing utilization.

1.3 Coping with Complexity I

be useful to memorize this gure because some version of it can be used to describe

many different things about systems.

1.3 COPING WITH COMPLEXITY I

As one might expect, with many elds contributing examples of systems with com-

mon problems and sources of complexity, some common techniques for coping with

complexity have emerged. These techniques can be loosely divided into four general

categories: modularity, abstraction, layering, and hierarchy. The following sections

sketch the general method of each of the techniques. In later chapters many examples

of each technique will emerge. It is only by studying those examples that their value

will become clear.

1.3.1 Modularity

The simplest, most important tool for reducing complexity is the divide-and-conquer

technique: analyze or design the system as a collection of interacting subsystems,

called modules. The power of this technique lies primarily in being able to consider

interactions among the components within a module without simultaneously think-

ing about the components that are inside other modules.

To see the impact of reducing interactions, consider the debugging of a large

program with, say, N statements. Assume that the number of bugs in the program is

proportional to its size and the bugs are randomly distributed throughout the code.

The programmer compiles the program, runs it, notices a bug, nds and xes the bug,

and recompiles before looking for the next bug. Assume also that the time it takes to

nd a bug in a program is roughly proportional to the size of the program. We can

then model the time spent debugging:

BugCount  N

DebugTime  N 3 BugCount

 N

Unfortunately, the debugging time grows proportional to the square of the program

size.

Now suppose that the programmer divides the program into K modules, each of

roughly equal size, so that each module contains N/K statements. To the extent that

the modules implement independent features, one hopes that discovery of a bug usu-

ally will require examining only one module. The time required to debug any one

module is thus reduced in two ways: the smaller module can be debugged faster, and

Plan to throw one away; you will, anyhow.

— Frederick P. Brooks, The Mythical Man Month (1974)

20 CHAPTER 1 Systems

since there are fewer bugs in smaller programs, any one module will not need to be

debugged as many times. These two effects are partially offset by the need to debug

all K modules. Thus our model of the time required to debug the system of K modules

becomes

DebugTime 

(

)

3 K



___

Modularization into K components thus reduces debugging time by a factor of K.

Although the detailed mechanism by which modularity reduces effort differs from

system to system, this property of modularity is universal. For this reason, one nds

modularity in every large system.

The feature of modularity that we are taking advantage of here is that it is easy

to replace an inferior module with an improved one, thus allowing incremental

improvement of a system without completely rebuilding it. Modularity thus helps

control the complexity caused by change. This feature applies not only to debug-

ging but to all aspects of system improvement and evolution. At the same time, it

is important to recognize a design principle associated with modularity, which we

may call

The unyielding foundations rule

It is easier to change a module than to change the modularity.

The reason is that once an interface has been used by another module, changing

the interface requires replacing at least two modules. If an interface is used by many

modules, changing it requires replacing all of those modules simultaneously. For this

reason, it is particularly important to get the modularity right.

Whole books have been written about modularity and the good things it brings.

Sidebar 1.5 describes one of those books.

1.3.2 Abstraction

An important assumption in the numerical example of the effect of modularity on

debugging time may not hold up in practice: that discovery of a bug should usually

lead to examining just one module. For that assumption to hold true, there is a further

requirement: there must be little or no propagation of effects from one module to

The purpose of computing is insight, not numbers.

— Richard W. Hamming, Numerical Methods for Scientists and Engineers (1962)

剩余367页未读，继续阅读

skyWalker_

粉丝: 0
资源: 1

计算机系统设计原理概览

Principles of Computer System Design Part II

Principles of Computer System Design An Introduction

Principles of Computer System Design - An Introduction (Part I)

rudin principles of mathematical analysis 下载

7. Write the assembly language program using the following instruction a) Set on less than instruction b) Set on less than immediate instruction c) Branch equal PRINCIPLES OF COMPUTER ORGANISATION d) Branch if not equal

principles of neural science

levinson h j.overlay//principles of lithography,spie,2005.

principles of lithography pdf

principles of lasers 下载

最新资源