关于算法：Java中的“快速”整数幂

“Fast” Integer Powers in Java

简短的回答：糟糕的标杆管理方法。你以为我现在已经明白了。

问题是"找到一个快速计算X ^ y的方法，其中X和Y是正整数"。典型的"快速"算法如下：

1
2
3
4
5
6
7
8
9
10
11
12
13

public long fastPower(int x, int y) {
// Replaced my code with the"better" version described below,
// but this version isn't measurably faster than what I had before
long base = x; // otherwise, we may overflow at x *= x.
long result = y % 2 == 1 ? x : 1;
while (y > 1) {
base *= base;
y >>= 1;
if (y % 2 == 1) result *= base;
}

return result;
}

我想看看这比调用math.pow()或使用简单的方法(比如x乘以y)快多少，比如：

1
2
3
4
5
6
7

public long naivePower(int x, int y) {
long result = 1;
for (int i = 0; i < y; i++) {
result *= x;
}
return result;
}

编辑：好吧，有人向我指出(正确地)我的基准代码没有消耗结果，这完全把一切都抛到一边。一旦我开始使用这个结果，我仍然看到幼稚的方法比"快速"方法快25%。

原文：

I was very surprised to find that the naive approach was 4x faster than the"fast" version, which was itself about 3x faster than the Math.pow() version.

我的测试是使用10000000个测试(然后是1亿个，只是为了确保JIT有时间预热)，每个测试都使用随机值(防止调用被优化掉)，2<=x<=3，25<=y<=29。我选择了一个很窄的值范围，它不会产生大于2^63的结果，但会偏向于较大的指数，以试图给"快速"版本带来优势。我正在预先生成10000个伪随机数，以从计时中消除这部分代码。

我理解，对于小指数来说，幼稚的版本可能更快。"fast"版本有两个分支，而不是一个分支，通常执行的算术/存储操作是原始分支的两倍，但我预计对于大指数，这仍然会导致fast方法在最佳情况下节省一半的操作，在最坏情况下几乎相同。

有人知道为什么天真的方法会比"快速"版本快得多，即使数据偏向于"快速"版本(即更大的指数)？在运行时，代码中额外的分支是否解释了这么大的差异？

基准代码(是的，我知道我应该为"官方"基准使用一些框架，但这是一个玩具问题)-更新为预热，并使用结果：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

PowerIf[] powers = new PowerIf[] {
new EasyPower(), // just calls Math.pow() and cast to int
new NaivePower(),
new FastPower()
};

Random rand = new Random(0); // same seed for each run
int randCount = 10000;
int[] bases = new int[randCount];
int[] exponents = new int[randCount];
for (int i = 0; i < randCount; i++) {
bases[i] = 2 + rand.nextInt(2);
exponents[i] = 25 + rand.nextInt(5);
}

int count = 1000000000;

for (int trial = 0; trial < powers.length; trial++) {
long total = 0;
for (int i = 0; i < count; i++) { // warm up
final int x = bases[i % randCount];
final int y = exponents[i % randCount];
total += powers[trial].power(x, y);
}
long start = System.currentTimeMillis();
for (int i = 0; i < count; i++) {
final int x = bases[i % randCount];
final int y = exponents[i % randCount];
total += powers[trial].power(x, y);
}
long end = System.currentTimeMillis();
System.out.printf("%25s: %d ms%n", powers[trial].toString(), (end - start));
System.out.println(total);
}

产生输出：

1
2
3
4
5
6

EasyPower: 7908 ms
-407261252961037760
NaivePower: 1993 ms
-407261252961037760
FastPower: 2394 ms
-407261252961037760

使用随机数和试验的参数确实会改变输出特性，但试验之间的比率始终与所示的一致。

相关讨论

