如何在Java中编写正确的微基准测试?

时间:2009-02-02 17:39:42

标签: java jvm benchmarking jvm-hotspot microbenchmark

如何用Java编写(并运行)正确的微基准测试?

我正在寻找一些代码示例和评论,说明需要考虑的各种事项。

示例:基准测试应该测量时间/迭代或迭代/时间,以及为什么?

相关:Is stopwatch benchmarking acceptable?

11 个答案:

答案 0 :(得分:730)

关于编写微基准的提示from the creators of Java HotSpot

规则0:阅读有关JVM和微基准测试的着名论文。一个好的是Brian Goetz, 2005。微观基准不要期望太多;它们仅测量有限范围的JVM性能特征。

规则1:始终包含一个完整运行测试内核的预热阶段,足以在计时阶段之前触发所有初始化和编译。 (在预热阶段,迭代次数较少。经验法则是数万次内循环迭代。)

规则2:始终使用-XX:+PrintCompilation-verbose:gc等运行,这样您就可以验证编译器和JVM的其他部分在执行期间没有执行任何意外的工作你的计时阶段。

规则2.1:在计时和预热阶段的开始和结束时打印消息,这样您就可以在计时阶段验证规则2中没有输出。

规则3:请注意-client-server以及OSR和常规编辑之间的区别。 -XX:+PrintCompilation标志报告带有at符号的OSR编译以表示非初始入口点,例如:Trouble$1::run @ 2 (41 bytes)。如果您追求最佳性能,则首选服务器到客户端,并定期访问OSR。

规则4:请注意初始化效果。在打印加载和初始化类时,不要在计时阶段第一次打印。除非您专门测试类加载(并且在这种情况下只加载测试类),否则不要在预热阶段(或最终报告阶段)之外加载新类。规则2是你抵御这种影响的第一道防线。

规则5:了解去优化和重新编译效果。在计时阶段第一次不要采用任何代码路径,因为编译器可能会破坏并重新编译代码,这是基于先前的乐观假设,即路径根本不会被使用。规则2是你抵御这种影响的第一道防线。

规则6:使用适当的工具来阅读编译器的想法,并期望对它产生的代码感到惊讶。在形成关于什么使得更快或更慢的东西的理论之前,自己检查代码。

规则7:降低测量中的噪音。在安静的机器上运行您的基准测试,并运行几次,丢弃异常值。使用-Xbatch将编译器与应用程序序列化,并考虑设置-XX:CICompilerCount=1以防止编译器与自身并行运行。尽量减少GC开销,设置Xmx(足够大)等于Xms并使用UseEpsilonGC(如果可用)。

规则8:使用库作为基准测试,因为它可能更高效,并且已经针对此唯一目的进行了调试。例如JMHCaliperBill and Paul's Excellent UCSD Benchmarks for Java

答案 1 :(得分:231)

答案 2 :(得分:82)

Java基准测试的重要内容是:

  • 首先在之前多次运行代码来预热JIT
  • 确保您运行的时间足够长,以便能够在几秒钟或(更好)数十秒内测量结果
  • 虽然你不能在迭代之间调用System.gc(),但在测试之间运行它是个好主意,这样每个测试都有望获得一个“干净”的内存空间。 (是的,gc()更多的是暗示而不是保证,但是根据我的经验,它真的很可能它真的会被垃圾收集。)
  • 我喜欢显示迭代和时间,以及可以缩放的时间/迭代分数,使得“最佳”算法得分为1.0,而其他算法以相对方式得分。这意味着您可以长时间运行所有算法,同时改变迭代次数和时间,但仍能获得可比较的结果。

我正在撰写有关.NET基准测试框架设计的博客。我有一个coupleearlier posts可能会给你一些想法 - 当然,并不是所有的一切都是合适的,但有些可能是。

答案 3 :(得分:47)

jmh是OpenJDK的最新成员,由Oracle的一些性能工程师编写。当然值得一看。

  

jmh是一个Java工具,用于构建,运行和分析用Java和其他针对JVM的语言编写的nano / micro / macro基准测试。

非常有趣的信息埋藏在the sample tests comments

另见:

答案 4 :(得分:20)

  

基准测量应该测量时间/迭代或迭代/时间,为什么?

这取决于您尝试测试的

如果您对延迟感兴趣,请使用时间/迭代,如果您对吞吐量感兴趣,请使用迭代/时间。

答案 5 :(得分:15)

确保以某种方式使用在基准代码中计算的结果。否则,您的代码可以被优化掉。

答案 6 :(得分:14)

如果您要比较两种算法,请为每种算法至少执行两个基准测试,以交替顺序。即:

for(i=1..n)
  alg1();
for(i=1..n)
  alg2();
for(i=1..n)
  alg2();
for(i=1..n)
  alg1();

在不同的传递中,我在相同算法的运行时发现了一些明显的差异(有时为5-10%)。

此外,请确保 n 非常大,以便每个循环的运行时间至少为10秒左右。迭代次数越多,基准时间内的数字越重要,数据就越可靠。

答案 7 :(得分:13)

在Java中编写微基准测试存在许多可能的缺陷。

首先:您必须计算各种随机时间或多或少随机的事件:垃圾收集,缓存效果(文件操作系统和内存CPU),IO等。

第二:在非常短的时间间隔内,您不能相信测量时间的准确性。

第三:JVM在执行时优化代码。因此,同一JVM实例中的不同运行将变得越来越快。

我的建议:让您的基准测试运行几秒钟,这比运行时间超过毫秒更可靠。预热JVM(意味着至少运行基准测试一次而不进行测量,JVM可以运行优化)。并多次运行您的基准测试(可能是5次)并取中值。在新的JVM实例中运行每个微基准测试(调用每个基准测试新Java),否则JVM的优化效果会影响以后运行的测试。不要执行在预热阶段没有执行的事情(因为这可能会触发类加载和重新编译)。

答案 8 :(得分:8)

还应该注意,在比较不同的实现时,分析微基准测试的结果可能也很重要。因此,应该significance test

这是因为在基准测试的大多数运行期间,实现A可能比实现B更快。但是A可能也有更高的差异,因此与A相比,B衡量的效果优势没有任何意义。

因此,正确编写和运行微基准测试也很重要,但也要正确分析它。

答案 9 :(得分:7)

http://opt.sourceforge.net/ Java Micro Benchmark - 控制在不同平台上确定计算机系统的比较性能特征所需的任务。可用于指导优化决策和比较不同的Java实现。

答案 10 :(得分:7)

为了增加其他优秀建议,我还要注意以下几点:

对于某些CPU(例如带有TurboBoost的Intel Core i5系列),温度(以及当前使用的内核数量以及其利用率百分比)会影响时钟速度。由于CPU是动态计时的,因此会影响您的结果。例如,如果您有单线程应用程序,则最大时钟速度(使用TurboBoost)高于使用所有核心的应用程序。因此,这可能会干扰某些系统上单线程和多线程性能的比较。请记住,温度和波动也会影响Turbo频率的维持时间。

也许您可以直接控制一个更为根本的重要方面:确保您正确测量正确的事情!例如,如果您使用System.nanoTime()对特定代码进行基准测试,请将调用调用放在有意义的位置,以避免测量您不感兴趣的内容。例如,不要这样做:

long startTime = System.nanoTime();
//code here...
System.out.println("Code took "+(System.nanoTime()-startTime)+"nano seconds");

问题是您在代码完成后没有立即获得结束时间。相反,请尝试以下方法:

final long endTime, startTime = System.nanoTime();
//code here...
endTime = System.nanoTime();
System.out.println("Code took "+(endTime-startTime)+"nano seconds");