Question

自CPU开始以来，一般都知道整数除法指令很昂贵。我去看看今天有多糟糕，在拥有数十亿晶体管的CPU上。我发现硬件idiv指令对于常量除数的性能仍然比JIT编译器能够发出的代码差得多，而且不包含idiv指令。

为了在专用的微基准测试中实现这一点，我写了以下内容：

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@OperationsPerInvocation(MeasureDiv.ARRAY_SIZE)
@Warmup(iterations = 8, time = 500, timeUnit = TimeUnit.MILLISECONDS)
@Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@State(Scope.Thread)
@Fork(1)
public class MeasureDiv
{
  public static final int ARRAY_SIZE = 128;
  public static final long DIVIDEND_BASE = 239520948509234807L;
  static final int DIVISOR = 10;
  final long[] input = new long[ARRAY_SIZE];

  @Setup(Level.Iteration) public void setup() {
    for (int i = 0; i < input.length; i++) {
      input[i] = DIVISOR;
    }
  }

  @Benchmark public long divVar() {
    long sum = 0;
    for (int i = 0; i < ARRAY_SIZE; i++) {
      final long in = input[i];
      final long dividend = DIVIDEND_BASE + i;
      final long divisor = in;
      final long quotient = dividend / divisor;
      sum += quotient;
    }
    return sum;
  }

  @Benchmark public long divConst() {
    long sum = 0;
    for (int i = 0; i < ARRAY_SIZE; i++) {
      final long in = input[i];
      final long dividend = DIVIDEND_BASE + in;
      final int divisor = DIVISOR;
      final long quotient = dividend / divisor;
      sum += quotient;
    }
    return sum;
  }
}

简而言之，除了一个（divVar）通过读取数组的数字执行除法而另一个除以编译时常量之外，我在每个方面都有两个相同的方法。结果如下：

Benchmark            Mode  Cnt  Score   Error  Units
MeasureDiv.divConst  avgt    5  1.228 ± 0.032  ns/op
MeasureDiv.divVar    avgt    5  8.913 ± 0.192  ns/op

性能比非常出色。我的期望是，现代英特尔处理器有足够的空间，而且它的工程师有足够的兴趣，在硬件中实现复杂但高性能的划分算法。然而，JIT编译器通过向其发送一些执行相同工作的其他指令流来击败英特尔，仅快七倍。如果有的话，专用微码应该能够比JIT通过汇编指令的公共API更好地利用CPU。

为什么idiv仍然慢得多，基本限制是什么？

我想到的一个解释是假设存在一种除法算法，该算法首次将红利放入过程中。然后，JIT编译器将有一个良好的开端，因为它将评估第一部分，它在编译时仅涉及除数，并仅将算法的第二部分作为运行时代码发出。这个假设是真的吗？

Answer 1

正如用户 pvg 通过评论所解释的那样，假设算法确实存在并且是当前已知的最佳算法。该算法涉及在预备步骤中由相同的除数进行除法，因此从根本上说它在整体上是不可简化的。它载于经典出版物Hacker's Delight的第10章。

CPU的div指令和HotSpot的JIT代码

1 个答案: