本文是一篇观点文章，指出计算系统研究需要学习算法领域的经验，探索能够刻画计算系统本质特征的可分析抽象，并提出了一个初步概念，称为算礼，旨在抛砖引玉，促进计算系统抽象的研究.
长期以来，计算系统领域缺乏“算法”这样简洁的学术概念来刻画系统的本质特征，使得系统研究往往依赖原型研制和基准程序测试.这种“原型测试”的计算系统设计方法非常耗时耗资源，研究结果往往难以被他人重现.另一方面，计算机系统结构研究正在进入多样性时代，各种加速器带来的异构硬件、领域特定体系结构(domain-specific architecture)、库操作系统、众多的应用框架、物联网系统的昆虫纲悖论，都是多样性趋势的表现.业界迫切需要超越“原型测试”的计算系统分析与设计方法，尤其需要能够简洁地刻画计算系统的可分析抽象，即在原型测试之前，就能分析出系统重要性质的抽象描述.
计算系统出现多样性趋势主要可以归纳为3个原因:1)应用需求的多样性，尤其是高能效(性能功耗比)的要求，难以被一种通用计算系统满足[1-2]；2)计算系统的范围早已从单机拓展到并行计算机、分布式计算系统；3)计算系统的层次近年来已经从系统硬件层、系统软件层拓展到包括Spark和TensorFlow等系统的应用框架层.
John Hennessy与David Patterson最近指出，计算系统的多样性趋势为计算机系统结构研究带来了又一个黄金时代[2].系统抽象是计算机系统结构研究的一个重要方向.本文学习算法的经验，指出计算系统研究需要能够刻画系统本质特征的可分析抽象，并提出了一个初步候选，称为算礼(computation protocol)，以抛砖引玉，促进学术社区对计算系统可分析抽象的研究.我们讨论了算礼的黑箱模型和白箱模型，并用初步的实例指出，算礼思想有助于在计算系统领域提出系统猜想、分析新的并行计算模型、拓展现有架构、启发新的系统评价方法.
1 计算系统研究需要向算法学习
计算机应用研究离不开计算机科学的一个本质抽象——算法.今天，算法已广泛渗透到计算机科学技术整个领域，包括它的3个二级学科：计算机系统结构、软件与理论、计算机应用.
算法的广泛渗透性得益于它是一个可分析抽象.学习和研究一个算法，并不一定要将该算法实现成程序代码在真实或原型计算机上运行，就可以分析出它的重要性质.事实上，国内外很多算法课程不涉及编程.但是，计算系统领域缺乏“算法”这样的抽象来刻画系统的本质特征，研究计算系统往往需要原型系统构建和基准程序测试.
算法这个抽象具备哪些特点呢？算法不同于程序，它是程序的简洁描述，体现了程序的本质特征.Donald Knuth给出了算法的一般定义[3].
定义1. 五特征算法定义[3].算法是一组有穷的规则，给出求解特定类型问题的运算序列，并具备下列5个特征：
1) 有穷性.一个算法在有限步骤之后必然要终止.
2) 确定性.一个算法的每个步骤都必须精确地(严格地和无歧义地)定义.
3) 输入.一个算法有零个或多个输入.
4) 输出.一个算法有一个或多个输出.
5) 能行性.一个算法的所有运算必须是充分基本的，原则上人们用笔和纸可以在有限时间内精确地完成它们.
定义1使得任何算法实例具备7个优点，我们可从算法概念本身和快速排序算法实例角度进一步说明.
1) 通用性.任何算法实例，不论是快速排序(quicksort)、高斯消元解方程、求最短路径的Dijkstra算法，还是任何串行算法、并行算法、分布式算法，都满足Donald Knuth的五特征算法定义.
2) 易描述.算法比实现该算法的程序往往简洁得多，例如几行伪代码足以精确描述quicksort算法.
3) 易理解.简洁描述特性也使得理解算法更容易，例如quicksort算法的基本逻辑与特色诀窍很容易被理解.
4) 可分析.quicksort算法的时间复杂度、空间复杂度可被严格地分析出来.
5) 可证明.可严格地证明quicksort算法的正确性、复杂度和适用范围.
6) 抽象性.算法不依赖于具体实现技术(硬件及软件)，包括已有技术和未来的技术，英文称这个特性为technology-proof和future-proof.
7) 可重复.有了上述6条优点，算法本身和算法的研究结果具备可重复性(reproducibility)，即他人可复制、可复现和可重用，这是任何科学方法的本质特征.
上述7条优点中，最重要的是可分析抽象.计算系统研究需要能够简洁刻画计算系统本质特征的可分析抽象，使其具备算法的上述7条优点，能够超越原型系统构建和基准程序测试，提升系统研究的效率.
超越原型测试并不是不要原型测试.原型测试仍将是计算系统研究的重要方法.可分析抽象可用在多种系统设计选择中、多次系统设计迭代中，在原型测试之前，筛掉不合适的候选系统，优选剩下的设计，再采用原型测试验证优化.
2 相关工作的历史经验
计算系统可分析抽象的相关研究已有数十年历史，本节讨论了6类研究工作并总结了历史经验.
1) Jim Gray在1999年的图灵奖获奖演说中提出了未来计算机科学技术的12个挑战难题[4]，其中最后一个称为“自动程序员”(automatic programmer)难题，即计算系统应该提供高效编程接口，使得设计应用程序容易1 000倍.如果系统缺乏可分析抽象，很难想象可以实现应用设计容易1 000倍的目标.
2) Leslie Lamport指出:这样的可分析抽象，即刻画系统本质特征的高级设计，是存在的[5].他引用了Tony Hoare的观点：“Inside every large program, there is a small program trying to get out”，其中small program是刻画该large program本质特征的算法，也称为specification或high level design.Lamport开发了TLA+工具，可用于描述串行和并发系统，并对其性质做自动模型检测[6].
3) John Hennessy与David Patterson因提出计算系统的量化设计方法获图灵奖.在回顾其量化设计方法时，Hennessy指出，处理器系统的CPI公式是量化设计方法的重要创新点[7].
事实上，这个公式既简洁又实用.例如，仅用一个指标CPI(clocks per instruction)就能区分出不同的指令集体系结构.CPI>1(即执行一条指令需要多于一拍时钟)对应着CISC体系结构；CPI=1对应着RISC体系结构；CPI<1对应着超标量(superscalar)体系结构.
4) 系统的性质不都是定量的，也有重要的定性性质，例如分布式系统的CAP定理：一个分布式系统能够且仅能够满足一致性(consistency)、可用性(availability)、分区容错性(partition tolerance)三条性质中的2条[8].CAP定理揭示了分布式系统的一种本质的不可能性.这个貌似负面的定性结果被广泛应用于今天的云计算系统、大数据系统、互联网服务系统的设计与实现中.
5) 针对并行计算系统，Leslie Valliant提出了Bulk-Synchronous Parellel(BSP)模型[9].借鉴串行计算机的冯·诺依曼模型经验，BSP提供了一个并行计算机的简洁抽象模型，应用算法研究者不用关心多种多样的真实并行计算系统，而是针对简洁唯一的BSP抽象模型研究并行算法.Valliant证明，不少典型并行算法，当从BSP过渡到真实并行计算机上时，映射开销为O(1).这种在应用算法和真实计算系统之间提供一个简洁抽象模型的思路称为桥接模型(bridging model).今天，BSP已经成为很多真实的并行计算、云计算、大数据系统支持的典型计算系统模式.
6) 针对万维网，Roy Fielding提出了表象状态转移(representational state transfer, REST)体系结构风格[10]，支撑了近20年的PC互联网与移动互联网应用.REST给出了一类系统抽象，即“体系结构风格”(也称为架构风格)：architectural style—an abstraction across many specific application architectures[11].体系结构风格的核心是一组体系结构设计原则,又称为体系结构约束(architectural constraints).例如REST提出了统一界面(uniform interface)、无状态通信(stateless communication)等6条原则.不同的桌面浏览器系统、移动浏览器系统、安卓APP系统、各种WWW服务器系统都遵循这6条REST体系结构设计原则.
上述研究提供了计算系统抽象的6条成功经验.它们表明，未来计算系统抽象应该考虑6个研究方向和目标：1)高效接口，使得应用设计容易1 000倍；2)刻画系统本质特征的高级设计，揭示出大而复杂的系统中的小而简洁的可分析抽象，即the small program trying to get out；3)刻画系统本质特征的定量公式；4)刻画系统本质特征的定性定理；5)真实应用算法与真实计算系统之间的桥接抽象模型；6)覆盖多种真实系统结构的体系结构风格.
3 算礼初探
3.1 算礼的直觉性质
研究算礼的目的是提炼出能够简洁刻画计算系统本质特征的可分析抽象，使得计算系统研究具备算法研究的7条优点.那么，从直觉上看，算礼应该具备什么新性质，为什么不沿用“算法”或“计算模型”这些名称，而是要使用一个新词呢？
Fig. 1 Comparison among arithmetic, algorithm, and computation protocol
图1 算术、算法、算礼之比较
1) 算礼不是算法.图1显示了算礼与算术和算法的区别.算术关注特定数值的加减乘除四则运算.算法关注给定输入数据，能够求出期望的输出数据的计算方法，尤其是时间复杂度/空间复杂度较低的有效方法.算礼关注计算系统的简洁刻画.一个算礼上可运行多个算法.例如图1中的Spark机群可用一个算礼刻画，它可以支持快速排序、k-means聚类等多种算法.给定一个算法，从给定输入可求出期望的输出结果.给定一个算礼，从给定算法和给定输入，才可能求出期望的输出结果.
2) 算礼不等于传统的计算模型.在计算机科学界，计算模型(models of computation)已有特定的定义[12-13]，主要关注各种图灵机、PRAM、I/O自动机等串行、并行和分布式计算模型，这些模型难以刻画Spark机群等计算系统的本质特征，也难以刻画人机物三元计算系统的本质特征.我们可以稍微修改下Tony Hoare的观点，得到：“Inside every large system, there is a small protocol trying to get out.”这个“small protocol”就是该“large system”的算礼.简言之，算礼概念与计算模型有交叉,但不完全等同.
3) 算礼强调秩序和约束.算礼之“礼”(protocol)受中华文化之“礼”的启发，强调系统带来的秩序(order)和约束(constraints).计算机系统结构的研究往往强调和选择不同的约束，例如REST中的体系结构约束(architectural constraints).
4) 算礼(computation protocol)之礼不是comm-unication protocol之protocol(协议)，而是更像自然科学期刊《Nature Protocols》之scientific protocol，强调他人可复制的构造性科学方法、他人可复制可重现可重用的系统抽象.
3.2 算礼的一般表述
我们学习Donald Knuth的五特征算法定义，给出算礼的一般表述(称为PEN刻画).
定义2. 算礼.算礼是一组有穷的规则，给出求解特定类型问题的计算系统，并具备下列4个特征.
1) 负载(payload, P)：算礼支持的应用负载类型.
2) 执行模型(execution model, E)：连接资源的体系结构，说明负载在资源上如何执行.
3) 赋名资源(named abstractions of resources, N)：对负载和执行模型可消耗的资源的明确命名与抽象.
4) 可重复性(reproducibility)：给定算礼的PEN刻画，他人可重现系统与结果.
3.3 算礼的黑箱模型
算礼有白箱表示和黑箱表示.黑箱表示主要涉及P，白箱表示涉及PEN三者，如图2所示.Payload除了算法和数据这些workload之外，还包含5个具体的P，即problem,principle,properties,programming model,policies，他们与workload一起共同刻画了payload需求.算礼的黑箱表示主要关注problem,principle,properties，隐藏了PEN的其他内容.
Fig. 2 The black-box representation and white-box representation of computation protocol
图2 算礼的黑箱表示与白箱表示
任何系统都是被设计用来有效支持一类负载的.它的算礼针对该负载的特有问题(problem)，提出解决该问题的特有的原理(principle)，凸显期望的计算性质(properties).
例如大数据应用框架Spark的设计初衷是针对MapReduce等应用框架不能有效“重用多级计算的中间结果”(reuse intermediate results across multiple computations)的问题[14].MapReduce也可以重用多级计算间的中间结果，但比较低效，其原因有2个：1)中间结果需要存盘；2)为了容错，数据需要复制.Spark解决这个低效问题的原理是“内存计算”(in-memory computing).Spark将数据和中间结果放在一种创新的内存数据抽象RDDs(resilient distributed datasets)中，并通过粗粒度的RDD transformation以及lineage机制实现容错计算.
Spark算礼具备3个性质：1)大多数情况下，数据的存储和计算发生在处理器和内存中，不涉及硬盘；2)特别地，多个RDD transformations的中间结果存放在内存中，不用存盘，从而通过内存计算支持了多级计算；3)容错不是靠多副本，而采用lineage机制，出错时重算，消除了复制开销.
3.4 算礼的白箱模型
算礼的白箱模型暴露的PEN的全部，也称为算礼的PEN模型.
定义3. 算礼的PEN模型.一个算礼是三元组(负载，执行模型，赋名资源)=(P,E,N)，说明如何利用赋名资源执行负载的系统组成和执行规则.三元组的含义说明为：
1) P是负载(payload)，或者说是workloads，说明算礼适用的负载类型，包括支持的(和不支持的)负载.Payload还包括problem,principle,properties,programming model,policies五个更加具体的P.例如，MapReduce系统(MR算礼)主要支持批处理类负载，而不是交互式负载.MR算礼提供分布式系统的MapReduce函数式编程模型[15].
2) E是执行模型(execution model)，即连接并组合赋名资源去实现负载的体系结构和任务执行方式.例如，MR算礼在机群上提供job,tasks的master-slave architecture，以及map-shuffle-reduce三阶段执行方式.
3) N是赋名资源(named abstractions of resources)，为算礼提供模块化的赋名资源和抽象接口.例如，MR算礼提供了机群节点资源抽象和HDFS分布式文件系统资源抽象.
4 算礼实例
4.1 实例1：启发计算系统猜想
云计算系统中各类无序现象(称为计算系统熵)，使得用户体验和系统效率2个目标难以被同时满足.我们提出下一代云计算系统的目标，称为“低熵云计算系统”[16]，要求多个应用负载在数据中心计算机上执行时，既能保证用户体验，又能提高系统利用率.
能否抽象出低熵云计算系统的主要性质？具备什么能力的系统才能同时满足用户体验和系统效率2个目标？为此，我们定义了“实用可计算性”(pro-duction computability)来刻画系统实现用户体验和提高系统效率的能力，并提出了实现“实用可计算性”的充分必要条件的猜想，称为DIP(distinguishing, isolation, prioritizing)猜想.从算礼的黑箱表示看，低熵云计算系统需要考虑3个难题.
1) Problem:低熵云计算系统应该解决什么问题？
对于传统的资源独占式分区云和共享式的虚拟化云，前者能很好实现负载的用户体验，但是系统效率较低；后者理论上支持更高的系统效率，但是却影响了特定负载的用户体验目标.
我们认为“难以同时满足用户体验和系统效率”难题的本质是无序现象.特别地，针对负载干扰的无序现象，由于共享资源的竞争导致了系统的内耗，资源的共享呈现互相的抑制和抢占，既影响了负载的资源保证，也会降低系统的效率.
所以，低熵云计算的主要问题是“在共享式的云计算系统中，如何实现应用负载间的有序共享(减小干扰造成的无序影响)，在保障特定负载的用户体验的基础上，提高系统效率”.
2) Principle：解决这些问题主要原理是什么？
云计算系统需要克服无序性影响，保障负载的用户体验的基础上，提高系统效率.显然，这不只是特定负载有关的性质，而是云计算系统本身的能力：使得负载之间有序共享资源的能力.
我们不妨将云计算系统中的共享资源(时间资源、计算资源、存储资源和通信资源)组成一个四维空间，称为计算时空(cyberspacetime).那么，降低计算系统熵，或者实现负载的实用可计算性的主要原理是时空共享，即多个负载在总线周期粒度有序地共享计算时空，有利于同时保障用户体验和资源利用率.
3) Properties：低熵云计算系统具备什么新的性质才能实现计算时空的有序共享？
我们提出了实现实用可计算性的充分必要条件的猜想，称为DIP猜想：如果应用负载A是实用可计算的，那么在给定用户体验阈值的前提下，云计算系统S实现A的实用可计算性，当且仅当S具备DIP能力.
这3点能力是：区分(distinguishing, D)、隔离(isolation, I)、优先化(prioritizing, P).也就是说，该云计算系统能够在运行时动态地区分、隔离、优先化负载A在系统S的计算时空中执行的相空间.云计算系统具备的3点能力，亦可作为系统的3个性质，即可区分性、可隔离性、可优先化性.
这3个性质的本质是限制云计算系统中的无序影响.无序行为会一直存在，无法彻底消除.但通过系统创新限制住无序的影响范围，从而使计算任务的尾延迟满足用户体验阈值，还是有可能的.
4.2 实例2：启发新并行计算模型
我们提出了分形冯·诺依曼体系结构[17]，一种同构、串行编程、层次化且层次同性的新体系结构.实验表明，具有分形冯·诺依曼体系结构的计算机Cambricon-F在机器学习领域能够解决编程难题，同时性能不弱于目前最先进的GPU系统.但是Cambricon-F仅针对特定领域应用负载、采用了特定的体系结构.我们能否拓展分形冯·诺依曼体系结构的原理，使它能够解决通用领域、广泛的现有体系结构上的编程难题呢？我们通过提出一种新的并行计算模型“分形计算模型”来实现这一目标，而算礼思想要求我们首先回答黑箱表述的3个难题分别是什么.
1) Problem：需要解决的“编程难题”究竟是什么？
目前并行计算模型既有注重于算法分析的理论模型(例如BSP[9],Multi-BSP[18],LogP[19],PRAM[20])，又有注重于编程实现的实用模型(例如MPI[21],OpenMP[22]).然而，现有通用并行计算模型都是并行编程、并行执行(parallel code, parallel execution, PCPE)的.通常我们认为并行编程比串行编程更为困难，因为并行编程需要额外考虑多条执行流之间的同步、通信等问题.
为了简化编程，我们需要实现串行编程、并行执行(sequential code, parallel execution, SCPE)——使用者只编写串行执行的程序，却可以并行、高效地执行在并行计算系统上.如果在分形计算模型上，编程与系统的规模无关，那么无论系统的规模如何，其编程都与在规模最小的系统(即仅具有单一计算节点的串行系统)上同样简单，即可实现SCPE.
并行编程的复杂性，本质来源于并行计算模型具有的编程-规模相关性(programming-scale variance)：当系统规模发生变化时，程序需要重新调整才可保持最优地执行.因此，难题是如何设计分形计算模型，使其具有编程-规模无关性(programming-scale invariance).
2) Principle：解决问题的主要原理是什么？
分形计算模型解决问题的主要原理与分形冯·诺依曼体系结构相同，都是通过将系统刻画为层次同性(isostratal)的层次结构，使系统在不同尺度上具有相同形式的硬件资源抽象、任务负载抽象和执行行为抽象，因此可以做到根据单一层次结构的刻画对系统规模进行任意的扩展.
3) Properties：我们希望分形计算模型具备什么新的性质？
通用性.我们希望分形计算模型是一种具有通用性的并行计算模型，即能够广泛、高效地支持各种可以并行计算的算法.
效率-规模无关性.我们希望分形计算模型的效率不会因系统规模扩展而渐进降低，只有如此，任意扩展系统规模才具有实用意义.
编程-规模无关性.分形计算模型是一种串行编程、并行执行的计算模型，用户无需编写并行程序，即可由分形计算模型自动地展开至任意规模的系统上并行执行.
4.3 实例3：拓展现有体系结构
REST体系结构风格支撑了PC互联网与移动互联网应用.能够进一步将REST拓展到智能万物互联网吗？我们的回答是肯定的，并将拓展后的体系结构风格称为T-REST(representational state transfer for things)[23],如图3所示.从算礼的黑箱表示看，T-REST需要考虑3个难题.
Fig. 3 Transition from PC Internet to mobile Internet only needs to inherit REST; Transition from mobile Internet to IoE needs to extend REST
图3 从PC互联网过渡到移动互联网只需继承REST；再过渡到智能万物互联网需要拓展REST
1) Problem：T-REST架构风格应该解决什么问题？
我们的研究表明，主要问题是：“物端设备应该是WWW客户端还是WWW服务器端”这个client vs. server问题.当PC互联网过渡到移动互联网时，智能手机继承了REST Web，主要思路是将PC上的WWW浏览器适配到智能手机的WWW浏览器和APP.这是合理的选择，因为PC机和智能手机都是人端设备，主要与人交互.但是，在智能万物互联网中，物端设备(不论是固定的还是移动的)主要与物理世界交互，包括传感(sensing)与致动(actuating).物端设备是数据源和制动器，这是服务端的特征.物端设备主要是server，而不是像PC机或智能手机那样的Web client.因此，难题是如何将原本在云端的WWW服务能力有效迁移到物端设备.
2) Principle：解决这些问题的主要原理是什么？
T-REST的核心原理是将超文本(hypertext)和超媒体(hypermedia)拓展为超任务(hypertask)，提供服务端按需代码(server-side code on demand)能力.
3) Properties：T-REST体系结构风格具备什么新的性质？
T-REST主要有2个性质，即2种新的体系结构原则，即计算超文本(computational HyperText, cHT)和可复用远端求值(reusable remote evalua-tion, RREV)，它们合起来提供服务侧按需代码(server-side code on demand)能力[23].
计算超文本原则.我们提出一种具体的新概念，称为计算超文本，去实现超任务.超任务就像超文本(hypertext)和超媒体(hypermedia)一样，也由URI超链接指向，通过传统的REST协议调用.引入超任务不违反“hypermedia as the engine of application state”的REST基本原则，但将超媒体的内涵从数据内容拓展到了任务代码.
可复用远端求值原则.一旦一个超任务被成功部署到某个云端或边缘端设备上，它就自动变成了一个Web资源和Web服务.该服务不是一次性的，而是具有持续复用的特点.例如执行HTTP方法“PUT http://edge.things.ac.cn/recognition_result recognize.cht”将超任务recognize.cht部署到边缘服务器edge上，并自动生成一个全球可访问的RESTful资源与服务，其URI为http://edge.things.ac.cn/recognition_result.
4.4 实例4：启发新的系统评价方法
物端设备通常是资源受限的计算系统，在评价物端计算系统性能时，不能仅考虑基准程序的执行性能，还需要考虑每类负载对物端计算系统的资源利用效率.为此，我们提出了资源服务效率(resource serve efficiency, RSE)匹配模型和归一化的匹配度量，用于评价物端计算系统性能.从算礼的黑箱表示看，RSE匹配模型需要考虑3个难题.
1) Problem：RSE匹配模型需要反映的性能指标具体是什么？
传统的计算系统性能评价方式是将每个基准程序的测试结果进行几何平均得到系统性能的量化指标.而设计物端计算系统时，在保证特定负载的执行性能的同时，还会考虑尽量减少负载对资源的占用，则物端计算系统的评价方法也应该将资源利用效率考虑至性能评价模型中.因此，难题是如何使用一个量化指标同时反映负载执行性能和系统资源利用效率.
2) Principle：解决问题的主要原理是什么？
RSE匹配模型解决问题的主要原理是使用“木桶原理”对每个资源针对负载的服务效率进行加权平均，从而获得系统-负载的匹配度量化指标.资源服务效率即为单个资源在不同利用率下负载执行性能曲线的积分；“木桶原理”的量化表达即为匹配度较低的资源代表系统的性能瓶颈，则其对系统-负载的匹配度应占有更高的计算权重，反之亦然.
3) Propertie：RSE匹配模型具备什么性质？
归一化的性能度量.RES匹配模型提供的系统-负载的匹配度指标以及每个系统资源分量的匹配度指标均是归一化的形式.归一化的性能量化指标为物端计算系统提供横向比较的基准，同时也为系统和负载性能优化给出了理论的性能优化上界.
反映系统性能瓶颈.负载和系统的匹配度指标可以对系统性能进行整体量化，而每个系统资源分量的匹配度指标则可以揭示出针对特定评测程序系统存在的性能瓶颈，为系统和负载性能优化提供方向.
我们在智能网联车计算系统基准测试程序集CAVBench[24]中提出了RSE匹配模型一种具体的量化计算公式，使用该计算公式本文给出一个具体的优化实例：在物端计算系统Intel FRD[25]上使用深度学习框架TensorFlow1.12运行目标检测算法SSD[26]，得到系统的CPU利用率、内存带宽、内存脚迹资源与负载的匹配度分别为0.08，0.14和0.23，计算可得该系统与SSD负载的匹配度为0.15，负载实际执行性能为2.5 FPS；RSE模型指出了CPU资源为该系统在执行SSD负载时的性能瓶颈，则使用TensorFlow的SIMD指令编译优化，优化后CPU利用率、内存带宽、内存脚迹资源匹配度分别为0.18，0.22和0.38，系统与SSD负载的匹配度则提高至0.25，SSD负载实际执行性能提高至4 FPS.
5 结 论
针对计算机系统结构领域的多样性趋势和挑战，本文指出需要研究计算系统的可分析抽象，即在原型测试前就能分析出计算系统本质特征的学术抽象.针对计算系统可分析抽象，本文归纳3个初步结论.
1) 继承算法的7条优点.本文回顾了Donald Knuth的五特征算法定义及其带来的算法的7条优点，并倡导计算机系统结构领域应该学习算法领域的成功经验，研究计算机科学的一个新概念：算礼.算礼是简洁刻画计算系统本质特征的可分析抽象，其目标是使得计算系统研究具备算法的7条优点，能够超越原型系统构建和基准程序测试，提升计算系统研究的效率.
2) 学习系统研究的6条经验.本文总结了6条历史经验，它们建议了计算系统抽象应该考虑的研究方向和目标：①高效接口，使得应用设计容易1 000倍；②刻画系统本质特征的高级设计，尤其是对Tony Hoare观点的修改：Inside every large com-puting system, there is a small computation protocol trying to get out；③刻画系统本质特征的定量公式；④刻画系统本质特征的定性定理；⑤真实应用与真实系统之间的桥接抽象模型；⑥覆盖多种真实系统结构的体系结构风格.
3) 以PEN刻画为特点的算礼思想有助于启发计算系统研究.本文提出了算礼的一个初步定义，即(负载，执行模型，赋名资源)刻画，简称为PEN模型.一个算礼可由它所支持的应用负载(payload)、执行模型(execution model)、赋名资源(named abstr-actions of resources)三元组刻画，并有只考虑P的黑箱表示以及考虑PEN全体的白箱表示.我们讨论了4个算礼研究实例，即低熵云计算系统的DIP猜想、分形并行计算模型、万物互联系统的T-REST架构风格、智能物端系统的性能匹配度模型.
这些实例和历史经验表明：与算法抽象相比，计算系统的可分析抽象研究还处于起步阶段，有不少研究问题和机会；算礼思想有助于在计算系统领域启发新的猜想、新的计算模型、新的架构风格、新的系统评价度量.
[1]Xu Zhiwei, Chi Xuebin, Xiao Nong. High-performance computing environment: A review of twenty years of experiments in China[J]. National Science Review, 2016, 3(1): 36-48
[2]Hennessy J L, Patterson D A. A new golden age for computer architecture[J]. Communications of the ACM, 2019, 62(2): 48-60
[3]Knuth D E, The Art of Computer Programming, Volume 1: Fundamental Algorithms, Third Edition[M]. Reading, MA: Addison-Wesley, 1997(Knuth D E. 计算机程序设计艺术(卷1)：基本算法(第3版)[M]. 苏运霖,译. 北京: 国防工业出版社, 2002)
[4]Gray J. What next? A dozen information-technology research goals[J]. Journal of ACM, 2003, 50(1): 41-57
[5]Lamport L. If you’re not writing a program, don’t use a programming language[J]. Bulletin of the EATCS, 2018, 125(1): 95-116 [2020-01-31]. http://www.heidelberg-laureate-forum.org/video/lecture-if-youre-not-writing-a-program-dont-use-a-programming-language.html
[6]Lamport L. Specifying Systems: The TLA+ Language and Tools for Hardware and Software Engineers[M]. Reading, MA: Addison-Wesley, 2002
[7]O’Hanlon, C. A conversation with John Hennessy and David Patterson[J]. ACM Queue, 2006, 4(10): 14-22
[8]Brewer E. CAP twelve years later: How the “rules” have changed[J]. Computer, 2012, 45(2): 23-29
[9]Valiant L G. A bridging model for parallel computation[J]. Communications of the ACM, 1990, 33(8): 103-111
[10]Fielding R T. Architectural styles and the design of network-based software architectures[D]. Irvine, CA: University of California, 2000
[11]Fielding R T, Taylor R N, Erenkrantz J R, et al. Reflections on the REST architectural style and principled design of the modern Web architecture (impact paper award)[C] //Proc of the 2017 11th Joint Meeting on Foundations of Software Engineering. New York: ACM, 2017: 4-14
[12]Savage J E. Models of Computation: Exploring the Power of Computing[M]. Reading, MA: Addison-Wesley, 1998
[13]Lynch N A. Distributed Algorithms[M]. San Francisco, CA: Morgan Kaufmann, 1996
[14]Zaharia M, Chowdhury M, Franklin M J, et al. Spark: Cluster computing with working sets[C] //Proc of the 2nd USENIX Workshop on Hot Topics in Cloud Computing. Berkeley, CA: USENIX Association, 2010
[15]Dean J, Ghemawat S. MapReduce:Simplified data processing on large clusters[J]. Communications of the ACM, 2008, 51(1): 107-113
[16]Xu Zhiwei, Li Chundian. Low-entropy cloud computing systems[J]. SCIENTIA SINICA Informationis, 2017, 47(9): 1149-1163(in Chinese)(徐志伟, 李春典. 低熵云计算系统[J]. 中国科学:信息科学, 2017, 47(9): 1149-1163)
[17]Zhao Yongwei, Du Zidong, Guo Qi, et al. Cambricon-F: Machine learning computers with fractal von Neumann architecture[C] //Proc of the 46th Int Symp on Computer Architecture. New York: ACM, 2019: 788-801
[18]Valiant L G. A bridging model for multi-core computing[J]. Journal of Computer and System Sciences, 2011, 77(1): 154-166
[19]Culler D, Karp R, Patterson D, et al. LogP: Towards a realistic model of parallel computation[C] //Proc of the 4th ACM SIGPLAN Symp on Principles and Practice of Parallel Programming. New York: ACM, 1993: 1-12
[20]Fortune S, Wyllie J. Parallelism in random access machines[C] //Proc of the 10th Annual ACM Symp on Theory of Computing. New York: ACM, 1978: 114-118
[21]Gropp W, Lusk E, Skjellum A. Using MPI: Portable Parallel Programming with the Message-Passing Interface[M]. Cambridge, MA: MIT Press, 1999
[22]Dagum L, Menon R. OpenMP: An industry-standard API for shared-memory programming[J]. IEEE Computational Science and Engineering, 1998, 5(1): 46-55
[22]Xu Zhiwei, Chao Lu, Peng Xiaohui. T-REST: An open-enabled architectural style for the Internet of things[J]. IEEE Internet of Things Journal, 2018, 6(3): 4019-4034
[24]Wang Yifan, Liu Shaoshan, Wu Xiaopei, et al. CAVBench: A benchmark suite for connected and autonomous vehicles[C] //Proc of the 3rd IEEE/ACM Symp on Edge Computing. Piscataway, NJ: IEEE, 2018: 30-42
[25]Intel Corporation. Intel’s Fog Reference Design Overview[EB/OL].[2020-01-31]. http://www.intel.com/content/www/us/en/internet-of-things/fog-reference-design-overview.html
[26]Liu Wei, Anguelov D, Erhan D, et al. SSD: Single shot multibox detector[C] //Proc of the 14th European Conf on Computer Vision. Berlin: Springer, 2016: 21-37
