JMH：在看似均匀的设置中测试不均匀

Question

我在Math.max周围玩耍，看它是否受分支预测的影响（不，至少在x64的JDK上没有，有cmovl），如果按位实现可以与默认实现竞争。所有测试如下所示：

@Threads(4)
@State(Scope.Thread)
@BenchmarkMode({Mode.AverageTime, Mode.SampleTime})
@OutputTimeUnit(TimeUnit.MILLISECONDS)
public class CoreMaximum {
    private int[][] corpus;

    @Setup
    public void setUp() {
        corpus = Corpus.create();
    }

    @Benchmark
    public void constant(Blackhole blackhole) {
        val arguments = corpus[0];
        for (val payload : corpus) {
            blackhole.consume(arguments[0]);
            blackhole.consume(arguments[1]);
            blackhole.consume(payload[0]);
            blackhole.consume(payload[1]);
            blackhole.consume(Math.max(arguments[0], arguments[1]));
        }
    }

    @Benchmark
    public void random(Blackhole blackhole) {
        val payload = corpus[0];
        for (val arguments : corpus) {
            blackhole.consume(arguments[0]);
            blackhole.consume(arguments[1]);
            blackhole.consume(payload[0]);
            blackhole.consume(payload[1]);
            blackhole.consume(Math.max(arguments[0], arguments[1]));
        }
    }
}

其中Math.max可以用对另一个实现的调用替换，并且Corpus.create()返回由SecureRandom填充的int[1_000_000][2]。

问题是，即使我确定调用的代码不会受到分支预测的影响，并且尽管在constant和random基准测试中执行了均匀的负载和消耗量，但对于所有实现，基准测试仍然存在相似的差距：

CoreMaximum.constant                               avgt     25         13.080 ±        0.680  ms/op
CoreMaximum.constant:CPI                           avgt      5          0.528 ±        0.027   #/op
CoreMaximum.constant:L1-dcache-load-misses         avgt      5     478734.008 ±     2419.011   #/op
CoreMaximum.constant:L1-dcache-loads               avgt      5   49990187.380 ±   114908.845   #/op
CoreMaximum.constant:L1-dcache-stores              avgt      5   17998192.002 ±    42008.496   #/op
CoreMaximum.constant:L1-icache-load-misses         avgt      5       2142.398 ±      526.619   #/op
CoreMaximum.constant:LLC-load-misses               avgt      5      28553.636 ±     1338.175   #/op
CoreMaximum.constant:LLC-loads                     avgt      5      33148.939 ±      667.526   #/op
CoreMaximum.constant:LLC-store-misses              avgt      5        150.218 ±       26.488   #/op
CoreMaximum.constant:LLC-stores                    avgt      5        271.536 ±      113.444   #/op
CoreMaximum.constant:branch-misses                 avgt      5        187.060 ±      123.697   #/op
CoreMaximum.constant:branches                      avgt      5   17001028.964 ±    32923.938   #/op
CoreMaximum.constant:cycles                        avgt      5   57063715.464 ±  2900664.885   #/op
CoreMaximum.constant:dTLB-load-misses              avgt      5      13153.047 ±     1808.179   #/op
CoreMaximum.constant:dTLB-loads                    avgt      5   49999483.367 ±    94718.665   #/op
CoreMaximum.constant:dTLB-store-misses             avgt      5         36.217 ±        7.357   #/op
CoreMaximum.constant:dTLB-stores                   avgt      5   17999664.120 ±    23160.612   #/op
CoreMaximum.constant:iTLB-load-misses              avgt      5         32.138 ±        4.584   #/op
CoreMaximum.constant:iTLB-loads                    avgt      5         16.571 ±       20.613   #/op
CoreMaximum.constant:instructions                  avgt      5  107989860.816 ±   240202.175   #/op
CoreMaximum.random                                 avgt     25         14.082 ±        0.717  ms/op
CoreMaximum.random:CPI                             avgt      5          0.503 ±        0.037   #/op
CoreMaximum.random:L1-dcache-load-misses           avgt      5     479117.110 ±     2632.690   #/op
CoreMaximum.random:L1-dcache-loads                 avgt      5   56030755.475 ±   120501.598   #/op
CoreMaximum.random:L1-dcache-stores                avgt      5   24015559.169 ±    51480.836   #/op
CoreMaximum.random:L1-icache-load-misses           avgt      5       2473.731 ±      968.508   #/op
CoreMaximum.random:LLC-load-misses                 avgt      5      29106.351 ±     1251.508   #/op
CoreMaximum.random:LLC-loads                       avgt      5      34274.838 ±     1178.339   #/op
CoreMaximum.random:LLC-store-misses                avgt      5        156.975 ±       29.332   #/op
CoreMaximum.random:LLC-stores                      avgt      5        268.092 ±      128.106   #/op
CoreMaximum.random:branch-misses                   avgt      5        169.811 ±      102.783   #/op
CoreMaximum.random:branches                        avgt      5   18007736.925 ±    42002.060   #/op
CoreMaximum.random:cycles                          avgt      5   61431988.502 ±  4506086.004   #/op
CoreMaximum.random:dTLB-load-misses                avgt      5      13157.184 ±     1496.518   #/op
CoreMaximum.random:dTLB-loads                      avgt      5   56026614.485 ±   144375.149   #/op
CoreMaximum.random:dTLB-store-misses               avgt      5         37.321 ±        6.870   #/op
CoreMaximum.random:dTLB-stores                     avgt      5   24011292.571 ±    54348.034   #/op
CoreMaximum.random:iTLB-load-misses                avgt      5         38.059 ±       19.549   #/op
CoreMaximum.random:iTLB-loads                      avgt      5         18.290 ±       36.399   #/op
CoreMaximum.random:instructions                    avgt      5  122045528.539 ±   313318.615   #/op

