On the 0x385 day of Apache Harmony Tim Ellison wrote:
> Xiao-Feng Li wrote:
> > A quick check shows that lots of time is spent in sqrt() computation:
> >
> > hyluni.dll!___ieee754_sqrt() + 0x1f3 C
> > hyluni.dll!_fdlibm_sqrt() + 0x11 C
> > hyluni.dll!internal_sqrt(double arg1=1528.7960683139602) Line 301 + 0xe C
> > hyluni.dll!Java_java_lang_Math_sqrt(const JNINativeInterface_ * *
> > env=0x0206aaa0, _jobject * jclazz=0x0013f5b0, double
> > arg1=1528.7960683139602) Line 596 + 0xe C
> > 0345c1b2()
>
> In this micro-bench ...
>
> ======================================================================
> public static void main(String[] args) {
>
> // warm-up
> double result = 0.0d;
> for (int i = 0; i < 10000; i++) {
> result += Math.sqrt((double) i);
> }
>
> // Timed run
> result = 0.0d;
> long start = System.currentTimeMillis();
> for (int i = 0; i < 1000000; i++) {
> result += Math.sqrt((double) i);
> }
>
> System.out.println("Result = " + result + " in "
> + (System.currentTimeMillis() - start) + "ms");
> }
> ======================================================================
>
>
> Harmony 5.0 M3 prints
> Result = 6.666661664588418E8 in 1352ms
> IBM 5.0 SR5a prints
> Result = 6.666661664588418E8 in 40ms
> Sun 1.6.0-b105 prints
> Result = 6.666661664588418E8 in 40ms
Wow, good catching microbenchmark! Tim++
> Can we squeeze a bit more out of the JIT?
actually, Math.sqrt() is native and taken from the slow and portable
FDLIBM. I believe, libc implementation is supposed to be
faster. -ffast-math does not suit us because sqrt() is a part of
IEEE754 standard which is a part of Java (with signalling exception).
In fact, NBody multiplies by 1/sqrt(x) function, and this is where
both JIT and native implementation could help. multiplication and
1/sqrt(x) must be cheaper than sqrt(x) and division, but I am not sure
it would make an IEEE754 compatible solution.
--
Egor Pasko