Math trig intrinsics and compiler options

[gustav trede]

2009/8/7 Andrew John Hughes <gnu_andrew at member.fsf.org>

> 2009/8/7 Ian Rogers <ian.rogers at manchester.ac.uk>:
> > 2009/8/6 Andrew John Hughes <gnu_andrew at member.fsf.org>:
> >> 2009/8/6 Joseph D. Darcy <Joe.Darcy at sun.com>:
> >>> My preferred long-term approach is to port the FDLIBM C code to Java,
> which
> >>> I've wanted to do for a while, but has never bubbled to the top of my
> to-do
> >>> list.
> >>>
> >>
> >> I don't know the full history of it (perhaps mjw can shed some more
> >> light), but as far as I'm aware, the Java StrictMath methods in GNU
> >> Classpath were written as exactly this: Java versions of the fdlibm
> >> code.  Developers of Java-based VMs such as JNode and JikesRVM
> >> preferred these, because they didn't have to incur the cost of
> >> dropping out to native code.
> >
> > Hi Andrew,
> >
> > I don't think we ever implemented this other than in the (never
> > released) Jamaica port of Jikes RVM. Chris Kirkham did that port of
> > fdlibm, perhaps he'd like to share the code :-)
> >
> > Ian
> > --
> > Metacircular JVM Research - http://mrp.codehaus.org/
> >
>
> At a naive glance, this:
>
>
> http://cvs.savannah.gnu.org/viewvc/classpath/java/lang/StrictMath.java?root=classpath&view=markup
>
> does seem to have the algorithms (at least <1.6) implemented in Java.
> It even credits fdlibm.


That code has room for some noticeable speedups, one is by refactoring
remPiOver2 to not need double[] y as param and do callers following logic
from within remPiOver2 instead.
Thats possible to do quite nice with overriding an enum method for each
usage case that is sent as a param instead of the double[] y.
RemPioOver2 then calls the return enum.dostuff(..) when its done and the
caller methods get their final result.
It saves the need for both the array allocation and the index of bound
checks for all its accesses, checks are still there with -XX:+AggressiveOpts
.
When i tested with b67 the current hotspot does not manage to remove that
object allocation by using cpu registers, even on 64 bit jvm with its many
registers available.
Also breaking up some very large methods into several smaller is a general
nice thing to do regarding both performance and OO design.

-- 
regards
 gustav trede
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090807/c0fca30f/attachment.html