harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [perf] Comparative benchmarking
Date Mon, 05 Nov 2007 20:35:03 GMT
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


Mime
View raw message