量化研究方法

⚠ 转载请注明出处：作者：ZobinHuang，更新日期：Nov.15 2021

本作品由 ZobinHuang 采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可，在进行使用或分享前请查看权限要求。若发现侵权行为，会采取法律手段维护作者正当合法权益，谢谢配合。

1. 测试、报告和总结计算机性能

1.1 评估指标

一般来说，我们有两种指标来衡量一个计算机系统的性能指标："执行时间 (Execution Time)" 和 "吞吐量 (Throughput)"。下面分别进行讨论。

执行时间

"执行时间 (Execution Time)" 是针对单任务来说的，常见的对其的定义是完成一个任务所需要的时间，包括磁盘访问、内存访问、I/O 操作和操作系统开销等等，这样的定义又被称为 "Wall-clock/Response/Elapsed Time"。

对于一个多任务系统来说，当一个程序在等待阻塞性 I/O 操作的回复时，通常会调度其它的任务来填补等待时间空白。"CPU 时间 (CPU Time)" 用于描述处理器实际运行当前程序的时间，而不包括上述的 I/O 等待时间。CPU 时间的计算方式如下所示：

CPU Time = #CPU Cycle`\times`Cycle Duration = #CPU Cycle/Frequency

因此提升系统运行一个程序的方法有两种：减少时钟周期数，或者增加时钟频率。

另外，针对上述公式，我们使用 Clock cycle per Instruction (CPI) 的概念来帮助我们计算 CPU 时钟周期数，CPI 标识执行每条指令所需的平均时钟周期数，是一个程序全部指令所用时钟周期数的平均值，即：

# CPU Cycle = #Instruction`\times`CPI

所以我们有：

CPU Time = #Instruction`\times`CPI`\times`Cycle Duration = (#Instruction`\times`CPI)/Frequency

因此，我们在比较两台计算机性能时应该综合考虑三个因素：

指令数：可以使用仿真器软件工具测出;
CPI：与计算机各种设计细节密切相关，以及应用程序中不同类型指令所占的比例;
时钟频率：通常由硬件手册直接给出

吞吐量

"吞吐量 (Throughput)" 是针对数据中心来说的，常见的定义就是单位时间内所做的工作总量。

另外我们还有一个工业性能指标："Millions of Instructions per Second (MIPS)"，其计算方式如下所示：

`MIPS = ((# Instructions)/(benchmark) \times (benchmark)/(t o tal \quad run \quad time))/(1,000,000)`

注意！MIPS 只有在相同指令集下的系统进行比较才有意义。

1.2 测试基准 (benchmark)

基准测试程序 (benchmarks) 可以用于测试系统的性能。常见的 benchmarks 分类如下所示：

Kernels: 从实际的程序中抽取少量较短的关键程序框架代码构成，这些代码的执行直接影响程序总的执行时间。如 Livermore Loops 和 Linpack;
Toy Programs: 代码在 10 ~ 100 行，具有特定目的测试程序。如 Sieve of Erastosthenes, Puzzle 和 Quieksort;
Synthetic Benchmarks (综合测试程序): 对一大套应用程序中的操作和操作数的执行频率进行统计，得到平均执行频率，再按这个频率编制的模拟测试程序。如 Whetstone 和 Dhrystone;

基准测试程序可以针对一个系统的某些方面，如 floating point & integer 运算, memory system 和 I/O等。

通用基准测试程序可能是一个误导，因为硬件和编译器的供应商或许会只针对这些基准测试程序优化他们的设计。编译通过利用结构的特点可以提高性能。应用程序特定的编译器优化已越来越流行。最好的基准测试程序就是实际应用程序，因为它们反应了终端用户的需要。

我们可以选择一组有代表性的不同类型应用程序，集中起来构成基准测试程序集，以有效评测计算机处理各种应用的性能。这种测试程序集合也称为测试程序组件 (benchmark suites)，常见的 benchmark suites 如 SPEC，TPC 等。

