这个JMH基准测试在不同的机器上结果不一致 - 为什么?

8

我正在尝试编写类似于以下的方法:

static boolean fitsInDouble(long x) {
  // return true if x can be represented
  // as a numerically-equivalent double
}

我正在尝试找到最有效的实现方式。我已经选择了一种方法,但是我的同事运行基准测试后得到了不同的相对结果。对于我来说最快的实现方式并不是他最快的。

这些基准测试是否存在问题?

package rnd;

import org.openjdk.jmh.annotations.Benchmark;
import org.openjdk.jmh.annotations.BenchmarkMode;
import org.openjdk.jmh.annotations.Fork;
import org.openjdk.jmh.annotations.Measurement;
import org.openjdk.jmh.annotations.Mode;
import org.openjdk.jmh.annotations.OutputTimeUnit;
import org.openjdk.jmh.annotations.Scope;
import org.openjdk.jmh.annotations.State;
import org.openjdk.jmh.annotations.Warmup;
import org.openjdk.jmh.infra.Blackhole;
import org.openjdk.jmh.runner.Runner;
import org.openjdk.jmh.runner.options.Options;
import org.openjdk.jmh.runner.options.OptionsBuilder;

import java.math.BigDecimal;
import java.util.concurrent.TimeUnit;

@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Fork(1)
@Measurement(iterations = 5)
@Warmup(iterations = 5)
public class Benchmarks {

  public static void main(String[] args) throws Exception {
    Options options = new OptionsBuilder()
        .include(Benchmarks.class.getName())
        .build();
    new Runner(options).run();
  }

  @Benchmark
  public void bigDecimal(Blackhole bh) {
    for (long x : NUMBERS) bh.consume(bigDecimal(x));
  }

  @Benchmark
  public void cast(Blackhole bh) {
    for (long x : NUMBERS) bh.consume(cast(x));
  }

  @Benchmark
  public void zeros(Blackhole bh) {
    for (long x : NUMBERS) bh.consume(zeros(x));
  }

  public static boolean bigDecimal(long x) {
    BigDecimal a = new BigDecimal(x);
    BigDecimal b = new BigDecimal((double) x);
    return a.compareTo(b) == 0;
  }

  public static boolean cast(long x) {
    return x == (long) (double) x
        && x != Long.MAX_VALUE;
  }

  public static boolean zeros(long x) {
    long a = Math.abs(x);
    int z = Long.numberOfLeadingZeros(a);
    return z > 10 || Long.numberOfTrailingZeros(a) > 10 - z;
  }

  private static final long[] NUMBERS = {
      0,
      1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
      -1, -2, -3, -4, -5, -6, -7, -8, -9, -10,
      123, 456, 789,
      -123, -456, -789,
      101112, 131415, 161718,
      -101112, -131415, -161718,
      11L,
      222L,
      3333L,
      44444L,
      555555L,
      6666666L,
      77777777L,
      888888888L,
      9999999999L,
      1111L,
      22222L,
      333333L,
      4444444L,
      55555555L,
      666666666L,
      7777777777L,
      88888888888L,
      999999999999L,
      11111111,
      222222222,
      3333333333L,
      44444444444L,
      555555555555L,
      6666666666666L,
      77777777777777L,
      888888888888888L,
      9999999999999999L,
      Long.MAX_VALUE,
      Long.MAX_VALUE - 1,
      Long.MIN_VALUE,
      Long.MIN_VALUE + 1,
      (1L << 53),
      (1l << 53) + 1,
      (1l << 53) + 2,
      (1l << 60),
      (1l << 60) + 1,
      (1l << 60) + 8,
      (1l << 60) + 32,
      (1l << 60) + 64,
      (1l << 60) + 128,
      (1l << 60) + 256,
      (-1L << 53),
      (-1L << 53) - 1,
      (-1L << 53) - 2,
      (-1l << 60),
      (-1l << 60) - 1,
      (-1l << 60) - 8,
      (-1l << 60) - 32,
      (-1l << 60) - 64,
      (-1l << 60) - 128,
      (-1l << 60) - 256
  };
}

