Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 59921 invoked from network); 5 Nov 2007 20:36:17 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 5 Nov 2007 20:36:17 -0000 Received: (qmail 69084 invoked by uid 500); 5 Nov 2007 20:36:04 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 68583 invoked by uid 500); 5 Nov 2007 20:36:03 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 68574 invoked by uid 99); 5 Nov 2007 20:36:03 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Nov 2007 12:36:03 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of gcjhd-harmony-dev@m.gmane.org designates 80.91.229.2 as permitted sender) Received: from [80.91.229.2] (HELO ciao.gmane.org) (80.91.229.2) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Nov 2007 20:36:05 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ip8fO-0006JJ-0p for dev@harmony.apache.org; Mon, 05 Nov 2007 20:35:26 +0000 Received: from 89-178-81-25.broadband.corbina.ru ([89.178.81.25]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 05 Nov 2007 20:35:26 +0000 Received: from egor.pasko by 89-178-81-25.broadband.corbina.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 05 Nov 2007 20:35:26 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: dev@harmony.apache.org From: Egor Pasko Subject: Re: [perf] Comparative benchmarking Date: 05 Nov 2007 23:35:03 +0300 Lines: 59 Message-ID: <0vqmytsh1mw.fsf@gmail.com> References: <472C548F.6030609@gmail.com> <9623c9a50711040630t7fe443b4r6f05895cc166641@mail.gmail.com> <472E052D.2050804@gmail.com> <9623c9a50711050447g1cac56a0jd0d895608c5ac8ab@mail.gmail.com> <472F2438.80707@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 89-178-81-25.broadband.corbina.ru User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 Sender: news X-Virus-Checked: Checked by ClamAV on apache.org 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