确定if (odd)控制的是哪个操作？
对于机器整数算法来说，求幂的快速算法并不值钱。只有当一次乘法的代价远远大于任何一次移位的减量时，"快速"才会变得更好。请使用BigInteger重试。
我无法重现这些结果，对我来说，快的结果实际上快了40%。你能把你用的代码贴在上面吗？我怀疑那里有一些瑕疵。JVM上的标杆代码可能很棘手…
@布莱恩，你测试这是为了什么输入，你得到了什么时间结果？
X=2和Y=48的机器操作和内存访问的粗略(幼稚)比较显示快速：34 46，幼稚：144 192。这是关于您可以期望的O(日志)的。Java基准测试很难，但我们应该看看您是如何做到的。
@灰胡子，实际上是如果(甚至)。
你们得到预期结果的事实确实指出了我的测试方法的一个缺陷，但我还看不到它。可能不值得浪费时间调试测试框架。谢谢。
that is actually if(even)想想。或者参考你喜欢的实现，或者维基百科。
@greybeard-(foo%2==0)询问当foo除以2时，余数是否为零-这对于偶数是正确的。感谢您的时间和反馈。
为什么，谢谢-在这几十年之后，我可能忘记了。不管怎么说，我似乎暗示的是，你没有提供代码来完成通常的实现：用你喜欢的任何过程可视化来观察它，检查他的答案中的一个dymo414链接，或者咨询维基百科关于通过平方来进行指数化。
我并不是在试图找到"最理想"的解决方案，而是在测试这个特定的实现。不过，您应该同意，我的方法(我已经验证了它会产生正确的结果)所需的迭代次数应该比简单版本(o(logn)vs o(n))少很多，其中n表示30。
抱歉，我提供的代码中有一个bug现在在这里重复了：x/base，最好是long(如果你不在48小时内更改它，我会的)。
我可以为NaivePower的意外良好运行提供最好的解释，尽管它进行了更多的乘法，但它从乘法管道中的气泡展开/避免中获益最多：参见guava的LongMath.pow()中的条件乘法与条件乘法。
@灰胡子-谢谢你提醒我关于长基地-我已经在我的本地版本修复，忘记在这里编辑它。对于乘法管道，这是完全合理的。天哪，我爱Jit Voodoo！

EDOCX1的0个方面有两个问题：

最好用EDCOX1〔2〕代替EDCOX1〔1〕；按位运算更快。

您的代码总是递减y并执行额外的乘法，包括y是偶数的情况。最好把这部分放在else条款中。

不管怎样，我想你的基准测试方法并不完美。4x性能差异听起来很奇怪，如果看不到完整的代码就无法解释。

在应用了上述改进之后，我已经使用JMH基准验证了fastPower确实比naivePower快，系数为1.3x到2x。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

package bench;

import org.openjdk.jmh.annotations.*;

@State(Scope.Benchmark)
public class FastPow {
@Param("3")
int x;
@Param({"25","28","31","32"})
int y;

@Benchmark
public long fast() {
return fastPower(x, y);
}

@Benchmark
public long naive() {
return naivePower(x, y);
}

public static long fastPower(long x, int y) {
long result = 1;
while (y > 0) {
if ((y & 1) == 0) {
x *= x;
y >>>= 1;
} else {
result *= x;
y--;
}
}
return result;
}

public static long naivePower(long x, int y) {
long result = 1;
for (int i = 0; i < y; i++) {
result *= x;
}
return result;
}
}

结果：

1
2
3
4
5
6
7
8
9

Benchmark (x) (y) Mode Cnt Score Error Units
FastPow.fast 3 25 thrpt 10 103,406 ± 0,664 ops/us
FastPow.fast 3 28 thrpt 10 103,520 ± 0,351 ops/us
FastPow.fast 3 31 thrpt 10 85,390 ± 0,286 ops/us
FastPow.fast 3 32 thrpt 10 115,868 ± 0,294 ops/us
FastPow.naive 3 25 thrpt 10 76,331 ± 0,660 ops/us
FastPow.naive 3 28 thrpt 10 69,527 ± 0,464 ops/us
FastPow.naive 3 31 thrpt 10 54,407 ± 0,231 ops/us
FastPow.naive 3 32 thrpt 10 56,127 ± 0,207 ops/us

注：整数乘法运算速度非常快，有时甚至比额外的比较还要快。不要期望在long中使用合适的值进行巨大的性能改进。在指数较大的BigInteger上，快速功率算法的优势将更加明显。

更新

由于作者发布了基准，我必须承认令人惊讶的性能结果来自于常见的基准测试陷阱。我在保留原始方法的同时改进了基准，现在它表明fastPower确实比naivePower快，见这里。

改进版本中的关键更改是什么？

应在不同的JVM实例中分别测试不同的算法，以防止剖面污染。

必须多次调用基准，以允许正确的编译/重新编译，直到达到稳定状态。

一个基准测试应该放在一个单独的方法中，以避免堆栈上的替换问题。

由于Hotspot不自动执行此优化，因此y % 2替换为y & 1。

最小化了主基准循环中不相关操作的影响。

手动编写微基准是一项困难的任务。这就是为什么强烈建议使用适当的基准框架(如JMH)的原因。

相关讨论

