【问题标题】:Increasing Java's BigInteger performance提高 Java 的 BigInteger 性能
【发布时间】:2019-01-06 16:31:25
【问题描述】:

如何提高 Java 的 Big Integer 的性能?

例如,这个阶乘程序:

import java.math.*;
class Fac {
  public static void main(String[] args) {
    BigInteger i = BigInteger.ONE;
    for(BigInteger z=BigInteger.valueOf(2);z.compareTo(BigInteger.valueOf(99999)) != 0;) {
      i = i.multiply(z);
      z = z.add(BigInteger.ONE);
    }
    System.out.println( i );
  }
}

该程序在31.5s 完成

在 C++ 中的位置:

#include <iostream>
#include <gmpxx.h>
using namespace std;
int main() {
  mpz_class r;
  r = 1;
  for(int z=2;z<99999;++z) {
    r *= mpz_class(z);
  }
  cout << r << endl;
}

1.0s 完成

和 Ruby(用于比较):

puts (2...99999).inject(:*)

4.4s (Ruby) 和 32.2s 在 JRuby 中完成

还有 Go(用于比较):

package main
import (
 "fmt"
 "math/big"
)
func main() {
  i := big.NewInt(1);
  one := big.NewInt(1)
  for z := big.NewInt(2); z.Cmp(big.NewInt(99999)) < 0;  {
      i.Mul(i,z);
      z.Add(z,one)
  }
  fmt.Println( i );
}

1.6s 和0.7s 完成MulRange

编辑根据要求:

import java.math.*;
class F2 {
  public static void main(String[] args) {
    BigInteger i = BigInteger.ONE, r = BigInteger.valueOf(2);
    for(int z=2; z<99999 ; ++z) {
      i = i.multiply(r);
      r = r.add(BigInteger.ONE);
    }
    System.out.println( i );
  }
}

运行时长:31.4s

EDIT 2 对于那些仍然认为第一个和第二个 java 代码不公平的人..

import java.math.*;
class F3 {
  public static void main(String[] args) {
    BigInteger i = BigInteger.ONE;
    for(int z=2; z<99999 ; ++z) {
      i = i.multiply(BigInteger.valueOf(z));
    }
    System.out.println( i );
  }
}

31.1s 完成

编辑 3 @OldCurmudgeon 评论:

import java.math.*;
import java.lang.reflect.*;
class F4 {
  public static void main(String[] args) {
    try {
      Constructor<?> Bignum = Class.forName("java.math.MutableBigInteger").getDeclaredConstructor(int.class);
      Bignum.setAccessible(true);
      Object i = Bignum.newInstance(1);
      Method m = i.getClass().getDeclaredMethod("mul", new Class[] { int.class, i.getClass()});
      m.setAccessible(true);
      for(int z=2; z<99999 ; ++z) {
        m.invoke(i, z, i);
      }
      System.out.println( i );
    } catch(Exception e) { System.err.println(e); } 
  }
}

23.7s 完成

EDIT 4 正如@Marco13 所说,最大的问题是字符串的创建,而不是 BigInteger 本身。

  • 大整数:3.0s
  • MutableBigInteger 破解:10.1s
  • 字符串创建:~20s

【问题讨论】:

  • 这不是一个完全公平的比较;在 Java 中,您使用 BigInteger 作为循环变量,在 C++ 中,您只是使用 int
  • ^^ 解决方法是开始使用 int。并缓存 .valueOf ,否则您每次都会创建一个新的 BigInteger。
  • 您可以尝试使用MutableBigInteger
  • 您已经消除了所有先前值的 GC 开销,但您仍然经常重新分配 int[]。我试图调整您的代码以预先分配一个 int[50,000] 但它似乎对我不起作用。我可能做错了。
  • 在 java 8 中,编辑 2 运行 3.5 秒。比 C++ 慢 3 倍还不错

标签: java biginteger


【解决方案1】:

开始于:

import java.math.*;
class Fac {
  public static void main(String[] args) {
    BigInteger i = BigInteger.ONE;
    BigInteger maxValue = BigInteger.valueOf(99999);

    for(BigInteger z=BigInteger.valueOf(2); z.compareTo(maxValue) != 0;) {
      i = i.multiply(z);
      z = z.add(BigInteger.ONE);
    }

    System.out.println( i );
  }
}

