编辑:maaartinus 给出了我一直在寻找的答案，并且 tmyklebu 关于该问题的数据有很大帮助，所以感谢两位! :)

我读过一些关于 HotSpot 如何在代码中注入(inject)一些“内在函数”的文章，特别是对于 Java 标准数学库 (from here)

所以我决定试一试，看看 HotSpot 与直接进行比较相比有何不同(特别是因为我听说 min/max 可以编译为无分支 asm)。

public class OpsMath {
    public static final int max(final int a, final int b) {
        if (a > b) {
            return a;
        }
        return b;
    }
}

这是我的实现。从另一个 SO question 我读到使用三元运算符使用额外的寄存器，我没有发现执行 if block 和使用三元运算符(即 return ( a > b ) ? a : b )之间的显着差异。

分配一个 8Mb 的 int 数组(即 200 万个值)，并将其随机化，我做了以下测试:

try ( final Benchmark bench = new Benchmark( "millis to max" ) )
    {
        int max = Integer.MIN_VALUE;

        for ( int i = 0; i < array.length; ++i )
        {
            max = OpsMath.max( max, array[i] );
            // max = Math.max( max, array[i] );
        }
    }

我在 try-with-resources block 中使用 Benchmark 对象。当它完成时，它在对象上调用 close() 并打印 block 完成的时间。测试是通过在上面的代码中注释入/出最大调用来单独完成的。

'max' 被添加到基准 block 之外的列表中并稍后打印，以避免 JVM 优化整个 block 。

每次测试运行时数组都是随机的。

运行 6 次测试，结果如下:

Java 标准数学:

millis to max 9.242167 
millis to max 2.1566199999999998
millis to max 2.046396 
millis to max 2.048616  
millis to max 2.035761
millis to max 2.001044 

第一次运行后相当稳定，再次运行测试会得到类似的结果。

运维数学:

millis to max 8.65418 
millis to max 1.161559  
millis to max 0.955851 
millis to max 0.946642 
millis to max 0.994543 
millis to max 0.9469069999999999 

再次，第一次运行后的结果非常稳定。

问题是:为什么？这有很大的不同。我不知道为什么。即使我像 Math.max() 一样完全实现我的 max() 方法(即 return (a >= b) ? a : b )我仍然会得到更好的结果!没有意义。

规范:

CPU:英特尔 i5 2500, 3,3Ghz。 Java 版本:JDK 8(3 月 18 日公开发布)，x64。 Debian Jessie(测试版)x64。

我还没有尝试使用 32 位 JVM。

编辑:按要求进行独立测试。添加了一行以强制 JVM 预加载 Math 和 OpsMath 类。这消除了 OpsMath 测试第一次迭代的 18 毫秒成本。

// Constant nano to millis.
final double TO_MILLIS = 1.0d / 1000000.0d;
// 8Mb alloc.
final int[] array = new int[(8*1024*1024)/4];
// Result and time array.
final ArrayList<Integer> results = new ArrayList<>();
final ArrayList<Double> times = new ArrayList<>();
// Number of tests.
final int itcount = 6;
// Call both Math and OpsMath method so JVM initializes the classes.
System.out.println("initialize classes " + 
OpsMath.max( Math.max( 20.0f, array.length ), array.length / 2.0f ));
    
final Random r = new Random();
for ( int it = 0; it < itcount; ++it )
{
    int max = Integer.MIN_VALUE;
    
    // Randomize the array.
    for ( int i = 0; i < array.length; ++i )
    {
        array[i] = r.nextInt();
    }
    
    final long start = System.nanoTime();
    for ( int i = 0; i < array.length; ++i )
    {
        max = Math.max( array[i], max );
            // OpsMath.max() method implemented as described.
        // max = OpsMath.max( array[i], max );
    }
    // Calc time.
    final double end = (System.nanoTime() - start);
    // Store results.
    times.add( Double.valueOf( end ) );
    results.add( Integer.valueOf(  max ) );
}
// Print everything.
for ( int i = 0; i < itcount; ++i )
{
    System.out.println( "IT" + i + " result: " + results.get( i ) );
    System.out.println( "IT" + i + " millis: " + times.get( i ) * TO_MILLIS );
}

Java Math.max 结果:

IT0 result: 2147477409
IT0 millis: 9.636998
IT1 result: 2147483098
IT1 millis: 1.901314
IT2 result: 2147482877
IT2 millis: 2.095551
IT3 result: 2147483286
IT3 millis: 1.9232859999999998
IT4 result: 2147482828
IT4 millis: 1.9455179999999999
IT5 result: 2147482475
IT5 millis: 1.882047

OpsMath.max 结果:

IT0 result: 2147482689
IT0 millis: 9.003616
IT1 result: 2147483480
IT1 millis: 0.882421
IT2 result: 2147483186
IT2 millis: 1.079143
IT3 result: 2147478560
IT3 millis: 0.8861169999999999
IT4 result: 2147477851
IT4 millis: 0.916383
IT5 result: 2147481983
IT5 millis: 0.873984

总体结果仍然相同。我尝试只对数组进行一次随机化，并在同一个数组上重复测试，总体上我得到了更快的结果，但 Java Math.max 和 OpsMath.max 之间的差异相同 2 倍。

最佳答案

很难说为什么 Math.max 比 Ops.max 慢，但很容易解释为什么这个基准测试强烈支持分支到条件移动:在n-第一次迭代，概率

Math.max( array[i], max );

不等于max 是array[n-1] 大于所有先前元素的概率。显然，这个概率随着 n 和给定

final int[] array = new int[(8*1024*1024)/4];

大部分时间都可以忽略不计。条件移动指令对分支概率不​​敏感，它总是花费相同的时间来执行。条件移动指令比分支预测更快如果分支很难预测。另一方面，如果可以以高概率很好地预测分支，则分支预测会更快。目前，与分支的最佳和最坏情况相比，我不确定条件移动的速度。¹

在您的情况下，除了前几个分支之外的所有分支都是相当可预测的。从大约 n == 10 开始，使用条件移动毫无意义，因为可以保证正确预测分支并且可以与其他指令并行执行(我猜你每次迭代都需要一个周期)。

这似乎发生在计算最小值/最大值或进行一些低效排序的算法(良好的分支可预测性意味着每步的熵低)。

¹ 条件移动和预测分支都需要一个周期。前者的问题在于它需要两个操作数，这需要额外的指令。最后，当分支单元空闲时，关键路径可能会变得更长和/或 ALU 饱和。通常，但并非总是如此，在实际应用中可以很好地预测分支；这就是最初发明分支预测的原因。

关于时间条件移动与分支预测最佳和最坏情况的详细信息，请参阅下面的评论中的讨论。我的 my own benchmark表明当分支预测遇到最坏情况时，条件移动明显快于分支预测，但我不能忽略 contradictory results .我们需要一些解释究竟是什么造成了差异。更多的基准和/或分析可能会有所帮助。

关于Java Math.min/max 性能，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/22752198/