我们的环境存在一些小差异:
我使用Windows 10操作系统,JDK版本为1.8.0_45,其中"zeros"是最快的。
他使用Windows 7操作系统,JDK版本为1.8.0_20,其中"cast"是最快的。
无论是在IDE中运行还是从命令行中运行,我们的结果在每次运行时都是自洽的。我们使用的是JMH 1.10.5。
这里发生了什么?性能基准似乎不可信,我不知道如何解决它。

6
我不足以评判基准测试的质量,但对于你的问题,有一个非常简单的答案:结果不同是因为环境不同:JVM不同、操作系统不同,可能硬件也不同。这就是导致结果不同的三个很好的理由。 - JB Nizet
@JBNizet 如果最终结果是由于JDK小版本、Windows版本或处理器特定的问题引起的,那将令人沮丧,但至少我会有一个答案。我想知道确切的原因。最终目标是将此方法放入库中。如果结果取决于环境中的某些因素,我希望了解哪个更有可能快速。现在对我来说看起来像是抛硬币。我希望自己在基准测试代码中犯了一个愚蠢的错误。 - Michael Hixson
@TagirValeev 谢谢,我会尽量在下周二大家都上班的时候提供完整的日志。希望我能说服其他同事加入进来。在我的机器上,“zeros”始终比“cast”快20%。如果我是异类,我可能会把“cast”放到库里,因为它更容易理解。 - Michael Hixson
你不应该基于微小的差异做出决策。你只需要让机器、操作系统、JVM、CPU温度、程序在内存中加载的位置或者其他代码运行情况有所不同,就可以改变结果。当存在微小差异时,你应该考虑其他因素,比如代码的简洁程度和清晰度。 - Peter Lawrey
顺便说一下,如果您启用了超线程,同一CPU上的另一个线程执行的操作可能会改变结果。 - Peter Lawrey
显示剩余2条评论
3个回答

7

即使在相同的机器和环境下,我也能够复现不同的结果:有时cast稍微快一些,有时zeros更快。

# JMH 1.10.5 (released 9 days ago)
# VM invoker: C:\Program Files\Java\jdk1.8.0_40\jre\bin\java.exe
# VM options: -Didea.launcher.port=7540 -Didea.launcher.bin.path=C:\Program Files (x86)\IDEA 14.1.3\bin -Dfile.encoding=UTF-8
# Warmup: 3 iterations, 1 s each
# Measurement: 5 iterations, 1 s each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: bench.LongDouble.cast

# Run progress: 0,00% complete, ETA 00:01:20
# Fork: 1 of 5
# Warmup Iteration   1: 513,793 ns/op
# Warmup Iteration   2: 416,508 ns/op
# Warmup Iteration   3: 402,110 ns/op
Iteration   1: 402,535 ns/op
Iteration   2: 403,999 ns/op
Iteration   3: 404,871 ns/op
Iteration   4: 404,845 ns/op
Iteration   5: 401,705 ns/op

# Run progress: 10,00% complete, ETA 00:01:16
# Fork: 2 of 5
# Warmup Iteration   1: 421,552 ns/op
# Warmup Iteration   2: 418,925 ns/op
# Warmup Iteration   3: 421,813 ns/op
Iteration   1: 420,978 ns/op
Iteration   2: 422,940 ns/op
Iteration   3: 422,009 ns/op
Iteration   4: 423,011 ns/op
Iteration   5: 422,406 ns/op

# Run progress: 20,00% complete, ETA 00:01:07
# Fork: 3 of 5
# Warmup Iteration   1: 414,057 ns/op
# Warmup Iteration   2: 410,364 ns/op
# Warmup Iteration   3: 402,330 ns/op
Iteration   1: 402,776 ns/op
Iteration   2: 404,764 ns/op
Iteration   3: 400,346 ns/op
Iteration   4: 403,227 ns/op
Iteration   5: 403,350 ns/op

# Run progress: 30,00% complete, ETA 00:00:58
# Fork: 4 of 5
# Warmup Iteration   1: 422,161 ns/op
# Warmup Iteration   2: 419,118 ns/op
# Warmup Iteration   3: 402,990 ns/op
Iteration   1: 401,592 ns/op
Iteration   2: 402,999 ns/op
Iteration   3: 403,035 ns/op
Iteration   4: 402,625 ns/op
Iteration   5: 403,396 ns/op

# Run progress: 40,00% complete, ETA 00:00:50
# Fork: 5 of 5
# Warmup Iteration   1: 422,621 ns/op
# Warmup Iteration   2: 419,596 ns/op
# Warmup Iteration   3: 403,047 ns/op
Iteration   1: 403,438 ns/op
Iteration   2: 405,066 ns/op
Iteration   3: 403,271 ns/op
Iteration   4: 403,021 ns/op
Iteration   5: 402,162 ns/op


Result "cast":
  406,975 ?(99.9%) 5,906 ns/op [Average]
  (min, avg, max) = (400,346, 406,975, 423,011), stdev = 7,884
  CI (99.9%): [401,069, 412,881] (assumes normal distribution)


# JMH 1.9.3 (released 114 days ago, please consider updating!)
# VM invoker: C:\Program Files\Java\jdk1.8.0_40\jre\bin\java.exe
# VM options: -Didea.launcher.port=7540 -Didea.launcher.bin.path=C:\Program Files (x86)\IDEA 14.1.3\bin -Dfile.encoding=UTF-8
# Warmup: 3 iterations, 1 s each
# Measurement: 5 iterations, 1 s each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: bench.LongDouble.zeros

# Run progress: 50,00% complete, ETA 00:00:41
# Fork: 1 of 5
# Warmup Iteration   1: 439,529 ns/op
# Warmup Iteration   2: 437,752 ns/op
# Warmup Iteration   3: 390,530 ns/op
Iteration   1: 389,394 ns/op
Iteration   2: 391,453 ns/op
Iteration   3: 390,446 ns/op
Iteration   4: 390,822 ns/op
Iteration   5: 389,850 ns/op

# Run progress: 60,00% complete, ETA 00:00:33
# Fork: 2 of 5
# Warmup Iteration   1: 438,252 ns/op
# Warmup Iteration   2: 437,446 ns/op
# Warmup Iteration   3: 448,328 ns/op
Iteration   1: 389,979 ns/op
Iteration   2: 392,741 ns/op
Iteration   3: 390,575 ns/op
Iteration   4: 390,492 ns/op
Iteration   5: 390,000 ns/op

# Run progress: 70,00% complete, ETA 00:00:25
# Fork: 3 of 5
# Warmup Iteration   1: 447,939 ns/op
# Warmup Iteration   2: 444,489 ns/op
# Warmup Iteration   3: 414,433 ns/op
Iteration   1: 417,409 ns/op
Iteration   2: 413,518 ns/op
Iteration   3: 413,388 ns/op
Iteration   4: 414,040 ns/op
Iteration   5: 415,935 ns/op

# Run progress: 80,00% complete, ETA 00:00:16
# Fork: 4 of 5
# Warmup Iteration   1: 439,012 ns/op
# Warmup Iteration   2: 437,345 ns/op
# Warmup Iteration   3: 388,208 ns/op
Iteration   1: 395,647 ns/op
Iteration   2: 389,221 ns/op
Iteration   3: 387,539 ns/op
Iteration   4: 388,524 ns/op
Iteration   5: 387,623 ns/op

# Run progress: 90,00% complete, ETA 00:00:08
# Fork: 5 of 5
# Warmup Iteration   1: 446,116 ns/op
# Warmup Iteration   2: 446,622 ns/op
# Warmup Iteration   3: 409,116 ns/op
Iteration   1: 409,761 ns/op
Iteration   2: 410,146 ns/op
Iteration   3: 410,060 ns/op
Iteration   4: 409,370 ns/op
Iteration   5: 411,114 ns/op


Result "zeros":
  399,162 ?(99.9%) 8,487 ns/op [Average]
  (min, avg, max) = (387,539, 399,162, 417,409), stdev = 11,330
  CI (99.9%): [390,675, 407,649] (assumes normal distribution)


# Run complete. Total time: 00:01:23

Benchmark         Mode  Cnt    Score   Error  Units
LongDouble.cast   avgt   25  406,975 ± 5,906  ns/op
LongDouble.zeros  avgt   25  399,162 ± 8,487  ns/op

