Uploaded image for project: 'Hive'
  1. Hive
  2. HIVE-23161 Umbrella issue for Hive on ARM issues
  3. HIVE-23133

Numeric operations can have different result across hardware archs

    XMLWordPrintableJSON

Details

    • Sub-task
    • Status: Closed
    • Major
    • Resolution: Fixed
    • None
    • 4.0.0-alpha-1
    • None
    • None

    Description

      Use java.lang.StrictMath rather than java.lang.Math for compatibility in the following UDFs:

      UDFCos.java

      UDFExp.java

      UDFLn.java

      UDFLog.java

      UDFLog2.java

      UDFLog10.java

       

      Currently, we have set up an ARM CI to test out how Hive works on ARM platform:

      https://builds.apache.org/view/H-L/view/Hive/job/Hive-linux-ARM-trunk/

      Among the failures, we have observed that some numeric operations can have different result across hardware archs, such as:

      https://builds.apache.org/view/H-L/view/Hive/job/Hive-linux-ARM-trunk/25/testReport/org.apache.hadoop.hive.cli/TestCliDriver/testCliDriver_vector_decimal_udf2_/

      https://builds.apache.org/view/H-L/view/Hive/job/Hive-linux-ARM-trunk/25/testReport/org.apache.hadoop.hive.cli/TestSparkCliDriver/testCliDriver_subquery_select_/

      https://builds.apache.org/view/H-L/view/Hive/job/Hive-linux-ARM-trunk/25/testReport/org.apache.hadoop.hive.cli/TestSparkCliDriver/testCliDriver_vectorized_math_funcs_/

      we can see that the calculation results of log, exp, cos, toRadians etc is slitly different than the .out file results that we are

      comparing(they are tested and wrote on X86 machines), this is because of we use Math Library for these kind of calculations.

      and according to the illustration:

      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.

      By default many of the Math methods simply call the equivalent method in StrictMath for their implementation.
      Code generators are encouraged to use platform-specific native libraries or microprocessor instructions, where available,
      to provide higher-performance implementations of Math methods.

      so the result will have difference across hardware archs.

      On the other hand, JAVA provided another library StrictMath that will not have this kind of problem as according to its' reference:

      To help ensure portability of Java programs, the definitions of some of the numeric functions in this package require that they produce
      the same results as certain published algorithms.

      So in order to fix the above mentioned problem, we have to consider switch to use StrictMath instead of Math.
       

       

       

      Attachments

        1. HIVE-23133.6.patch
          18 kB
          Zhenyu Zheng
        2. HIVE-23133.5.patch
          19 kB
          Zhenyu Zheng
        3. HIVE-23133.4.patch
          20 kB
          Zhenyu Zheng
        4. HIVE-23133.3.patch
          16 kB
          Yikun Jiang
        5. HIVE-23133.2.patch
          21 kB
          Yikun Jiang
        6. HIVE-23133.1.patch
          6 kB
          Yikun Jiang

        Issue Links

          Activity

            People

              Kevin_Zheng Zhenyu Zheng
              Kevin_Zheng Zhenyu Zheng
              Votes:
              1 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: