Math trig intrinsics and compiler options

[Andrew John Hughes]

2009/8/7 gustav trede <gustav.trede at gmail.com>:
>
>
> 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.

Nice; remember that there were no enums when this was written... :)

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



-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8