Small micro benchmark for Java vs C++: howto?

Performance Tuning
#21

“Work well” is a value judgement, cas.

Java trig works VERY well for the original goals of java-- that the same code produce exactly the same out put on any system. This is very important to those apps that want consistency and accuracy over speed (eg the scientific apps that Java math was originally targeted at.)

What you want, a fast and sloppy trig, wasn’t the design spec.

There are some ways being talked about now inside of Sun about how to reduce the JNI over-head. No promises yet but if that happens then it’ll be reasonable for you to call a C function to do your fast trig…

#22

[quote]Actually that microbenchmark is a rather good one because it rather highlights a glaring performance deficiency in one small area.
[/quote]
Sure, which is why I say microbenchmarks are useful IF you understand what you are measuring and how it will relate to your actual app. They can also teach you things about whats going on in the VM that can be very useful IF you have the knowledge base to properly interpret them. (Which generally means familiarity with the intricacies of the VM in question and logic behind its design.)

But they rarely reflect real code so interpreted naively, which is what is almost always done, they tend to mean less thyen nothing and lead peopelo to improper conclusions.

Keep in mind one other factor, unless you are doing an incredibly simple program I gaurantee you you DON’T know what your bottlenecks will really be. Real code execution is far too complex for our puny minds to statically analyze effectively. So there’s no real good way to predict the relationship of that MB to your over-all code performance. This is why Profilers were invented.

#23

It’s all very well making a spec that mandates accurate trig but if 95% of the worlds processors do slightly less accurate trig that’s good enough for everyone else where’s the sense in it??? The Java spec ought to be amended to lower the accuracy to the Intel FPU.

…but hang on, isn’t this what all that strictfp stuff was about?

Cas :slight_smile:

#24

[quote]…but hang on, isn’t this what all that strictfp stuff was about?
[/quote]
Under strictfp calculations must at all times use only the precision and range of double (or float). Relaxed code is permitted to use the extended exponent range that intel processors can provide (but NOT the extended precision) using the 80 bit real form.

A related change was the addition of the StrictMath class which is currently defined to produce results identical to a specified math library (fdlibm). The spec for the Math class was then relaxed very slightly: “a larger error bound of 1 or 2 ulps is allowed for certain methods”. Unfortunately the trig operations on Intel processors substantially exceed this error limit for some input values (especially values near Math.PI).

I’m not in favour of further relaxing the spec for the Math class, but perhaps another class could be added with a deliberately insulting name like BadMath which offered no accuracy guarantees but did offer the prospect of speed. The mischievous name might discourage inappropriate use of the class.

#25

BadMath.PI == 3? :o

#26

[quote]BadMath.PI == 3? :o
[/quote]
Spoken like a true games developer…
;D

#27

[quote]I’m not in favour of further relaxing the spec for the Math class, but perhaps another class could be added with a deliberately insulting name like BadMath which offered no accuracy guarantees but did offer the prospect of speed. The mischievous name might discourage inappropriate use of the class.
[/quote]
This is a particular issue on some hardware platforms. I can’t name the one I’m thinking of because Im under NDA but it has a TON of floating point processors NONE of which meet Java spec :frowning:
The end result is that a Java app on that platform would be unable to use most of the platform’s power unless they down coded all their math to C :frowning: :frowning: :frowning:

Its possible that silicon is getting so dense and so cheap that this wont be a problem in the next generation, but I’m not willing to bet on gate-counting in consumer devices stopping any time soon.

So yes i think a “BadMath” or perhaps more appropriately named “PlatformMath” would be a good addition for some environments.
it needs to be more then just a class though, it has to recognized and supported in the code generator. You really don’t want math primitives treated as method calls, even inlined ones, unless your inliner is so good that it literally makes no difference.

#28

Wouldn’t a BadMath VM Option make more sense than a BadMath class since you’re not going to know whether you need it or not until after you’ve written the code?

#29

No, I’d argue against that. That would violate a primary promise of the VM, that the same code produce the same output for portability purposes.

We’re already bending that by saying “this code doesnt HAVE to produce the same output on all platforms” but that should be a documented limit of the code, ergo it should be in the code itself.

#30

Someone asked for “Macro benchmarks”. That sort of depends on your goals.

For your code, the macro benchmark IS your code, or major units thereof.

For libraries, the macro benchmark is typical consumers and varies from library to library.

For instance, to get Java2D tuned to run GUI apps well we took a bunch of then current Java applications and metered them.

We also knew that we had to support a whole lot of swing ontop of us so we wrote a little harness that brought up a swing gui and “bashed” on it with events. It wasn’t really like a user, but it was more like a user then a microbenchmark that draws 1000 blue lines in a row, which is what the first suite had looked like.

#31

[quote]Wouldn’t a BadMath VM Option make more sense than a BadMath class since you’re not going to know whether you need it or not until after you’ve written the code?
[/quote]
No because the programmer has to take responsibility for writing code that will tolerate less accurate results. They may also have some code which while not performance critical requires the full accuracy promise of Math or even StrictMath.