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 !

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 !

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.

-----------

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

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.