Re: why Java Math slower than C Math?

[mdbergmann at t-online dot de (Manfred Bergmann)]

Tom Tromey wrote:

> > > > > > "Manfred" == Manfred Bergmann <bergmannmd at web dot de> writes:
> > > > > >            
>
> Manfred> I am doing some performance tests between C/C++ and Java.  An
> Manfred> algorithm performs on a lot of float elements in an array
> Manfred> where quite often math-functions (abs, min, max) are called.
>
> First, java does bounds checking of array accesses.  gcj curently
> doesn't try to eliminate bounds checks, so this adds overhead.
> You can compile with -fno-bounds-check to disable this, though in that
> case a bounds violation will cause unpredictable behavior.
Ok, but the bounds-check is not to blame for the lower performance. I 
got another example:
a loop where all short values in an array are casted to float and stored 
in a float array.
Here Java is nearly factor 10 faster than C/C++, optimzed or unoptimized 
doesn't matter.

> Manfred> On the same code-base, Java performs unoptimized slower than C.
> Manfred> With -O3 optimization both have nearly the same performance.
> Manfred> AFAIK, all java.lang.Math methods are declared static, does this
> Manfred> mean, that they are made to inline-funktions with a -O3 optimization
> Manfred> and with that Java is as fast as C?
>
> A few methods in java.lang.Math are treated as builtins at -O1 and
> greater.  Currently these are min, max, abs, cos, sin, and sqrt.  We
> might be able to add more, but I haven't really kept up with that
> area.
What does "builtin" mean? No function call is needed, so no assembler 
jump instruction?
Istn't that similar to how inline function behave?


Thx, for help,
Manfred