SPEC

System Performance Evaluation Cooperation (SPEC) 是最成功的性能测试标准化组织，其目的是为了保证市场有一套公平和实用的指标来区分不同的候选系统，其基本方法是提供基于现有应用程序的一套标准化源代码作为基准测试程序集。

单就测试单核心处理器性能来说，有两种 benchmark 的分类：CPU-intensive benchmarks 和 Graphics-intensive Benchmarks，前者用于测量通用处理器的计算性能，后者更着重于图形渲染性能，我们重点关注前者：对于通用处理器的计算性能测量，SPEC 开发了一套 benchmark suite：SPEC CPU，现在经常使用的是它的第五个版本 SPEC CPU 2006，它包含了 12 个整数基准测试程序集以及 17 个浮点数基准测试程序集，下面是它的具体程序内容，上面 12 个是整数性能测试程序，下面的 17 个是浮点数性能测试程序。

SPEC 还提供了很多其他的 Benchmark Suites：用于测试多核处理器性能的 SPECrate，用于测试文件服务器的 SPECSFS，用于测试 Web 服务器性能的 SPECWeb 等等。

对于测试结果，为了简化，SPEC 使用了一个单一的数字来归纳所有基准程序的测试结果，具体方法是：将被测计算机的执行时间标准化，即将被测计算机的执行时间除以一个参考处理器的执行时间，结果成为SPECratio。该值越大，表示性能越快，然后再取这些SPECratio的几何平均值。

TPC

除了上面提到的基于 SPEC 的各种测试场景，事务处理测试基准 (Transaction-processing Benchmarks) 对于基于事务的系统 (e.g. 数据库等) 来说是十分重要的。在上个世纪 80 年代中期，一群工程师建立了独立于厂商的 Transaction Processing Coucil (TPC)，专门为基于事务的系统创建真实的和公平的 benchmark。

2. 量化原则

2.1 利用并行性

在处理器系统上，我们应该注意利用系统提供的并行性 (parallelism)，比如，有以下几个层次：

线程级或者任务级: 使用多个处理器，GPU;

指令级: 流水线、超标量、OOO 等;

操作级: 并行加法器、组相联 cache、功能部件流水线、

2.2 局部性原理

根据经验我们容易观察到：一个程序 90% 的时间只会执行 10% 的代码，也即程序具有时间局部性 (Temporal Locality) (i.e. 最近访问过的内存单元很可能近期将被再次访问) 和空间局部性 (Spatial Locality) (i.e. 地址相近单元的内容趋向于在一定时间内被相近访问)。因此，计算机系统的设计理念中很重要的一条就是要重点针对 Common Case 进行优化。

量化这个原则的基本定律是 Amdahl's Law，其关键内容是：系统中某一部件由于采用某种更快的执行方式后所获得系统性能的提高，与这种执行方式的使用频率或占总执行时间的比例有关。Amdahl 定律定义了一台计算机系统采用某种改进措施所取得的加速比：

加速比 (Speedup) = `(Origi n \quad Duration)/(Fi x i ng \quad Duration)` = `(Fixed \quad Perfo rmance)/(Origi n \quad Perfo rmance)`

Amdahl 定律中，加速比与两个因素有关：

在原有的计算机上，能被改进的部分在总执行时间中所占的比例，这个值称为改进比例 (Enhanced Fraction)，记为 `Fraction_(enhanced)`，简记为 `F_e`，它总小于等于 1;
改进部分采用改进措施后，相比没有采用改进措施前性能提高的倍数，这个值称为改进加速比 (Enhanced Speedup)，记为 `Speedup_(enhanced)`，简记为 `S_e`，它总大于 1;

基于上述两个值，我们可以得到一些结论：

改进后整个任务的执行时间为：`T_n = T_0 (1 - F_e + F_e/S_e)`
改进后整个系统的加速比 `S_n` 为：`S_n = T_0/T_n = 1/((1-F_e) + F_e/S_e)`