Re: java.lang.StrictMath
> "Per" == Per Bothner <[EMAIL PROTECTED]> writes:
Per> For JDK, or other system with a good JIT, it is probably faster
Per> to use Java code.
If the Java code is restricted enough then I think gcj will be as good
as C.
For best performance I think the code would have to:
* Not make static or final ("nonvirtual") method calls
(These induce overhead relative to C++)
* Not use arrays
(C++ does check bounds)
* Not "look like" it might throw an exception (this prevents
reordering code)
There may be other restrictions that I can't think of. These are
pretty restrictive, but the Math code might satisfy them. I haven't
looked.
Tom
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: java.lang.StrictMath
Tom Tromey wrote: >>"Eric" == Eric Blake <[EMAIL PROTECTED]> writes: >> > >Eric> StrictMath is required to be implemented in pure Java > >How curious. >BTW, fdlibm is fine to use. We already use it in libgcj. > >Thanks for doing this. Now all we have to do is implement strictfp in >gcj :-) > Do you have any examples of how GCC is *not* strictfp compliant (at least on common platforms)? My understanding is that, by default, it tries to be strictly IEEE 754. On x86 it will store values to memory and make a function call to do FP arithmetic, unless -ffast-math is given which allows it to do inline math using (the 80-bit x87) FP registers. So, unless I misunderstand something and there is more to it, we should make -ffast-math the default for Java except where strictfp is encountered. regards Bryce ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.lang.StrictMath
Eric Blake wrote: > But maybe it > is worth it after all for StrictMath to have native implementations, Note I am not saying that StrictMath should have native implementations, only that it *may*, *if* the results are the same. > Is the overhead of calling a native method offset by the > speed of doing this number crunching without going through bytecode? It depends. For GCJ, there is no overhead for calling a native method, beyond the normal method calling overhead, which is the same as in C++. (For virtual calls. Interface calls are a different matter.) For JDK, or other system with a good JIT, it is probably faster to use Java code. -- --Per Bothner [EMAIL PROTECTED] http://www.bothner.com/per/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.lang.StrictMath
Hmm, maybe you are right. On second reading, Sun specifies the following in StrictMath: "To help ensure portability of Java programs, the definitions of many of the numeric functions in this package require that they produce the same results as certain published algorithms These algorithms, which are written in the C programming language, are then to be understood as executed with all floating-point operations following the rules of Java floating-point arithmetic." Then, in Math, they state: "By default many of the Math methods simply call the equivalent method in StrictMath for their implementation. Code generators are encouraged to use platform-specific native libraries or microprocessor instructions, where available, to provide higher-performance implementations of Math methods. Such higher-performance implementations still must conform to the specification for Math." I had interpreted it to mean that Math may be native, but StrictMath should be pure. Besides, the less native code there is, the less maintainance problems and more portable Classpath becomes. But maybe it is worth it after all for StrictMath to have native implementations, provided such implementations match the ones I just submitted in the Java language. Is the overhead of calling a native method offset by the speed of doing this number crunching without going through bytecode? Per Bothner wrote: > > Eric Blake wrote: > > StrictMath is required to be implemented in pure Java, not > > in native code; > > Where is this peculiar requirement stated? No proper > specification would make any such requirement (not to > suggest that Java has a proper specification) - most > standards have an "as-if" rule: The implementation must > behave *as if* it used the specified algorithm or code, > but as long as no valid program can tell the difference, > the implementation is free to use some other algorithm. > -- > --Per Bothner > [EMAIL PROTECTED] http://www.bothner.com/per/ -- This signature intentionally left boring. Eric Blake [EMAIL PROTECTED] BYU student, free software programmer ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.lang.StrictMath
> "Eric" == Eric Blake <[EMAIL PROTECTED]> writes: Eric> StrictMath is required to be implemented in pure Java How curious. BTW, fdlibm is fine to use. We already use it in libgcj. Thanks for doing this. Now all we have to do is implement strictfp in gcj :-) Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.lang.StrictMath
Eric Blake wrote: > StrictMath is required to be implemented in pure Java, not > in native code; Where is this peculiar requirement stated? No proper specification would make any such requirement (not to suggest that Java has a proper specification) - most standards have an "as-if" rule: The implementation must behave *as if* it used the specified algorithm or code, but as long as no valid program can tell the difference, the implementation is free to use some other algorithm. -- --Per Bothner [EMAIL PROTECTED] http://www.bothner.com/per/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.lang.StrictMath
Eric Blake wrote: >OK to commit? If it weren't for this little section of StrictMath.java, >I would have committed without asking. But since it involves copyright >issues, I want to make sure. I don't think I tainted myself, since the >copyright notice of fdlibm (the source for my algorithms) does say it is >freely usable. > This is very cool! Thanks for doing this. Please consider it pre-approved for libgcj as well. regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.lang.StrictMath
Brian Jones wrote: > > I think it is fine. I noticed this odd little class in the 1.3 > javadocs a couple of months ago and it says explicitly that it uses > fdlibm, of course it says that in contrast to what it used elsewhere > (pure Java, whee...). The javadocs state that the class StrictMath must have bit-identical results to the fdlibm library, after translating the C algorithms to Java types. StrictMath is required to be implemented in pure Java, not in native code; it is only Math which permits you to use native code (and inline things like cos() and sin()). At any rate, I went ahead and committed the new file. -- This signature intentionally left boring. Eric Blake [EMAIL PROTECTED] BYU student, free software programmer ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
java.lang.StrictMath
OK to commit? If it weren't for this little section of StrictMath.java,
I would have committed without asking. But since it involves copyright
issues, I want to make sure. I don't think I tainted myself, since the
copyright notice of fdlibm (the source for my algorithms) does say it is
freely usable.
By the way, converting arcane C to Java is not an exercise for the
weak-minded :)
/*
* Some of the algorithms in this class are in the public domain, as
part
* of fdlibm (freely-distributable math library), available at
* http://www.netlib.org/fdlibm/, and carry the following copyright:
*
* Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved.
*
* Developed at SunSoft, a Sun Microsystems, Inc. business.
* Permission to use, copy, modify, and distribute this
* software is freely granted, provided that this notice
* is preserved.
*
*/
--
This signature intentionally left boring.
Eric Blake [EMAIL PROTECTED]
BYU student, free software programmer
2002-02-14 Eric Blake <[EMAIL PROTECTED]>
* java/lang/Makefile.am: Add StrictMath.java.
* java/lang/StrictMath.java: New file.
* java/lang/Math.java: Formatting and comments (no functional
changes).
Index: java/lang/Makefile.am
===
RCS file: /cvsroot/classpath/classpath/java/lang/Makefile.am,v
retrieving revision 1.9
diff -u -r1.9 Makefile.am
--- java/lang/Makefile.am 7 Feb 2002 17:43:00 - 1.9
+++ java/lang/Makefile.am 14 Feb 2002 20:44:20 -
@@ -62,6 +62,7 @@
SecurityManager.java \
Short.java \
StackOverflowError.java \
+StrictMath.java \
StringBuffer.java \
StringIndexOutOfBoundsException.java \
String.java \
Index: java/lang/Math.java
===
RCS file: /cvsroot/classpath/classpath/java/lang/Math.java,v
retrieving revision 1.10
diff -u -r1.10 Math.java
--- java/lang/Math.java 22 Jan 2002 22:27:00 - 1.10
+++ java/lang/Math.java 14 Feb 2002 20:44:20 -
@@ -1,5 +1,5 @@
-/* java.lang.Math
- Copyright (C) 1998, 2001 Free Software Foundation, Inc.
+/* java.lang.Math -- common mathematical functions, native allowed
+ Copyright (C) 1998, 2001, 2002 Free Software Foundation, Inc.
This file is part of GNU Classpath.
@@ -7,7 +7,7 @@
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version.
-
+
GNU Classpath is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
@@ -58,7 +58,7 @@
/**
* Math is non-instantiable
*/
- private Math ()
+ private Math()
{
}
@@ -66,25 +66,30 @@
{
if (Configuration.INIT_LOAD_LIBRARY)
{
- System.loadLibrary ("javalang");
+ System.loadLibrary("javalang");
}
}
- static Random rand;
+ /**
+ * A random number generator, initialized on first use.
+ */
+ private static Random rand;
/**
- * The mathematical constant e.
- * Used in natural log and exp.
+ * The most accurate approximation to the mathematical constant e:
+ * 2.718281828459045. Used in natural log and exp.
+ *
* @see #log(double)
* @see #exp(double)
*/
- public static final double E = 2.7182818284590452354;
+ public static final double E = 2.718281828459045;
/**
- * The mathematical constant pi.
- * This is the ratio of a circle's diameter to its circumference.
+ * The most accurate approximation to the mathematical constant pi:
+ * 3.141592653589793. This is the ratio of a circle's diameter
+ * to its circumference.
*/
- public static final double PI = 3.14159265358979323846;
+ public static final double PI = 3.141592653589793;
/**
* Take the absolute value of the argument.
@@ -96,13 +101,13 @@
* a computer, MIN_VALUE is what will be returned.
* This is a negative value. You have been warned.
*
- * @param a the number to take the absolute value of.
- * @return the absolute value.
- * @see java.lang.Integer#MIN_VALUE
+ * @param i the number to take the absolute value of
+ * @return the absolute value
+ * @see Integer#MIN_VALUE
*/
- public static int abs (int a)
+ public static int abs(int i)
{
-return (a < 0) ? -a : a;
+return (i < 0) ? -i : i;
}
/**
@@ -115,73 +120,80 @@
* a computer, MIN_VALUE is what will be returned.
* This is a negative value. You have been warned.
*
- * @param a the number to take the absolute value of.
- * @return the absolute value.
- * @see java.lang.Long#MIN_VALUE
+ * @param l the number to take the absolute value of
+ * @return the absolute value
+ * @see Long#MIN_VALUE
*/
- public stati
