Name: skT88420 Date: 12/22/99


Q:\performanceAnalysis\trackerViewer\experiments>java -version
java -version
java version "1.3beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3beta-O)
Java(TM) HotSpot Client VM (build 1.3beta-O, mixed mode)

Q:\performanceAnalysis\trackerViewer\experiments>

This might not be considered a bug, as much as a performance problem.

Or, it may be an fdlibm problem. I dont' have the time or resources to
investigate that possibility.

since I didn't see this on the bug parade, I thought I should mention it to
someone.

I'm pretty sure the x86 processors support floating point squareroot, so I find
it hard to believe that such a discrepancy can exist? Presumably the x86
processor follows the IEEE754 standards.

Also, fwiw, I was not able to figure this out on Solaris, there I'm using 1.2.1,
but the profiler seems to indicate that Math.sqrt is never called.


import java.util.Random;

public class TimingTest {
    public static void main(String[] args) {

Random rnd = new Random();
double count = 0;
for (int i = 0; i < 10000000; i++) {
count += Math.sqrt(rnd.nextDouble());
count += Math.exp(0.5 * Math.log(rnd.nextDouble()));
};

    };
};

--------------------------------

The output ....

java -Xprof TimingTest

Flat profile of 65.94 secs (6584 total ticks): main

  Interpreted + native Method
  0.1% 0 + 5 java.util.zip.ZipFile.open
  0.0% 0 + 2 java.io.FileInputStream.open
  0.0% 0 + 2 java.io.Win32FileSystem.canonicalize
  0.0% 0 + 1 java.util.HashMap$Entry.<init>
  0.0% 0 + 1 java.lang.Math.log
  0.0% 0 + 1 java.lang.System.arraycopy
  0.0% 1 + 0 java.util.zip.ZipEntry.getSize
  0.0% 1 + 0 java.lang.StringBuffer.<init>
  0.0% 1 + 0 java.util.Random.next
  0.0% 0 + 1 sun.net.www.protocol.file.Handler.openConnection
  0.0% 0 + 1 java.io.BufferedReader.fill
  0.3% 3 + 14 Total interpreted

     Compiled + native Method
  8.0% 530 + 0 java.util.Random.next
  4.3% 280 + 0 java.util.Random.nextDouble
  1.1% 74 + 0 TimingTest.main
  0.5% 33 + 0 java.lang.Math.sqrt
  0.5% 31 + 0 java.lang.Math.log
  0.5% 30 + 0 java.lang.Math.exp
 14.9% 978 + 0 Total compiled

         Stub + native Method
 67.1% 44 + 4374 java.lang.StrictMath.sqrt
  8.6% 39 + 524 java.lang.StrictMath.log
  8.0% 54 + 475 java.lang.StrictMath.exp
 83.7% 137 + 5373 Total stub

  Thread-local ticks:
  0.0% 1 Class loader
  1.2% 78 Unknown code


Global summary of 65.94 seconds:
100.0% 6585 Received ticks
100.0% 6584 Delivered ticks
100.0% 6584 All ticks
  0.0% 1 Class loader
  1.2% 78 Unknown code

Q:\performanceAnalysis\trackerViewer\experiments>

So, I can cut the time of sqrt in 4, by taking logs, and exponentials. I don't
believe the standards are defined so strangely. But I could be wrong.

This reminds me of why all the curmudgeonly fortran types hated C when
it started getting popular. Because it was slow numerically, and because
they didn't follow any of the accepted standards for numerical computations.
(the usual IEEE floating point standards) At least Java is following the
standards! Thank you.
(Review ID: 99287)
======================================================================