All, I'm sorry not replying earlier (I'm in a business trip) but I want to add that Jitrino.OPT does support calling of some (annotated or added to a method list) JNI methods without creation of M2N frame.
Yuri Kashnikoff did this patch and I hope we will commit it before M4. Yuri, can you share your patch with us? On Nov 7, 2007 5:46 AM, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > > On Nov 7, 2007 7:09 AM, Robin Garner <[EMAIL PROTECTED]> wrote: > > > > Aleksey Shipilev wrote: > > > On 07 Nov 2007 00:27:25 +0300, Egor Pasko <[EMAIL PROTECTED]> 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. > > > > > > BTW, in my thought this benchmark is like the top of the iceberg > > > called "FP performance problems". > > > > > > Thanks, > > > Aleksey. > > > > > You might be interested to know that the JikesRVM implementation calls > > out to glibc via a fast syscall (we have an @SysCall annotation for > > native methods), and it is 1.5x slower than Sun 1.6 on a Core2/Linux for > > Tim's (non-strict) benchmark. Maybe you can squeeze the overhead of > > intrinsic calls down a bit further ? > > I am also wondering why not to leverage the system support directly. > This solution is by default portable. :-) > > > cheers > > > > cheers > > > > > > > -- > http://xiao-feng.blogspot.com > -- Mikhail Fursov
