Alec Lee

Ranch Hand

Posts: 569

posted 7 years ago

Java's math methods do not use the built-in instructions in the CPU, and that's why they are generally (much) slower than when you use equivalent functions in for example C or C++.

Sun decided not to use the built-in CPU instructions, because they favour platform independence and accuracy above speed. There might be slight differences (different rounding behaviour, for example) between the square root instructions of different brands of CPUs. If Java would have used those instructions, then the result could have been slightly different on different platforms - which means it would have been a point where Java would give up platform independence.

That question is really impossible to answer, what do you mean with "other normal api call"? There are thousands of methods in the standard API and how long they take to execute varies wildly and depends a lot on what the call is supposed to do. It makes no sense to compare one specific method "api calls in general".

Sun decided not to use the built-in CPU instructions, because they favour platform independence and accuracy above speed. There might be slight differences (different rounding behaviour, for example) between the square root instructions of different brands of CPUs. If Java would have used those instructions, then the result could have been slightly different on different platforms - which means it would have been a point where Java would give up platform independence.

Alec Lee wrote:So how fast is Math.sqrt() compared to other normal api call?

That question is really impossible to answer, what do you mean with "other normal api call"? There are thousands of methods in the standard API and how long they take to execute varies wildly and depends a lot on what the call is supposed to do. It makes no sense to compare one specific method "api calls in general".

posted 7 years ago

Sorry to disagree so strongly with Jesper, but Math.sqrt(), along with many other methods in java.lang.Math, are explicitly defined

Now, anything you'll read about sqrt being a slow operation is only in the context of math; it is always slow compared to other math operations, all things being equal (even hardware-accelerated sqrt is slow compared to addition or multiplication.) But if you compare "Math.sqrt()" to, say, "JFrame.setVisible(true)", you'll find that it's a veritable speed demon!

*not*to produce bit-identical results across machines -- there's another class StrictMath which does provide that guarantee. Math.sqrt() by default forwards to StrictMath.sqrt(), which is a native method; that native method can either use a machine-specific instruction (if the platform has an IEEE compliant square root instruction) or implement IEEE math itself; so on some platforms, even StrictMath will be accelerated. Furthermore, the Math class can be (and is) special-cased in HotSpot, so that the forward to StrictMath can be removed and a non-IEEE compliant sqrt instruction can be used for that class.Now, anything you'll read about sqrt being a slow operation is only in the context of math; it is always slow compared to other math operations, all things being equal (even hardware-accelerated sqrt is slow compared to addition or multiplication.) But if you compare "Math.sqrt()" to, say, "JFrame.setVisible(true)", you'll find that it's a veritable speed demon!

posted 7 years ago

I've heard Dick Wall from The Java Posse complain a few times that methods like Math.sin() don't use CPU instructions but are implemented in software in Java, and therefore they are much slower than they could have been. But I don't know the fine details of it.

Charles Bradley

Ranch Hand

Posts: 32

posted 7 years ago

On a typical computer with hardware floating point operations, but no special square root instruction, a floating point square root can be computed in a few dozen machine instructions. The technique was developed in the mid 1960s so it should be in just about all math libraries by now. It uses the usual iterative method, with a cleverly chosen initial guess.