问题:如何用Java编写正确的微基准?

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

我正在寻找一些代码示例和注释,以说明要考虑的各种事情。

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

相关:秒表基准测试是否可以接受?

标签:java,jvm,benchmarking,jvm-hotspot,microbenchmark

回答1:

关于编写微型基准测试的提示来自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字节)。如果您追求最佳性能,则优先选择服务器而不是客户端,并经常选择OSR。

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

规则5::请注意反优化和重新编译的效果。在时序阶段不要第一次使用任何代码路径,因为基于较早的乐观假设(即根本不会使用该路径),编译器可能会垃圾并重新编译代码。规则2是抵御此类影响的第一道防线。

规则6::使用适当的工具来阅读编译器的思想,并期望对其生成的代码感到惊讶。在形成有关使事物变快或变慢的理论之前,请自己检查代码。

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

规则8:使用一个库作为您的基准测试,因为它可能更有效,并且已经针对该目的进行了调试。例如 JMH 卡尺条例草案和Paul的Java优秀UCSD基准测试

回答3:

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

  • 通过在计时之前多次运行代码来对JIT进行预热
  • 确保将其运行足够长的时间,以便能够在几秒钟或几十秒(更好)内测量结果
  • 尽管您不能在两次迭代之间调用System.gc(),但最好在测试之间运行它,以便每个测试都有望获得一个"干净的"内存空间以供处理。 (是的,gc()不仅仅是一个提示,而不是一个保证,但很有可能它确实会根据我的经验进行垃圾收集。)
  • 我喜欢显示迭代次数和时间,以及时间/迭代的分数,可以对分数进行缩放,以使"最佳"算法的分数为1.0,其他分数则以相对方式进行评分。这意味着您可以长时间运行 all 算法,同时改变迭代次数和时间,但仍可获得可比的结果。

我只是在博客中讨论.NET中的基准测试框架的设计。我有一个夫妇 之前的版本帖子,也许可以为您提供一些想法-当然,并非所有内容都合适,但其中某些内容可能是合适的。

回答4:

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

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

示例测试注释

另请参阅:

回答5:

基准测试应该测量时间/迭代次数还是迭代/时间,为什么?

这取决于您要测试的什么

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

回答6:

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

回答7:

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

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

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

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

回答8:

用Java编写微基准有许多可能的陷阱。

首先:您必须计算各种事件,这些事件或多或少地会花费时间:垃圾回收,缓存效果(文件用于OS,内存用于CPU),IO等。

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

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

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

回答9:

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

这是因为在大多数基准测试运行期间,实现A可能比实现B更快。但是A的传播范围也可能更高,因此与B相比,A的性能优势没有任何意义。 / p>

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

回答10:

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

回答11:

除了其他出色的建议,我还请注意以下几点:

对于某些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");
回到顶部