Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of t.p.ellison@gmail.com
 designates 209.85.134.191 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=OtpI25K/AV+uLGGVQf41baS6pu/G8xQEiqTDK3XOx5s6LZy8oxIG0C8WX3EjSiIqmVyzeX/1P3gcX0WM6Yg5v1PpEF0pzzSVfY3N3fQeoJ1OMZm7ilYHMCx1O8oQ+4/TItuTHPirYq0Jp5ArLDm5+4cCsRvnwgD1W1VJyGoM8oI=
Message-ID: <47304FB3.7020306@gmail.com>
Date: Tue, 06 Nov 2007 11:27:47 +0000
From: Tim Ellison <t.p.ellison@gmail.com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: [perf] Comparative benchmarking
References: <472C548F.6030609@gmail.com>
 <9623c9a50711040630t7fe443b4r6f05895cc166641@mail.gmail.com>
 <472E052D.2050804@gmail.com>
 <9623c9a50711050447g1cac56a0jd0d895608c5ac8ab@mail.gmail.com>
 <472F2438.80707@gmail.com> <0vqmytsh1mw.fsf@gmail.com>
In-Reply-To: <0vqmytsh1mw.fsf@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Egor Pasko wrote:
> On the 0x385 day of Apache Harmony Tim Ellison wrote:
>> 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++

Credit to Xiao-Feng for that, not me.

>> Can we squeeze a bit more out of the JIT?
> 
> actually, Math.sqrt() is native and taken from the slow and portable
> FDLIBM.

I guess that was my point -- I'm making the assumption, given the orders
of magnitude difference in time, that we are going through JNI and
IBM/Sun are recognizing the method in the JIT compiler and creating code
for it directly.

> 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).

I defer to you for the compatibility between the hardware instructions
and Java standard, but looks like others are doing the 'right thing', or
am I making a wrong assumption here?

> 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.

ack.

Regards,
Tim