注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

zorksylar

Nothing is impossible , if distributed.

 
 
 

日志

 
 

【6.033】【notes】Lec1 : Intro to systems  

2012-08-07 16:45:52|  分类: Distributed |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
Common problems of systems in many fields :
     Emergent Properties : Emergent properties are properties that are not evident in the individual components of a system, but show up when combining those components, so they might also be called surprises. Some things turn up only when a system is built.
     Propagation of effects : When you change a small part of a system , that may render many effects that associate with that part. some effects are obvious , in complicated systems, as the analysis continues, more distant and subtle effects normally appear. Folk wisdom characterizes propragation of effects as :" There are no small changes in a large system".
     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 of this problem is that different parts of the system exhibit different orders of growth.
     Trade-offs : The general model of a trade-off is that there is a limited amount of some form of goodness in the universe, and the design challenge is first to maximize that goodness, second to avoid wasting it , and thrid to allocate it to the places where it will be help  the most.

Sources of System Complexity
     Cascading and interacting requirements 
     The accumulation of many requirements adds not only their individual complexities but also complexities from their interactions. This interaction complexity arises from pressure for generality and exceptions that add complications ,and it is made worse by change in individual requirements over time. So, Adding a requirement increases complexity out of proportion.
       【6.033】【notes】LEC1 Intro to systems - sylareclipse - zorksylar
     Meeting many requirements with a single design is sometimes expressed as a need for generality. Generality may be loosely defined as " applying to a variety of circumstances ". Unfortunately, Generality contributes to complexity, so it comes with a trade-off, and the designer must use good judement to decide how much of the generality is actually wanted. So, 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 exceptions that must be handled as special cases. This area is one where the judgment of the system designer is most evident.
     A major source of complexity is that requirements change. 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 finally do surface, the maintainer may again find it most expedient to deal with it locally, perhaps by adding exceptions. Incommensurate scaling effect begin to dominate behavior when a later maintainer scales a system up in size or replaces the underpinnings with a faster hadware.The first response to these effects is usually to make local changes( sometimes called patches) to conteract them rather than to make fundamental changes in design that would require changing several moduales or changing interfaces between modules.
     Maintaining high utillization
     One requirement by itself is fequently a specific source of complexity. It starts with a desire for high performance or high efficiency. Whenever a scarce resource is involved, an effort arises to keep its utillization high.  The more completely one tries to use a scare resource , the greater the complexity of the strategies for use , allocation, and distribution. So , The more one improves some measure of goodness, the more effort the next improvement will require.
【6.033】【notes】LEC1 Intro to systems - sylareclipse - zorksylar
 
Dealing with Complexity I
     some common techniques for coping with complexity : modularity, abstraction, hierarchy, layering.
     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 subsystem, called modules. 
     The feature of modularity 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. At the same time, it is import to recognize the unyielding foundations rule : It is easier to change a module than to change the modularity. It is particularly important to get the modularity right.

     Abstraction
     The best division usually follow natural or effective boundaries. They are characterized by fewer interactions among modules and by less propagation of effects from one module to another, and more gengerally by the ability of any module to treat all the others entirely on the bases of their external specifications, without need for knowledge about what goes inside. The additional requirement on modularity is called abstraction. I think the most perfect way to modularity is abstraction. Abstraction nearly always accompaines modularity . One sometimes sees the term functional modularity used to mean modularity with abstraction.
     Well-designed and properly enforced modular abstraction are especially important in limiting the impact of faults because they control propagation of effects.
     Closely related to abstraction is an important design rule that makes modularity work in practice :  The robustness principle -- Be tolerant of inputs and strict on outputs.
     At the same time , there is a tension between the robustness principle and another important design principle : The safety margin principle -- Keep track of the distance to the cliff, or you may fall over the edge.  That means , it is important to track and report out-of-tolerance-inputs ,even if the robustness principle would allow them to be interpreted sucessfully.

     Layers
     Systems that are designed using good abstraction tend to minimize the number of interconnections among their component modules. One powerful way to reduce module interconnections is to empoly a particular method of module organization known as layering.
     In designing with layers, one build a set of mechanisms that is already complete( a lower layer) , and uses them to create a different complete set of mechanisms( an upper layer). A layer may itself be implemented as serveral modules, but as a general rule, a module of a given layer interact only with its peers in the same layer and with the modules of the next higher and next lower layer. That restriction can significantly reduce the number of potential inter-module interactions in a big system.

     Hierarchy
     Start with a small group of modules ,and assemble them to a stable , self-contained subsystem that has a well-defined interface. Next , assemble  a small group of subsystems to produce a larger subsystem. This process continues until the final system has been constructed from a small number of relatively large subsystems. The result is a tree-like structure known as hierarchy.
     Large organizations such as corporations are nearly always set up this way, with a manager responsible for only five to ten employees, and a higher-level manager responsible for five to ten managers, on up to the president of the company, who may supervise five to ten vice-presidents.Even layers can be thought of as a kind of degenerate one-dimensional hierarchy.    
     This can also reduce interconnections among modules.
     In Simon's paper “The Architecture of Complexity " : 
     The fact ,then , that many complex systems have a nearly decomposable, hierarchic structure is a major facilitating factor enabling us to understand , to describe , and even to "see" such systems and their parts. Or perhaps the proposition shoud be put the other way round. If there are important systems in the world that are complex without being hierarchic, they may to a considerable extent escape our observation and our understanding.  Analysis of their behavior would involve such detailed knowledge and calculation of the interactions of their elementary parts that it would be beyond our capacties of memory or computation.
     If you want to understand Hierarchy deepley and want to konw why Hierarchy , read Simon's "The Architecture of Complexity" , that paper is f***ing HOT!


     Names make connections
     Modularity, Abstraction, Layering , Hierarchy   provide ways of dividing things up and placing the resulting modules in suitable relation one to another. But, How to connect those modules together? In digital systems , the primary connection method is that one module names another module that it intends to use. Names allow postponig of decisions, easy replacement of one module with a better one, and sharing modules. 
     In a modular system, one can find serveral ways to combine modules to implement a desired feature. The designer must at some point choose a specific implementation from among many that are avaliable.   Making this choice is called binding.
     The designer usually tries to maintain maximum fexibility by delaying binding until the last possible instant, perhaps even until the first instant that the feature is actually needed.
     One way to delay binding is , rather than implementing a feature, just name it. Using a name allows one to design a module as if a feature of another module exists, even if that feature has not yet been implemented, and it also makes it mechanically easy to later choose a different implementation.By the time the feature is actually invoked , the name must be bound to a real implementation of the other module. Using a name to delay or allow changing a binding is called indirection.
     Decouple modules with indirection : Indirection supports replaceability. (???? mark)
     David Wheeler of the University of Cambridge, exaggerates the power of indirection by claiming that
 “any problem in a computer system can be solved by adding a layer of indirection.”  A somewhat more plausible counterpart of this folk wisdom is the observation that a computer system can be made faster by removing a layer of indirection.
  评论这张
 
阅读(327)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018