经过一些分析,我发现问题不在基准测试中,而是在JMH中。 perfasm 分析器指向了 Blackhole.consume 方法:

public final void consume(boolean bool) {
    boolean bool1 = this.bool1; // volatile read
    boolean bool2 = this.bool2;
    if (bool == bool1 & bool == bool2) {
        // SHOULD NEVER HAPPEN
        nullBait.bool1 = bool; // implicit null pointer exception
    }
}

有趣的部分在于如何初始化bool1bool2

Random r = new Random(System.nanoTime());
...
bool1 = r.nextBoolean(); bool2 = !bool1;

是的,它们每次都是随机的!正如您所知,JIT编译器依赖于运行时执行配置文件,因此生成的代码会根据bool1bool2的初始值略有不同,特别是在一半的情况下,它认为分支被采取,在其余的一半情况下则未被采取。这就是差异的来源。
我已经提交了报告,并建议修复该缺陷,以防作者确认此问题。

4
这就是为什么通常不能依靠单个分支的原因之一:这会忽略整个一组跑到跑的差异问题,这些差异不仅由基准测试、基准测试工具引起,也由运行时环境、操作系统和硬件引起。默认的 JMH 设置使用 10 个分支;如果像 OP 一样将其调整为 1 个分支,则必须面对后果。 - Aleksey Shipilev
哦,太棒了!当我使用多个forks(糟糕),我确实看到了运行到运行的差异。“cast”在290ns和270ns之间切换,“zeros”在250ns和240ns之间切换。所以我认为仍然存在这样一个问题:“哪个更快?”取决于……某些我不理解的特定环境因素。但是你在这里的发现可能比我的原始问题的答案更有趣/有用。 - Michael Hixson
1
@MichaelHixson,这个特定的 bug 在 JMH 中已经修复了。你尝试使用更新版本来重现结果了吗? - Tagir Valeev
@TagirValeev 它修复了运行到运行的差异。它不会改变机器之间的差异,这是我最初问题的主题。可悲的是,我认为我无法让我的同事花更多时间在这上面,这意味着我将无法提供日志或其他输出进行比较。因此,我认为我的问题永远不会得到真正的答案。至少有些好东西出现了(这个答案和错误修复)。你认为我应该标记它为已接受吗? - Michael Hixson
@MichaelHixson,这取决于你。但是,如果问题实际上没有得到解决,我不会接受答案。 - Tagir Valeev

2

正如JB Nizet所指出的那样,您不能假设程序在多个JVM和/或操作系统上执行的效果相同,尤其是如果您使用不同的机器。

顺便说一下,您不需要numberOfLeadingZeroes(a)

public static boolean zeroes2(final long x) {
    final long a = Math.abs(x);
    return (a >>> Long.numberOfTrailingZeros(a)) < (1L << 53);
}

最后,如果你真的需要最高性能,要么选择一组随机样本机进行测试,并选择表现最佳的那一台(除非有某些机器的表现明显更差,但考虑到你的代码示例,这种情况相当不太可能);要么添加所有方法并创建一个校准程序,对所有版本进行基准测试,并选择在运行该程序的机器上运行最快的版本。
编辑:正如Javier所说,确保使用多个类似于真实世界工作负载的基准测试。

2
CPU型号会随着时间的推移而演变。如果操作性能平衡发生变化,或者有一些新的分支预测改进,则会出现一致性差异。
如果您想要舍弃一个备选项在特定数据集上具有虚假优势(例如能够猜测下一个案例,在实际情况下可能无法做到),则可以随机/洗牌您的数据集并使其变得更长。只是想试试,虽然这可能是徒劳的(如果您需要执行完全相同的数据,这也是可疑的)。
final int times = 10;
List<Long> listShuffle = new ArrayList<>(NUMBERS.length * times);
for (long l : NUMBERS) {
    for (int i = 0; i < times; i++) {
        listShuffle.add(l);
    }
}

// Shake and serve chilled
Collections.shuffle(listShuffle);

P.D.#1 此外,如果您能提供真实数据样本而非合成数据,则可能会提供更有意义的信息。在这种情况下,CPU 猜测过多实际上可能是有益的。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接