Al Chou wrote:
Before we go too far down this path, it would be very helpful to know just how much performance penalty is incurred by specifying strictfp. That FAQ certainly suggests that the difference is large and undesirable, but like profiling, you never really know what it is until you actually measure it....
Suggestion: conduct an informal timing test of a few representative functions, say, some of the transcendental functions in java.lang.Math, with and without strictfp. A loop doing 100,000 of these method calls should be sufficient to have runtime lasting several seconds to several minutes depending on the operation. Run it at least three times to get an idea of the mean runtime and standard deviation.
The tough part is that I think all the java.lang.Math functions already are "strict" in that they simply call their strict counterparts in java.lang.StrictMath.
I've read some harsh statements from allot of game developers concerning Java's neglecting to use floating point coprocessors for certain trig calculations, instead using software approaches in the native math implementation that utilize strictfp. Their point was outside the scope of our discussion, (yet clarifies the need for a JVM option). Error in calculations is unimportant in 3D gaming, performance is.
But I'm digressing, my point is that I ripped open the source and found out both StrictMath and Math are defined strictfp.
public final strictfp class StrictMath {
public final strictfp class Math {-Mark
-- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