.valueOf 来源

1081    public static BigInteger More ...valueOf(long val) {
1082        // If -MAX_CONSTANT < val < MAX_CONSTANT, return stashed constant
1083        if (val == 0)
1084            return ZERO;
1085        if (val > 0 && val <= MAX_CONSTANT)
1086            return posConst[(int) val];
1087        else if (val < 0 && val >= -MAX_CONSTANT)
1088            return negConst[(int) -val];
1089
1090        return new BigInteger(val);
1091    }

自从MAX_CONSTANT 为 16 后,每次都会创建一个新的 BigInteger。


我认为它可能会变慢,因为 GC 开始收集一些较旧的 BigInteger 实例,但无论如何您应该始终使用 int 和 long.. 这里并不真正需要 BigInteger。

在您上次测试后,我认为我们可以确定它可能是由 GC 引起的。

【讨论】:

【解决方案2】:

计算本身不应该花费这么长时间。但是,字符串创建 可能需要一段时间。

这个程序(对 OldCurmudgeon 和 https://stackoverflow.com/a/8583188/823393 表示敬意)在 Core I7、3GHz、Java 7/21 上使用 -Xmx1000m -sever 启动时大约需要 3.9 秒:

import java.lang.reflect.Constructor;
import java.lang.reflect.Method;

public class FastBigInteger
{
    public static void main(String[] args)
    {
        try
        {
            Class<?> c = Class.forName("java.math.MutableBigInteger");
            Constructor<?> con = c.getDeclaredConstructor(int.class);
            con.setAccessible(true);
            Object i = con.newInstance(1);
            Method m = c.getDeclaredMethod("mul", new Class[] { int.class, c });
            m.setAccessible(true);
            long before = System.nanoTime();
            for (int z = 2; z < 99999; ++z)
            {
                m.invoke(i, z, i);
            }
            long after = System.nanoTime();
            System.out.println("Duration "+(after-before)/1e9);

            String s = i.toString();
            int n = s.length();
            int lineWidth = 200;
            for (int j=0; j<n; j+=lineWidth)
            {
                int j0 = j;
                int j1 = Math.min(s.length(), j+lineWidth);
                System.out.println(s.substring(j0, j1));
            }
        }
        catch (Exception e)
        {
            System.err.println(e);
        }
    }
}

打印实际计算的持续时间后,它需要很长时间才能完成创建字符串,但这里几乎不应该考虑这一点。

这仍然是不是一个合理的基准,但表明至少计算本身没有问题。

但不可否认,当只使用 BigInteger 而不是这个 MutableBigInteger hack 时,它需要 appx。 15 秒,与 C++ 实现相比相当差。

【讨论】:

  • 你是对的,它在3.0s 完成,总时间23.8s,所以问题出在字符串创建上。
【解决方案3】:

我有一些使用大整数计算第 100 000 个斐波那契数的 clojure 代码。现在这个线程不是关于 clojure 的,而是因为 clojure 在 JVM 上运行,并且我在一些现有的大整数实现上运行了基准测试,我觉得这里的评论可能很有价值。

使用 JVM BigInteger 类(clojure 中用 xN 字面语法表示)时的算法如下所示:

(defn fibo [n]
  (loop [i n a 1N b 1N]
    (if (> i 0)
      (recur (dec i) b (+ a b))
      a)))

我使用四个大整数实现重新实现了这一点,并使用 clojure criterium 库运行基准测试,该库进行热身和一些统计分析以尝试获得一些相关的数字。

在我的 2.8 GHz Intel Core i7 macbook 上的结果:

现在我意识到这都是轶事,我们只是在这里测量加法,但我不得不说,huldra 流行语“自 2015 年以来表现优于 BigInteger”在这种情况下似乎非常准确。

非常感谢任何具有指向更快大整数加法算法的潜在候选者的指针的 cmets。

【讨论】:

    【解决方案4】:

    其他答案与使用代码调整性能有关。

    如果您使用的 java 版本低于 1.8.0_151,您可以使用以下命令选项调整大整数性能:

    -XX:+UseMontgomerySquareIntrinsic
    -XX:+UseMontgomeryMultiplyIntrinsic
    -XX:+UseSquareToLenIntrinsic
    -XX:+UseMultiplyToLenIntrinsic
    

    1.8.0_151 之后,这些选项默认开启。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多