健壮的java基准测试，第2部分统计和解决方案.doc

健壮的Java基准测试,第2部分统计和解决方案
程序性能一直是受到关注的问题,即使在现在这样的高性能硬件时代,也是如此。本文是分两部分的文章系列的第二篇,讨论基准测试的统计问题并提供一个框架,可以用这个框架对各种 Java™代码进行基准测试,包括自我包含的微基准测试和调用整个应用程序的代码等等。
本系列的解释了与 Java 代码基准测试相关联的许多问题。本文讨论另外两个领域。首先,讨论一些有助于克服基准测试中不可避免的度量偏差的统计技术。然后,介绍一个软件基准测试框架并对一系列示例使用这个框架,以说明要点。
统计
如果只需执行一次执行时间度量,然后就可以用单一度量值比较不同代码的性能,那就太方便了。遗憾的是,这种方法虽然很流行,但是很不可靠。有许多因素会导致结果的偏差,所以无法信任单一度量值的精确性。在)。
我在本文中只讨论解决以下这些常见性能问题所需的统计技术:
1. 任务 A 是否比任务 B 执行得快?
2. 这个结论可靠吗?还是由于度量的误差造成的假像?
如果做多次执行时间度量,那么首先要计算的统计数据可能是一个代表典型值的单一数字(中的一篇 Wikipedia 文章定义了本文涉及的统计学概念)。最常用的计算方法是算术平均值,通常称为平均值或均值,也就是所有度量值的和除以度量值的数量:
本文配套网站上的补充资料(参见)讨论了除平均值之外的其他统计数据;参见其中的Alternatives to the mean一节。
用几个度量值的平均值来量化性能,肯定比使用单一度量值更准确,但这还不能判断哪个任务执行得更快。例如,假设任务 A 的平均执行时间是 1 毫秒,任务 B 的平均执行时间是 毫秒。能够由此得出任务 A 比任务 B 快的结论吗?如果您知道任务 A 的度量值范围是 到 毫秒,任务 B 的度量值范围是 到 毫秒,恐怕就不会下这样的结论了。因此,还需要解决度量值的跨度。
描述度量值跨度(或者说漂移)的最常用统计技术是标准偏差(standard deviation):
标准偏差如何量化度量值漂移?它依赖于您对度量值的概率密度函数(probability density function,PDF)的认识。您做的假设越强,得到的结论就越好。本文补充资料的Relating standard deviation to measurement scatter一节详细解释了这个概念并得出以下结论:在基准测试上下文中,合理的经验规则是至少 95% 的度量值应该落在平均值的三倍标准偏差的范围内。
那么,如何用平均值和标准偏差判断两个任务中哪一个更快呢?根据上面的经验规则,最简单的情况是两个任务的平均值之差超过了三倍标准偏差(选用两个标准偏差中较大者)。在这种情况下,平均值小的任务显然在大多数时候都更快,见图 1:
图 1. 平均值之差超过三倍标准偏差,这表示可以明确分辨出性能差异
图 2. 平均值之差小于三倍标准偏差,性能数据出现重叠
可靠性
要解决的另一个问题是,这些平均值和标准偏差统计值本身的可靠性如何。显然,这些数据是从度量值计算出来的,所以另一组度量值很可能产生不同的统计值。现在,假设度量过程是有效的。(注意:不可能测量出“真实的”标准偏差。补充资料的Standard deviation measurement issues一节解释了这个问题)。那么,如果重复执行度量过程,平均值和标准偏差会有多大变化?另一组度量值会产生明显不同的结果吗?
要回答这些问题,最明显的方法是为统计数据构造置信区间(confidence interval)。置信区间并不是统计数据的单一计算值(估值点[point estimate]),而是一个估值范围。与这个范围相关联的概率 p 称为置信水平(confidence level)。在大多数情况下,设 p 为 95%,这个值在置信区间比较期间保持不变。置信区间的意义很直观,因为它们的大小表示可靠性:窄的区间表示统计数据比较精确,宽的区间表示统计数据不太确定。例如,如果任务 A 的平均执行时间的置信区间是[1, ] 毫秒,任务 B 是[, ] 毫秒,那么 B 的平均值就比 A 可靠性高,还可以确认它的值比 A 小(在置信水平上)。补充资料的Confidence intervals一节详细讨论了这个问题。
在以前,只能针对一些常见的 PDF(比如 Gaussian)和简单的统计数据(比如平均值)计算置信区间。但是,在 20 世纪 70 年代晚期,开发出了一种称为bootstrapping的技术。这是一种用来产生置信区间的通用技术。它适用于任何统计数据,而不只是平均值这样的简单数据。