你说得对。按位和VSD并不重要——Java优化了这一点。这两个变化都不会影响我的测试结果。这是一个玩具问题，特别是针对本地整数，因此使用biginteger会破坏其目的。
@Brian汇编转储和JMH基准测试结果证明，&确实比%生成更好的代码。
@Brian"两个变化都不会影响我的测试结果"-这也表明您的基准度量并不是您期望的度量。
也许吧，但是在我的基准测试中，进行这种更改对运行时没有可测量的影响。这意味着运行时由其他操作控制。
我已经发布了我的基准代码——在我的生活中，我没有发现任何明显的错误。也许你看到我错过了什么？
@布莱恩，根据我的经验，(x%2)==0并没有优化到(x&1)==0，这确实有区别。C编译器通常是这样做的，Java没有。你是如何验证Java优化这一点的？
@布莱恩是的，在你的基准测试中有很多常见的错误。1。它测量OSR'ED代码；2.它在单个JVM中执行不同的度量，甚至在单个循环中也是如此。三。不使用函数结果。4。没有预热等等。看看我如何在Java中编写正确的微基准？
Java的安东尼慕斯在编译时间和运行时优化之间有区别。javac不优化它并不意味着jit不优化。我非常肯定JIT会在这里优化它。
我假设(我知道)，但从经验上讲，当我做这个更改时，运行时并没有以统计上显著的方式发生变化，这意味着我的运行时被其他一些操作所控制。我在这里的目标不是找到最快的实现——而是弄清楚为什么我的测试显示简单的实现要快4倍。
@apangin-osr v jit不应该与数百万次迭代有关。热身没什么区别-只是用它做了一个测试。但是你完全正确地忘记消耗输出。杜赫。但是！即使在做了这些更改之后，我仍然看到这个幼稚的函数比"快速"版本快25%。
"布瑞恩，那不是真的。由于热点编译器性质，OSREST代码与从零开始编译的代码不同。也尝试在EDOCX1×3阵列中留下EDOCX1×2单独的时间，它的时间很可能会改变。
Apangin -我只是试着在阵列中单独使用FASTPOWER，只是时间稍微变了。我也尝试过天真的版本。幼稚的版本仍然稍微快一点。不管怎样，如果你认为这真的在我的基准上有很大的不同，你怎么建议我处理OSREST代码呢？谢谢！
@Brian我在保留原始方法的同时改进了您的基准。请看这里。现在它表明，FastPower确实更快。顺便问一下，你使用了什么Java版本？我在JDK 8U60 X64上测试过。
@A引擎，你能解释一下为什么原始代码会显示这种行为吗？
@A引擎非常酷-我实际上尝试在单独的虚拟机中单独运行它们，但没有观察到显著的差异。我用Java1.7.0Ey95(OpenJDK运行时环境(ICETEA 2.64))运行。除了你的代码比我的更干净之外，我看不出任何功能上的区别…你认为我们两次跑步的结果不同完全是由于你在结构上的不同吗？或者你的结果会因为更好的JVM而不同吗？
@我刚下载并在我的系统上运行了你的代码(很抱歉，之前应该这样做)。我得到的结果和你的一样。所以…为什么我的代码和您的代码之间的结构差异会造成如此巨大的差异？(还记得这是在我的数组中只有一个实例的情况下运行的。)
@布赖恩·马丁斯是的，结构的改变会产生影响。记住，JIT编译单元是一个方法。不要把所有的基准代码放在一个单一的main方法中。我已经更新了关于基准问题的答案。
@阿潘金-非常感谢！仅供参考——mod与bitwise的比较，并没有影响我的结果，使用你的代码(我尝试了两种方法)。
@马丁斯是的，而且您不能在运行时在Hotspot中进行所有优化。出于某种原因，C编译比JIT花费的时间要长得多。我的基准测试表明Hotspot也不会在运行时执行这种优化。
@Anony Mousse在查看由JIT生成的汇编代码时，我可以看到它确实优化了% 2，但是客户机VM和服务器VM之间可能存在差异，以及不同的版本，天知道是什么。