（（我没有足够的经验来得出结论，但显然random基准具有比constant多的计数器，尤其是instructions和branches）]

Random总是需要更长的时间，并且有更多的指令，这显然表明基准测试并未说明问题，但我不知道这是怎么回事。除了线程计数（我不知道为什么，但它只使用一个而不是内核数）之外，我没有做任何其他调整，预热应该完成他们的工作（我看到C2在第一次预热时就已经编译了代码），和ASM的转储（在CompileCommandFile中使用打印）除了几次点按和特定指令的放置外，没有显着差异。我想念什么？

Answer 1

虽然对我来说仍然是完全个谜，但根本原因是什么（可能是ASM清单包含了答案，但是我没有足够的时间来深入研究所有问题），我认为我找到了问题所在。删除for循环即可完成工作：

@Threads(4)
@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class CoreMaximum {
    @Param({"true", "false"})
    public boolean constant;

    private int[][] corpus;

    @Setup
    public void setUp() {
        corpus = constant ? Corpus.constant() : Corpus.random();
    }

    @Benchmark
    public void run(Blackhole blackhole) {
        blackhole.consume(Math.max(corpus[0][0], corpus[0][1]));
        blackhole.consume(Math.max(corpus[1][0], corpus[1][1]));
        blackhole.consume(Math.max(corpus[2][0], corpus[2][1]));
        blackhole.consume(Math.max(corpus[3][0], corpus[3][1]));
        blackhole.consume(Math.max(corpus[4][0], corpus[4][1]));
        blackhole.consume(Math.max(corpus[5][0], corpus[5][1]));
        blackhole.consume(Math.max(corpus[6][0], corpus[6][1]));
        blackhole.consume(Math.max(corpus[7][0], corpus[7][1]));
        blackhole.consume(Math.max(corpus[8][0], corpus[8][1]));
        blackhole.consume(Math.max(corpus[9][0], corpus[9][1]));
        blackhole.consume(Math.max(corpus[10][0], corpus[10][1]));
        blackhole.consume(Math.max(corpus[11][0], corpus[11][1]));
        blackhole.consume(Math.max(corpus[12][0], corpus[12][1]));
        blackhole.consume(Math.max(corpus[13][0], corpus[13][1]));
        blackhole.consume(Math.max(corpus[14][0], corpus[14][1]));
        blackhole.consume(Math.max(corpus[15][0], corpus[15][1]));
        blackhole.consume(Math.max(corpus[16][0], corpus[16][1]));
        blackhole.consume(Math.max(corpus[17][0], corpus[17][1]));
        blackhole.consume(Math.max(corpus[18][0], corpus[18][1]));
        blackhole.consume(Math.max(corpus[19][0], corpus[19][1]));
        blackhole.consume(Math.max(corpus[20][0], corpus[20][1]));
        blackhole.consume(Math.max(corpus[21][0], corpus[21][1]));
        blackhole.consume(Math.max(corpus[22][0], corpus[22][1]));
        blackhole.consume(Math.max(corpus[23][0], corpus[23][1]));
        blackhole.consume(Math.max(corpus[24][0], corpus[24][1]));
        blackhole.consume(Math.max(corpus[25][0], corpus[25][1]));
        blackhole.consume(Math.max(corpus[26][0], corpus[26][1]));
        blackhole.consume(Math.max(corpus[27][0], corpus[27][1]));
        blackhole.consume(Math.max(corpus[28][0], corpus[28][1]));
        blackhole.consume(Math.max(corpus[29][0], corpus[29][1]));
        blackhole.consume(Math.max(corpus[30][0], corpus[30][1]));
        blackhole.consume(Math.max(corpus[31][0], corpus[31][1]));
    }
}

