why Java Math slower than C Math?

Tue Feb 25 20:29:00 GMT 2003

>>>>> "Manfred" == Manfred Bergmann <mdbergmann@t-online.de> writes:

Manfred> Ok, but the bounds-check is not to blame for the lower
Manfred> performance. I got another example: a loop where all short
Manfred> values in an array are casted to float and stored in a float
Manfred> array. Here Java is nearly factor 10 faster than C/C++,
Manfred> optimzed or unoptimized doesn't matter.
I'm very surprised by this result.
Tom> A few methods in java.lang.Math are treated as builtins at -O1 and
Tom> greater. Currently these are min, max, abs, cos, sin, and sqrt. We
Tom> might be able to add more, but I haven't really kept up with that
Tom> area.
Manfred> What does "builtin" mean? No function call is needed, so no
Manfred> assembler jump instruction? Istn't that similar to how
Manfred> inline function behave?
A "builtin" is a function that gcc has particular internal knowledge
of. For instance, for the `max' function, gcc knows its semantics and
will inline it into efficient code.
It is different from an inline function in a way. With an inline
function, gcc reads the body of the function from the program its is
compiling. With a builtin, the body of the function is determined by
gcc.
In our case this makes a big difference. The Math functions are
written in C++, and we can't inline a C++ function into a Java
function (since the Java compiler can't read the C++ code).
I think some builtin functions, like `sin', may be compiled to a
single assembly instruction on some platforms. I've never delved into
the details. You could look at the assembly output to see though.
Tom