如果没有能力回顾和复制你的基准，那么尝试分解你的结果是没有意义的。这可能是由于输入选择不当、基准测试错误(例如在一个测试之前运行另一个测试(从而给JVM时间"预热")等原因造成的。请分享您的基准代码，而不仅仅是您的结果。

我建议在你的测试中包括番石榴的EDOCX1(SRC)，这是一种广泛使用和良好的基准测试方法。虽然您可能能够用某些输入击败它，但在一般情况下，您不太可能改进它的运行时(如果可以，他们很乐意听到)。

不出意料的是，Math.pow()比仅正整数算法的性能更差。看看"快速"与"幼稚"的实现，很明显，这很大程度上取决于你选择的输入，正如迈克·卡默曼所建议的那样。对于小值的y，"幼稚"的解决方案显然要做的工作更少。但是对于较大的值，我们使用"快速"实现节省了大量迭代。

相关讨论

在我看来，这个问题的第一个fastPower(base, exponent)是错误的，如果没有给出错误的结果。(下面的intPower()的第一个版本是错误的，因为除了稍微误导基准结果之外，给出了错误的结果。)由于评论"格式化能力"，另一种通过平方来表示求幂的形式作为答案来争论：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

static public long intPower(int base, int exponent) {
if (0 == base
|| 1 == base)
return base;
int y = exponent;
if (y <= 0)
return 0 == y ? 1 : -1 != base ? 0 : y % 2 == 1 ? -1 : 1;
long result = y % 2 == 1 ? base : 1,
power = base;
while (1 < y) {
power *= power;
y >>= 1; // easier to see termination after Type.SIZE iterations
if (y % 2 == 1)
result *= power;
}
return result;
}

如果使用微基准(整数求幂的典型用法是什么？)如果使用框架，请进行适当的预热。千万不要把时间花在微基准测试结果上，因为每个选项的计时运行时间少于5秒。

另一种选择来源于Guava的LongMath.pow(b, e)：

1
2
3
4
5
6
7
8
9
10
11
12
13

public long power(int base, int k) {
for (long accum = 1, b = base ;; k >>>= 1)
switch (k) {
case 0:
return accum;
case 1:
return accum * b;
default:
if ((k&1) != 0) // guava uses conditional multiplicand
accum *= b;
b *= b;
}
}

相关讨论

while循环运行log2(y)次，而for循环运行y次，因此根据您的输入，一个运行得比另一个快。

while循环(最坏情况)运行：

比较(while条件)

模，

比较，最坏的情况三更多的OPS：

乘法运算

位移位指定

又一次乘法，最后，

减量

而幼稚的for循环运行：

比较(for条件)

乘法，和

增量(for迭代器)

因此，对于小值的y，您会期望简单的循环更快，因为for循环中更少的操作比"快速"方法的log2减少更好，只要这些额外操作所损失的时间大于log2减少y所获得的时间。

相关讨论

"两者兼而有之"并非真实。- 1，
看看EDOCX1的0个，快的一个不运行Y次
好点，更新。
EDCOX1的1是什么呢？
@启动右移位和赋值，只要y真的是整数，就和y /= 2一样。
(问题的一部分是，"对fast的分析"使用了问题中fast的错误实现。)
一旦有更好的答案出现，我会很高兴地删除这个答案。
depending on [circumstances], one [alternative] will run faster than the other-这是典型的比较运行时分析。
我在这里做零真正的运行时分析，其他人可以做。编译后的代码可以根据不同的指令进行优化，直到有人愿意坐下来为Brian运行数字(他自己应该这样做)，通过观察一个运行O(log2(n))，但运行更多的操作，而另一个运行更少的操作，这似乎是一个适当的分析水平。
我已经编译了自己的代码，非常感谢，我看到的是"快速"版本的算术指令和分支是原始版本的两倍。但是，对于一个指数为30的人来说，我希望"快速"版本只通过这些语句5次，而对于幼稚的版本则是30次。因此，对于y=30，我希望"快速"版本的速度快两到三倍…但我看不出有任何理由使大Y的速度慢25%。
你的文章中的测试代码显示了你如何比较这些方法，以及y的测试结果数据在1到1000之间？超过随机整数x？我只看到一个实例比较：这不是可靠的数据，这总是一个侥幸。
@超过[11000]的mike'pomax'kamermans-y对于产生64位长度结果的计算没有任何意义。我已经更新了我的描述，以便更好地了解我在做什么。
对于这样的任务，理论上的运行时分析是无用的。常数因子不能被忽略。甚至CPU周期计数也没用，因为我们这里有一台虚拟机。
它绝对不是无用的：它提供了一个粗略的，绝对不准确的，但信息丰富的洞察可能发生的事情，这是一类堆积如山的答案：如果你有答案，张贴它，但如果你只是有信息，可以帮助提出问题的人在寻找可能的答案的路线上，那些人说。100%也可以，因为它们很有用。这个答案几乎可以从字面上解释常量因素在这里已经不能被忽略了，一个适当的分析涉及到对JVM字节码的分析。