《人月神话(40周年中文纪念版)》:
作为成本的程序空间
程序有多大?除了运行时间以外,它所占据的空间也是主要开销。这同样适用于专用开发的程序,用户支付给开发者一笔费用,作为必要分担的开发成本。考虑一下IBMAPL交互式软件系统,它的租金为每月400美元,在使用时,它至少占用160K字节的内存。在Model165上,内存租金大约是12美元/每月·千字节。如果程序在全部时间内都可用,他需要支付400美元的软件使用费和1920美元的内存租用费。如果某个人每天使用APL系统4小时,他每月需要支出400美元的软件租金和320美元的内存租用费。
常常听到的一个“可怕的”谈论是在2M内存的机器上,操作系统就需要占用400K内存。这种言论就好像批评波音747飞机,仅仅因为它耗资2700万美元一样无知。我们首先必须问的是“它能干什么?”对于所耗费的资金,获得的易用性和性能(高效的系统利用)是什么?投资在内存上的每月4800美元的租金能否比用在其他硬件、编程人员、应用程序上更加有效?
当系统设计者认为对用户而言,常驻程序内存的形式比加法器、磁盘等更加有用时,他会将硬件实现中的一部分移到内存上。相反,其他的做法是非常不负责任的。所以,应该从整体上进行评价。没有人可以在自始至终提倡更紧密的软硬件设计集成的同时,又仅仅就规模本身对软件系统提出批评。
由于规模是软件系统产品用户成本中如此大的一个组成部分,开发人员必须设置规模的目标,控制规模,考虑减小规模的方法,就像硬件开发人员会设立元器件数量目标,控制元器件的数量,想出一些减少零件的方法。同任何开销一样,规模本身不是坏事,但不必要的规模是不可取的。
规模控制
对项目经理而言,规模控制既是技术工作的一部分,也是管理工作的一部分。他必须研究用户和用户需求,以设置待开发系统的规模。接着,把这些系统划分成若干部分,并设定每个部分的规模目标。由于“规模一速度”权衡方案的结果在很大的范围内变化,规模目标的设置是一件颇具技巧的事情,需要对每个可用方案有深刻的了解。聪明的项目经理还会给自己预留一些空间,在工作推行时分配。
在OS/360项目中,即使所有的工作都完成得相当仔细,我们依然从中得到了一些痛苦的教训。
首先,仅对核心程序设定规模目标是不够的,必须把所有方面的规模都编入预算。在先前的大多数操作系统中,系统驻留在磁带上,长时间的磁带搜索意味着它无法自如地运用在程序片段上。OS/360和它的前任产品Stretch操作系统和1410-7010磁盘操作系统一样,是驻留在磁盘上的。它的开发者对自由、廉价的磁盘访问感到欣喜。而如果使用磁带,会给性能带来灾难性的后果。
在为每个单元设立核心规模的同时,我们没有同时设置访问的预算。正如大家能想到的一样,当
程序员发现自己的单元核心未能达到要求时,他会把它分解成覆盖模块。这个过程本身增加了程序整体的规模,并降低了运行速度。最重要的是,我们的管理控制系统既没有度量,也没有捕获这些问题。每个人都汇报了内核的大小,由于都在目标范围之内,所以没有人发现规模上的问题。
幸运的是,OS/360性能模拟程序投入使用的时间较早。第一次运行的结果反映出很大的麻烦。FortranH在带磁鼓的Model65上,每分钟模拟编译5条语句。嵌入的例程显示控制程序模块进行了很多次磁盘访问。甚至使用频繁的监控模块也犯了很多同样的错误,结果很类似于页