首页 文章

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

提问于
浏览 次
752

你如何在Java中编写（并运行）正确的微基准测试？

我在这里寻找代码示例和注释，说明要考虑的各种事项 .

示例：基准测试应该测量时间/迭代或迭代/时间，为什么？

相关：Is stopwatch benchmarking acceptable?

java jvm benchmarking jvm-hotspot microbenchmark

11 回答

  • 697

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

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

    Rule 1: 始终包含一个预热阶段，它一直运行测试内核，足以在定时阶段之前触发所有初始化和编译 . （在预热阶段，迭代次数较少 . 经验法则是数万次内循环迭代 . ）

    Rule 2: 始终使用 -XX:+PrintCompilation ， -verbose:gc 等运行，这样您就可以验证编译器和JVM的其他部分在计时阶段没有意外工作 .

    Rule 2.1: 在计时和预热阶段的开始和结束时打印消息，因此您可以在计时阶段验证规则2中没有输出 .

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

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

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

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

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

    Rule 8: 使用库作为基准测试，因为它可能更有效，并且已经针对此唯一目的进行了调试 . 如JMH，Caliper或Bill and Paul's Excellent UCSD Benchmarks for Java .

    回复于
  • 218

    基准测量应该测量时间/迭代或迭代/时间，为什么？

    这取决于你要测试的内容 . 如果您对延迟感兴趣，请使用时间/迭代，如果您对吞吐量使用迭代/时间感兴趣 .

    回复于
  • 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秒左右 . 迭代次数越多，基准时间内的数字越重要，数据越可靠 .

    回复于
  • 12

    我知道这个问题已被标记为已回答，但我想提及两个使我们能够编写微基准的库

    Caliper from Google

    入门教程

    JMH from OpenJDK

    入门教程

    回复于
  • 12

    Java基准测试的重要事项是：

    • 首先通过运行代码多次预热JIT，然后再计时

    • 确保运行它足够长的时间，以便能够在几秒或更好（几十秒）内测量结果

    • 虽然你不能在迭代之间调用 System.gc() ，但在测试之间运行它是个好主意，这样每个测试都可以获得一个"clean"内存空间 . （是的， gc() 更像是一种暗示，而不是保证，但根据我的经验，它很可能真的会被垃圾收集 . ）

    • 我喜欢显示迭代和时间，以及可以缩放的时间/迭代分数，使得"best"算法得分为1.0而其他算法以相对方式得分 . 这意味着您可以长时间运行所有算法，同时改变迭代次数和时间，但仍然可以获得可比较的结果 .

    我'm just in the process of blogging about the design of a benchmarking framework in .NET. I'得到couple的earlier posts可能能给你一些想法 - 当然，并非一切都是合适的，但有些可能是 .

    回复于
  • 77

    为了增加其他优秀的建议，我还要注意以下几点：

    对于某些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");
    回复于
  • 14

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

    第一：你必须用各种各样的事件来计算，这些事件或多或少是随机的：垃圾收集，缓存效果（文件操作系统和内存CPU），IO等 .

    第二：在非常短的时间间隔内，您不能相信测量时间的准确性 .

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

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

    回复于
  • 6

    还应该注意，在比较不同的实现时，分析微基准的结果可能也很重要 . 因此应该制作一个significance test .

    这是因为实施 A 在基准测试的大多数运行期间可能比实现 B 更快 . 但是 A 也可能具有更高的价差，因此与 B 相比， A 的测量性能优势没有任何意义 .

    因此，正确编写和运行微基准测试也很重要，同时也要正确分析它 .

    回复于
  • 17

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

    回复于
  • 5

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

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

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

    也可以看看：

    回复于
  • 42

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

    回复于

相关问题