2

我读过，为了避免在微基准测试中消除死代码，最常见的解决方案是：

  1. 返回计算结果
  2. 使用黑洞消耗结果。

我的问题是：

是否可以通过将计算结果放在公共变量中来避免死代码消除？

编辑：

感谢 Shipilev 的回答，我意识到返回结果或使用黑洞使用它们必须正确完成，以避免死代码消除 (DCE)，如 JMH 示例中所述。

因此，我将重写我的问题以使其更清楚：

在返回计算结果或与 blackholes 一起使用足以避免 DCE 的情况下，是否也足以将结果放入公共变量中？

我已经运行了示例JMHSample_08_DeadCode的变体，如下所示：

public double sink;

@Benchmark
public void measureRightPerhaps_2() {
    // What could possibly go wrong?
    sink = Math.log(x);
}

从结果看来是这样：

Benchmark              Mode  Cnt   Score   Error  Units
baseline               avgt   15   0,458 � 0,001  ns/op
measureRight           avgt   15  33,233 � 0,268  ns/op
measureRightPerhaps_2  avgt   15  30,177 � 0,603  ns/op
measureWrong           avgt   15   0,459 � 0,001  ns/op
measureWrong_2         avgt   15   0,917 � 0,001  ns/op
4

1 回答 1

2

这很容易回答：不，这不安全，除非您正在控制环境，验证没有发生不良影响等。最简单的情况是优化器发现该字段有几个连续的存储，并消除除最新商店以外的所有内容。例如，采用众所周知的JMHSample_08_DeadCode，并添加以下测试：

public double sink;

@Benchmark
public void measureWrong_2() {
    // What could possibly go wrong?
    sink = Math.log(x);

    // Imagine this happens somewhere downstream.
    // Or, you are sinking in the loop.
    // Or, measureWrong_2 had inlined and the very next Math.log will sink.
    sink = Math.PI;
}

...然后运行它，然后哭泣：

Benchmark                             Mode  Cnt   Score   Error  Units
JMHSample_08_DeadCode.baseline        avgt    5   0.251 ± 0.001  ns/op
JMHSample_08_DeadCode.measureRight    avgt    5  19.034 ± 0.033  ns/op
JMHSample_08_DeadCode.measureWrong    avgt    5   0.251 ± 0.001  ns/op
JMHSample_08_DeadCode.measureWrong_2  avgt    5   0.326 ± 0.001  ns/op

士气：除非您知道自己在做什么，否则不要脱离 JMH 文档提到的避免 DCE 的受支持方式。

更新：当然，当其他技术起作用时，您可以找到一个极端情况。但是，即使目前某些东西正在起作用，您也不能确定它是否会与其他一些无害的变化一起起作用。这就是使用 Blackholes 的全部意义——它们一直在工作。例如更复杂的案例JMHSample_09_Blackholes，您可以在其中“意外”在以下位置创建两个背靠背商店sink：

@Benchmark
public void measureRight_2(Blackhole bh) {
    bh.consume(Math.log(x1));
    bh.consume(Math.log(x2));
}

public double sink;

@Benchmark
public void measureWrong_2() {
    sink = Math.log(x1);
    sink = Math.log(x2);
}

...和：

JMHSample_09_Blackholes.measureRight_1  avgt    5  35.837 ± 0.043  ns/op
JMHSample_09_Blackholes.measureRight_2  avgt    5  38.378 ± 0.071  ns/op
JMHSample_09_Blackholes.measureWrong    avgt    5  19.012 ± 0.009  ns/op
JMHSample_09_Blackholes.measureWrong_2  avgt    5  16.659 ± 0.018  ns/op

哎呀。黑洞正在工作，而汇没有：这是您更新问题的反例。除非您使用该技巧验证每个基准测试，并按预期仔细检查您正在使用该技巧的代码，否则您无法确定该技巧是否有效。我的观点是，您最好花时间找出特定于您的基准测试的问题（占所有基准测试错误的 99%），而不是试图在几纳秒的时间内作弊。优先事项！

现在维护者的观点。JMH 开发跟踪在更新的 JVM 中所做的事情，随着它们的发展。黑洞在此过程中得到修复。JMH 基准存根的代码形状正在得到纠正。但是，它们在使用广告保证的有效基准上得到验证。我们没有理由关心自己做某事的基准。例如，如果编译器能够内联@Benchmark、展开 JMH 正在执行的外部循环，那么它将sink为上面发现的问题做好准备。换句话说，如果您希望代码具有面向未来的能力，请使用已知和记录在案的 API，而不是一些技巧。

于 2015-10-02T10:08:37.380 回答