和Java Math库有关的那些坑

最近在进行ARM切换的过程中发现了很多因为Java Math库在不同的平台上的精度不同导致用例失败,我们以Math.log为例,做一下简单的分析。下面是一个简单的计算log(3)的示例:

public class Hello {
    public static void main(String[] args) {
        System.out.println("Math.log(3): " + Math.log(3));
        System.out.println("StrictMath.log(3): " + StrictMath.log(3));
    }
}

我们发现,在x86下,Math的结果为 1.0986122886681098

# on x86
$ java Hello
Math.log(3): 1.0986122886681098
StrictMath.log(3): 1.0986122886681096

而aarch64的结果为 1.0986122886681096

# on aarch64
$ java Hello
Math.log(3): 1.0986122886681096
StrictMath.log(3): 1.0986122886681096

而在Java 8的 官方文档 中,对此有明确说明:

Unlike some of the numeric methods of class StrictMath, all implementations of the equivalent functions of class Math are not defined to return the bit-for-bit same results. This relaxation permits better-performing implementations where strict reproducibility is not required.

因此,结论是: Math的结果有可能是不精确的,如果结果对精度有苛求,那么请使用StrictMath

在此,我们留下2个疑问:

the bit-for-bit same results
better-performing implementations

2. 深度探索一下Math的实现

为了能够更清晰的看到StrictMath的实现,我们深入的看了下JDK的实现。

2.1 Math和StrictMath的基本实现

我们从Math.log和StrictMath.log的实现为例,进行深入学习:

  1. Math.log的代码 表面上很简单,就是直接调用StrictMath.log。

    public static double log(double a) {
        return StrictMath.log(a); // default impl. delegates to StrictMath
    }
    
  2. StrictMath的代码 ,会调用 StrictMath.c 中的方法,最终会调用fdlibm的 e_log.c 的实现。

总体的实现和下图类似:

对于StrictMath来说,没有什么黑科技,最终的实现就是e_log.c的ieee754标准实现,是通过C语言实现的,所以在各个平台的表现是一样的,整个流程如图中蓝色部分。感兴趣的同学可以看 e_log.c 的源码实现即可。

2.2 Math的黑科技

回到我们最初的起点,再加上一个问题:

the bit-for-bit same results
better-performing implementations

原来,JVM为了让各个arch的CPU能够充分的发挥自己CPU的优势,会根据架构不同,会通过Hotspot intrinsics替换掉Math函数的实现,我们可以从代码 vmSymbols.hpp 看到,Math的很多实现都被替换掉了。log的替换类似于:

do_intrinsic(_dlog, java_lang_Math, log_name, double_double_signature, F_S)

最终,Math的调用为下图红色部分:

log的实现:

  • 在x86下,最终其实调用的是 assembler_x86.cpp 中的 flog 实现:

    void Assembler::flog() {
      fldln2();
      fxch();
      fyl2x();
    }
    
  • 而在aarch64下,我们可以从 src/hotspot/cpu/ 目录下看到,aarch64并未实现优化版本。因此,实际aarch64调用的就是标准的StrictMath。

正因如此,x86汇编的计算结果的差异导致了x86和aarch64结果在Math.log差异。

当然,aarch64也在JDK 11中,对部分的Math接口做了加速实现,有兴趣可以看看 JEP 315: Improve Aarch64 Intrinsics 的实现。

3. toRadians的小插曲

在ARM优化过程中,有的是因为Math库和StrictMath不同的实现造成结果不同,所以我们如果对精度要求非常高,直接切到StrictMath即可。

但有的函数,由于在Java大版本升级的过程中,出现了一些实现的差异,先看一个简单的Java程序

public class Hello {
    public static void main(String[] args) {
	System.out.println("Math.toRadians(0.33): " + Math.toRadians(0.33));
	System.out.println("StrictMath.toRadians(0.33): " + StrictMath.toRadians(0.33));
    }
}

我们分别看看在Java11和Java8的结果:

$ /usr/lib/jvm/java-11-openjdk-amd64/bin/java Hello
Math.toRadians(0.33): 0.005759586531581287
StrictMath.toRadians(0.33): 0.005759586531581287
$ /usr/lib/jvm/java-1.8.0-openjdk-amd64/bin/java Hello
Math.toRadians(0.33): 0.005759586531581288
StrictMath.toRadians(0.33): 0.005759586531581288

最后一位很奇怪的差了1,我们继续深入进去看到toRadians的实现:

  • Java8的实现 为:

    // Java 8 
    public static double toDegrees(double angrad) {
        return angrad * 180.0 / PI;
    }
    
  • Java11的实现 为:

    private static final double DEGREES_TO_RADIANS = 0.017453292519943295;
    public static double toRadians(double angdeg) {
        return angdeg * DEGREES_TO_RADIANS;
    }
    

原来在Java11的实现中,为了优化性能,将 * 180.0 / PI 提前算好了,这样每次只用乘以乘数即可,从而化简了计算。这也最终导致了,Java8和Java11在精度上有一些差别。

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章