harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Ozhdikhin" <pavel.ozhdik...@gmail.com>
Subject Re: [perf] Comparative benchmarking
Date Wed, 07 Nov 2007 12:20:50 GMT
On 11/7/07, Maksim Ananjev <maksim.ananjev@gmail.com> wrote:
>
> Btw, why not to implement api magic that would substitute sqrt(x) by
> hardware sse sqrt instruction? "sqrtpd", afair
>
> It might be faster then JNI call.


The native part of the API may have the same native code as the JIT would
produce if it implements sqrt using magics. Let's see our performance on the
test using LightJNI calls. BTW, we can estimate our potential speedup limit
by writing the same micro-benchmark on C using FDLIBM or another sqrt
implementation.

Thanks,
Pavel


Just an idea. I am not sure if such JIT hack looks pretty from the
> point of view of design.
>
>
> 2007/11/7, Egor Pasko <egor.pasko@gmail.com>:
> > On the 0x387 day of Apache Harmony Aleksey Shipilev wrote:
> > > On 07 Nov 2007 00:27:25 +0300, Egor Pasko <egor.pasko@gmail.com>
> wrote:
> > > > Vladimir, guess what? :) I actually mixed several things
> > > > altogether.
> > > <giggly>(sigh) As usual, miracle does not happen :) I dreamed to see
> > > software sqrt() implementation that could be faster than hardware one.
> > > </giggly>
> > >
> > > > So, we are left with SSE asm that can be inlined by JIT and AFAI can
> > > > see it is not as fast as HotSpot? Weird :)
> > > No, for now we have just the intrinsic in native code, so we also have
> > > overheads for JNI transition (and it is heavy!), parameter passing,
> > > chains of calls, etc. I believe that sqrt() magic will lead that NBody
> > > performance very close to RI.
> >
> > Ha! I thought, you made it without JNI. Then we have a chance! If we
> > do not get it through magics we still have another chance to implement
> > 1/sqrt() :)
> >
> > > BTW, in my thought this benchmark is like the top of the iceberg
> > > called "FP performance problems".
> >
> > Yes, I know, DRLVM has not been actively optimized for FP calc.
> >
> > --
> > Egor Pasko
> >
> >
> >
>
>
> --
> Maksim
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message