1 / 81

Principles of Computer System

Principles of Computer System. 2012 (Fall). Instructor. Yubin Xia ( 夏虞斌 ) Email: xiayubin@gmail.com Web site: http://ipads.se.sjtu.edu.cn/ yubin_xia. Textbook. Principles of Computer System Design: An Introduction Jerome H. Saltzer & M. Frans Kaashoek June 2009.

louisa
Download Presentation

Principles of Computer System

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Principles of Computer System 2012 (Fall)

  2. Instructor • Yubin Xia (夏虞斌) • Email: xiayubin@gmail.com • Web site: http://ipads.se.sjtu.edu.cn/yubin_xia

  3. Textbook • Principles of Computer System Design: An Introduction • Jerome H. Saltzer & M. FransKaashoek • June 2009. • Papers and articles online

  4. Grading • 50%: Lab • 40%: Exam • Only one final-term exam • All exams are open-books / open-notes • 10%: Performance • Paper reading • QA site asking/answering/voting • Attendance

  5. Topics • Systems • A bunch of computer systems • E.g., hardware, software, or combined ones • Problems • From benign ones to vital ones • Principles • E.g., end-to-end argument

  6. System’s Perspective

  7. You’ve Already Learnt: • Programming / Data Structure • LOC: From hundreds to millions • Operating System / Architecture • Cores: from one to hundreds • Network • Nodes: from two to millions • Web Service • Clients: from tens to millions

  8. The Problem: Complexity of System

  9. An Example: Gas System

  10. Complexity of Computer Systems • Hard to define; symptoms: • Large number of components • Large number of connections • Irregular • No short description • Many people required to design/maintain • Technology rarely the limit • Indeed tech opportunity is the problem • Limit is usually designers’ understanding

  11. System Complexity

  12. Problem Types • Emergent properties • Surprises • Propagation of effects • Small change -> big effect • Incommensurate scaling • Design for small model may not scale • Trade-offs • Waterbed effect

  13. 1. Emergent Properties • Features • No evident in the individual components of a system • But show up when combining those components • Might also be called surprises • An unalterable fact of life: some things turn up only when a system is built

  14. 1. Emergent Properties (Cont.) • The Millennium Bridge • For pedestrians over the River Thames in London • Pedestrians synchronize their footsteps when the bridge sways, causing it to sway even more • It had to be closed after only a few days

  15. 2. Propagation of Effects [Cole’69] • WHO: tried control malaria in North Borneo • Sprayed villages with DDT • Wiped out mosquitoes, but …. • Roaches collected DDT in tissue • Lizards ate roaches and became slower • Easy target for cats • Cats didn’t deal with DDT well and died • Forest rats moved into villages • Rats carried the bacillus for the plague • WHO replaced malaria with the plague

  16. 3. Incommensurate Scaling • As a system increases in size or speed, not all parts of it follow the same scaling rules • so things stop working. • The mathematical description • Different parts of the system exhibit different orders of growth

  17. 3. Incommensurate Scaling (Cont.) • Galileo in 1638 • To illustrate briefly, I have sketched a bone whose natural length has been increased three times and whose thickness has been multiplied until, for a correspondingly large animal, it would perform the same function which the small bone performs for its small animal. From the figures here shown you can see how out of proportion the enlarged bone appears.

  18. 3. Incommensurate Scaling (Cont.) • Galileo in 1638 • Clearly then if one wishes to maintain in a great giant the same proportion of limb as that found in an ordinary man he must either find a harder and stronger material for making the bones, or he must admit a diminution of strength in comparison with men of medium stature; for if his height be increased inordinately he will fall and be crushed under his own weight.

  19. 3. Incommensurate Scaling (Cont.) • Galileo in 1638 • Whereas, if the size of a body be diminished, the strength of that body is not diminished in the same proportion; indeed the smaller the body the greater its relative strength. Thus a small dog could probably carry on his back two or three dogs of his own size; but I believe that a horse could not carry even one of his own size.

  20. 3. Incommensurate Scaling (Cont.)

  21. 4. Trade-offs • General Models • Limited amount of goodness • Maximize the goodness • Avoid wasting • Allocate where helps most • Waterbed Effect • Pushing down on a problem at one point • Causes another problem to pop up somewhere else

  22. 4. Trade-offs(Cont.) • Binary Classification • We wish to classify a set of things into two categories • based on presence or absence of some property • but we lack a direct measure of that property • so we identify instead some indirect measure • known as a proxy

  23. 4. Trade-offs(Cont.) • Binary Classification (Cont.) • Occasionally this scheme misclassifies something • By adjusting parameters of the proxy • The designer may be able to • reduce one class of mistakes • but only at the cost of increasing some other class of mistakes

  24. How to Handle? • Ideally, the Constructive Theory • Allows the designer systematically to • Synthesize a system from its specifications • Make necessary trade-offs with precision • In some fields • Communication systems • Linear control systems • Design of bridge and skyscrapers (to a certain extent)

  25. How to Handle? (Cont.) • In Computer Systems • We find that we were born too soon • The problems • We work almost entirely by analyzing ad hoc examples rather than by synthesizing • So, in place of a well-organized theory, we use case studies

  26. Terminology • Systems, components, interfaces, environments

  27. Different Views • Example: Different Views of an Aircraft

  28. Different Views (Cont.) • Different Purposes • As a passenger-handling system • e.g. consider engine as a source of noise • e.g. ignore the control surfaces on the wings • Different Granularities • System and subsystem are relative • e.g. engine is a component of aircraft, while itself is a system

  29. Signs of Complexity • Webster’s Definition • “Difficult to understand” • Signs of complexity (like diagnosis in medicine) • Large number of components • Large number of interconnections • Many irregularities • A long description • A team of designers, implementers, or maintainers

  30. Signs of Complexity (Cont.) • Example • Large University Library VS. Small Town Library • More catalogs: aids, guides, journal indexes, etc. • More cross-references • More exception: oversized books over newspaper rack, microfilm or digital media, etc. • No methodical rules for locating a piece of information • More personnel and even specialists

  31. Levels of Complexity • All system are indefinitely • The deeper one digs, the more signs of complexity turn up • A computer -> gates -> electrons -> quarks -> … • Abstraction: limits the depth of digging

  32. Sources of Complexity • Many Goals / Requirements / Features • Interactions among Requirements

  33. Sources of Complexity (Cont.) • More Goals, More Complexities • Examples • 1975 Unix kernel: 10,500 lines of code • 2008 Linux 2.6.24 line counts: • 85,000 processes • 430,000 sound drivers • 490,000 network protocols • 710,000 file systems • 1,000,000 different CPU architectures • 4,000,000 drivers • 7,800,000 Total

  34. Sources of Complexity (Cont.) • More Interacting Features, More Complexities • The point is not that these bad interactions can’t be fixed • The point is that there are so many interactions • Example • Call Forwarding • Call Number Delivery Blocking • Call 900 (reverse billing) • A blocks outgoing call to 900 • A call B, B forwarding to 900 • What happens?

  35. Sources of Complexity (Cont.) • Principles of escalating complexity • Adding a requirement increases complexity out of proportion • The complexity barrier is soft: no warning • Requirements increasing leads exceptions increasing

  36. Sources of Complexity (Cont.) • Principle: Avoid excessive generality • If it is good for everything, it is good for nothing • Generality • Meeting many requirements with a single design • General enough to minimize the number of exceptions • but not “too general” • E.g. design a vehicle that can drive on the highway, fly, use as a boat

  37. Maintain High Utilization • Example: Single Rail • Performance -> complexity • Base design: alternate trains • Low throughput, high delay • Worse than two-track, cheaper than blasting • Lower delay with a siding and two trains • Precise schedule • Risk of collision / signal lights • Siding limits train length (a global effect!) • Point: performance cost super-linear

  38. Maintain High Utilization

  39. Principles • The law of diminishing returns • The more one improves some measure of goodness, the more effort the next improvement will require

  40. Coping with complexity

  41. M.A.L.H • Modularity • Split up system • Consider separately • Abstraction • Interface/Hiding • E.g., standard size windows • Avoid propagation of effects • Layering • Gradually build up capabilities • Hierarchy • Reduce connections • Divide-and-conquer

  42. Modularity • Analyze or design the system as a collection of interacting subsystems • Subsystems called modules • Divide-and-conquer technique • The simplest, most important tool for reducing complexity • Be able to consider interactions among the components within a module • Without simultaneously thinking about the components that are inside other modules

  43. Modularity (Cont.) • Example • Debugging a program with N statements • Number of bugs is proportional to its size • Bugs are randomly distributed Original With Modularity

  44. Modularity (Cont.) Bug Bug Bug Bug Original System System with Modularity

  45. Modularity (Cont.) • The Unyielding Foundations Rule • It is easier to change a module than to change the modularity • Changing the interface requires replacing at least two modules • Once an interface has been used by another module • If an interface is used by many modules • Changing it requires replacing all of those modules simultaneously • It is particularly important to get the modularity right

  46. Abstraction • Abstraction • Treat a module based on external specifications, no need for details inside • Principles to divide a module • Follow natural or effective boundaries • Fewer interactions among modules (Chap.4 & 5) • Less propagation of effects

  47. Abstraction (Cont.) • Examples • DVD players • Registers (circuits to remember states) • Procedure call • Applications with window interfaces • Games, Spreadsheet, Web browsers

  48. Abstraction (Cont.) • Minimizing interconnections among modules may be defeated • unintentional or accidental interconnections, arising from implementation errors • well-meaning design attempts to sneak past modular boundaries • Improve performance • Meet some other requirement

  49. Abstraction (Cont.) • Software is particularly subject to this problem • The modular boundaries provided by the separately compiled subprograms are actually somewhat soft • Is easily penetrated by errors in • using pointers • filling buffers • calculating array indices

  50. Abstraction (Cont.) • System designers prefer techniques • enforce modularity by • interposing impenetrable walls between modules • assure that there can be no • unintentional or hidden interconnections

More Related