Solved

Trigonometrical bad performance with j2sdk 1.4

Posted on 2004-09-17
5
192 Views
Last Modified: 2010-03-31
I have read this benchmark results  -- http://osnews.com/img/5602/results.jpg  --  and java 1.4 performance is very bad in trigonometrical operations , and worse is that 1.4 is slower than JAVA 1.3 (in this topic specially).

Is it possible that the program developed for running the benchmark don`t use appropiate programming techniques for JAVA 1.4 or something like that, because it`s neither logical nor clear that a new version o JAVA be slower than 1.3.

Source of the benchmark could be found in  --   http://www.ocf.berkeley.edu/~cowell/research/benchmark/code/   --

Thanks a lot for you all !!

Regards from Colombia !
0
Comment
Question by:diordonez
  • 4
5 Comments
 
LVL 35

Expert Comment

by:TimYates
ID: 12085591
In 1.4, the java Trig functions became implemented in Java, so yes, they are slower.
0
 
LVL 35

Accepted Solution

by:
TimYates earned 250 total points
ID: 12085664
From:  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4857011
-----------

A DESCRIPTION OF THE REQUEST :
My numeric calculation intensive program runs 8 times slower with 1.4 as opposed to 1.3.1. I am doing Math.sin(), Math.cos(), and Math.sqrt(). I realize that you made StrictMath the default math library--is there a way to run the faster 1.3.1 math routines?

...SNIP...

We are aware of the issue raised by this bug; it is the same issue
raised in 4807358, the "almabench" bug.  Both this bug and 4807358 are
symptoms of the same problem: the sin/cos routines in the client
compiler under 1.3.1 did *not* comply with the Math.{sin/cos}
specification.  As explained below, the way they did not comply could
be the source of a large amount of error.  As a consequence of fixing
this compliance problem (bug 4345903), the x86 sin/cos routines in 1.4
and later are slower than in 1.3.1 client.

The x87 FPU has fsin and fcos instructions to accelerate the
computation of sine and cosine.  However, these instructions have a
number of limitations. First, they only return sensible results over a
limited range of values, +/- 2^63.  Java's sin/cos functions are defined
over the full double range, roughly +/- 2^1023.  Second, even within
the +/-2^63 range, nearly all fsin/fcos implementations perform faulty
*argument reduction,* consequently, the results can be very wrong
outside of a narrow range of +/- pi/4.

The way many math libraries routines work is to map any argument into
an "equivalent" argument in a fixed, narrow range; this process is
called argument reduction.  Since sine and cosine are periodic, the
basic idea behind the mapping is clear; subtract out multiples of
2*pi.  The actual details are a little more sophisticated; in the case
of sin/cos, arguments are mapped into [-pi/4, pi/4] using sign
symmetries between sin/cos (for a good current reference on such
matters see Jean-Michel Muller's book "Elementary Functions").

The number pi is transcendental; it has no finite binary
representation.  Around 1982 several years after the original x87
design, techniques for doing argument reduction as if by an exact
value of pi were developed (see http://www.validlab.com/arg.pdf for a
discussion of the techniques).  The fsin/fcos instructions use an
older technique: pretend pi has a fixed number of bits; most x87
implementations use a 66-bit approximation of pi for argument
reduction.  If the sine/cosine functions are viewed a spring, using a
limited precision approximation to pi amounts to slightly compressing
the spring.  Even for moderately large arguments, the difference
between the compressed and uncompressed versions of sin/cosine can be
very, very large, affecting even the sign of the result.

People are often unnerved when they discover that 1.0/10.0 cannot be
exactly represented as a binary floating-point number.  The exact
value of the floating-point result of dividing 1 by 10 is

0.1000000000000000055511151231...

which is accurate to 17 decimal places.  In floating-point parlance,
this is accurate to 1/2 ulp (unit in the last place), which is the
most one can ask from a single floating-point operation.

The value of sine for the floating-point number Math.PI is around

1.2246467991473532E-16

while the computed value for the algorithm used in java 1.3.1 is

1.2246063538223773E-16
      ^

In other words, the returned result is only accurate to about 5 digits
instead of the full 15-17 digit precision of double. Instead of a 1/2
ulp or 1 ulp error, the error is about 1.64e11 ulps, over *ten
billion* ulps.

Does this magnitude of error matter to your application?  It might, or
it might not.  However, in case it does matter, the Java specification
requires an accurate answer be returned.  If you don't care what is
returned, why do you care how fast it is returned?  Rhetorically, sin
could always return 0 and cos could always return 1; they would be
very fast but not too useful as sine and cosine functions.  (Neither
the almabench code nor the code submitted in this bug actually examine
the results to verify they are sensible.)

On a related note, the sine and cosine of large values, even as large
as Double.MAX_VALUE, are perfectly well-defined mathematically.  There
is no mathematical justification for returning arbitrary sin/cos
results for large values.

In 1.4, an effort was made to take advantage of the fsin/fcos hardware
as much as we could and still meet the spec.  However, "large"
arguments outside of around pi/4 require a separate argument reduction
step, which can be the bulk of the cost.

Closing as not a bug.
0
 
LVL 35

Expert Comment

by:TimYates
ID: 12085682
So, use lookup tables wherever possible if performance becomes an issue...
0
 

Author Comment

by:diordonez
ID: 12129103
Thanks for your complete and very clear explanation !
0
 
LVL 35

Expert Comment

by:TimYates
ID: 12150321
>  Thanks for your complete and very clear explanation !

Hehe..."B" grade then? ;-)

Good luck with it!

Tim
0

Featured Post

Is Your Active Directory as Secure as You Think?

More than 75% of all records are compromised because of the loss or theft of a privileged credential. Experts have been exploring Active Directory infrastructure to identify key threats and establish best practices for keeping data safe. Attend this month’s webinar to learn more.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Title # Comments Views Activity
eclipse package explorer vs project explorer view 2 84
starter POM and spring-boot-starter,  spring-boot-web 2 43
stackato and cloud 4 72
factorial example 4 35
For customizing the look of your lightweight component and making it look lucid like it was made of glass. Or: how to make your component more Apple-ish ;) This tip assumes your component to be of rectangular shape and completely opaque. (COD…
After being asked a question last year, I went into one of my moods where I did some research and code just for the fun and learning of it all.  Subsequently, from this journey, I put together this article on "Range Searching Using Visual Basic.NET …
Viewers will learn about arithmetic and Boolean expressions in Java and the logical operators used to create Boolean expressions. We will cover the symbols used for arithmetic expressions and define each logical operator and how to use them in Boole…
This tutorial will introduce the viewer to VisualVM for the Java platform application. This video explains an example program and covers the Overview, Monitor, and Heap Dump tabs.

920 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

16 Experts available now in Live!

Get 1:1 Help Now