Benchmark                              (constant)  Mode  Cnt     Score    Error  Units
CoreMaximum.run                              true  avgt   25    92.235 ±  7.998  ns/op
CoreMaximum.run:CPI                          true  avgt    5     0.392 ±  0.049   #/op
CoreMaximum.run:instructions                 true  avgt    5  1000.988 ±  5.330   #/op
CoreMaximum.run                             false  avgt   25    92.556 ±  9.010  ns/op
CoreMaximum.run:CPI                         false  avgt    5     0.390 ±  0.074   #/op
CoreMaximum.run:instructions                false  avgt    5   999.559 ±  5.132   #/op

我正在手动展开循环，因为单发基准测试没有理由分支，而在基准测试中直接调用Random / SecureRandom可能会超过实际的实现调用，并且容易出错。老实说，面对这样的问题，删除实际的测试对象并检查结果应该是第一件事。

对于那些通过google最终出现在这里的人：当您发现测试中存在一些错误并且没有足够的时间进行深入挖掘时，您可以作弊。如果您确定基准测试的某个部分在撒谎，则可以尝试找出它的哪一部分，然后重写基准测试以摆脱它。但是要记住，a）获得想要看到的数字并不能证明任何事情，并且比实际确认假设要安慰您，b）如果您想做的事情[[正确，您必须找出根源原因，否则您的基准测试只是一个逃脱，（再次）可能隐藏了一个错误。我这次之所以作弊只是因为a）我不是在做我的工作，而是在做更多的工作，而不是追求一个特定的生产代码中的问题，没有足够的时间进行适当的调查，并且b）我确信结果是因为我已经看到所有实现的ASM清单，而我所追求的实际实现（库一）只是少数说明所有这些都排除了分支预测的可能性。 如果找到确切答案是您工作的一部分，请不要作弊，您将无法解决所寻找的问题。

JMH：在看似均匀的设置中测试不均匀

问题描述投票：0回答：1

1个回答

最新问题

JMH：在看似均匀的设置中测试不均匀

问题描述 投票：0回答：1

1个回答

最新问题

问题描述投票：0回答：1