why Java Math slower than C Math?

[Tom Tromey]

>>>>> "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