<br><br><div class="gmail_quote">2009/8/7 Andrew John Hughes <span dir="ltr">&lt;<a href="mailto:gnu_andrew@member.fsf.org">gnu_andrew@member.fsf.org</a>&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2009/8/7 Ian Rogers &lt;<a href="mailto:ian.rogers@manchester.ac.uk">ian.rogers@manchester.ac.uk</a>&gt;:<br>
<div><div></div><div class="h5">&gt; 2009/8/6 Andrew John Hughes &lt;<a href="mailto:gnu_andrew@member.fsf.org">gnu_andrew@member.fsf.org</a>&gt;:<br>
&gt;&gt; 2009/8/6 Joseph D. Darcy &lt;<a href="mailto:Joe.Darcy@sun.com">Joe.Darcy@sun.com</a>&gt;:<br>
&gt;&gt;&gt; My preferred long-term approach is to port the FDLIBM C code to Java, which<br>
&gt;&gt;&gt; I&#39;ve wanted to do for a while, but has never bubbled to the top of my to-do<br>
&gt;&gt;&gt; list.<br>
&gt;&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; I don&#39;t know the full history of it (perhaps mjw can shed some more<br>
&gt;&gt; light), but as far as I&#39;m aware, the Java StrictMath methods in GNU<br>
&gt;&gt; Classpath were written as exactly this: Java versions of the fdlibm<br>
&gt;&gt; code.  Developers of Java-based VMs such as JNode and JikesRVM<br>
&gt;&gt; preferred these, because they didn&#39;t have to incur the cost of<br>
&gt;&gt; dropping out to native code.<br>
&gt;<br>
&gt; Hi Andrew,<br>
&gt;<br>
&gt; I don&#39;t think we ever implemented this other than in the (never<br>
&gt; released) Jamaica port of Jikes RVM. Chris Kirkham did that port of<br>
&gt; fdlibm, perhaps he&#39;d like to share the code :-)<br>
&gt;<br>
&gt; Ian<br>
&gt; --<br>
&gt; Metacircular JVM Research - <a href="http://mrp.codehaus.org/" target="_blank">http://mrp.codehaus.org/</a><br>
&gt;<br>
<br>
</div></div>At a naive glance, this:<br>
<br>
<a href="http://cvs.savannah.gnu.org/viewvc/classpath/java/lang/StrictMath.java?root=classpath&amp;view=markup" target="_blank">http://cvs.savannah.gnu.org/viewvc/classpath/java/lang/StrictMath.java?root=classpath&amp;view=markup</a><br>

<br>
does seem to have the algorithms (at least &lt;1.6) implemented in Java.<br>
It even credits fdlibm.</blockquote><div><br>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.<br>
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. <br>RemPioOver2 then calls the return enum.dostuff(..) when its done and the caller methods get their final result.<br>
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 .<br>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.<br>
Also breaking up some very large methods into several smaller is a general nice thing to do regarding both performance and OO design.<br></div></div><br>-- <br>regards<br>  gustav trede<br><br><br>