Runtime & Compiler Flags

[Jeff]

Now on the seperate subject of autoboxing.

I agree that its dumb, its annoying, and I wish we could turn it off

A wise man said “never automate sharp objects”. Frankly I think autoboxing is one of these cases. You push the bar low enough that any idiot can write code that compilew and runs and what you get is idioicly written code.

We’ve already seen this happen with some of the Java netowrking stuff which made it so easy to write networked code that anyone could do it-- including those who had no idea of what they wree really doing. The result was a lot of very badly performing network applications.

I have similar though slightly different issues with generics and eventually I may blog on both o those subjects and annoy quite a few people…

[Jeff]

@zero

Meanwhile, I read an white paper about Excelsior’s JET Technology and I can’t wait to try the demo version, because it seems this JVM already performs all these optimization using partial evaluation. In favor of the SUN JVMs, one has to emphasize that they use Ahead-Of-Time compilation and therefore can use much more heavyweight/complex optimization techniques.

Flame bait.,

I’m not going to even rise to why this is nonsense.

Go try it, if it works for you then terrific.

The results of people arpound here have not born out
that it buys you anything beyond maybe a start-up time imrpovement and costs you in
other places such as code bloat. You can find a whole lot of discussion of this if you
search on “JET”.

But hey, use whatever works for you.

[Jeff]

@swpalmer

@zero

Sorry, I don’t see that magic:

…
The evalution graph is as simple is it can be, just a 3-Node Chain:

PrimtiveType -> WrapperClass -> PrimitiveType

and the algorithm to remove nodes (here the frist two) has only to check whether the expression evaluated to its parent ist constant. More precise, in order to make sure an expression doesn’t change:

1. step: test if the method depends on any variable
   1.1. if yes recursively start at 1. to evaluate these variables
   1.2. if no, make sure that both, the method and variable(s), are declared final an therefore cannot change
   1.2.1 if everything is final remove this expression (optimization)
   1.2.2. if not, heavy runtime analysis may needed to device if the expression can change or it might even not be possible in multi-threaded environments, but these cases should not occur using the basic wrapper classes

Nothing in the code you posted was declared ‘final’, though I doubt that will matter much - maybe the server compiler will do something with it.

The thing is as is pointed out above, this is a very trivial example. In “real” code ‘foo’ is likely to be called from many other places, some of which might actually need a Float class, not a float primitive.

To quantify what SWP is talkign about. consider this…

Map  floatmap = new HashMap();
map,put("MyFloat",1.0f);

.....  many routines later ....

System.out.println("MyFloat = "+((Float)floamap.get("MyFloat")).floatValue());

Clearly the float needs to be put in an obejct box. IF you have a brilliant way to somehow know, even given Java’s late binding, what primitive will actually be used as an object and need to be sued as an object without using the coercion inherent
in parameter types I suggest you (1) write an example compiler that dpes this (2) write your thesis on it and (3) send both to the manager of the Hotspot team along with your resume.

Tell you what, you do (1) and (2) and Ill get you the name for (3)!

Now a totally seperate issue are languages that dont HAVE primtiive types. Where everything is an object, including your primitives. Smalltalk works this way. There are some optimizations you cna do within the VM of such a system to reduce the penalties and store primtiives without needing the wrappers BUT Java is not one of those languages. We DO have true primitives. This allows us to do somethign Smalltalk never cpould-- approach C speeds.

The price is that they are seperate syntactical constructus and always will be. Autoboxing just allows sloppily written code that doesnt really care about the penalties of conversion to pretend that they aren’t. Its a coercion mechanism. Thats all.

[zero]

@Jeff

@zero

I personally think the mircobenchmarking issue is often used just as a lame excuse for the JVM

Then you dont know enough about either subject.

I’m sorry, Im really not trying to flame here, but that is a statement that illustrates fudnemental ignorance of the problem space.

please don’t take everything too seriously - didn’t noticed that smiley at the end ?

@Jeff

A have tested code like the mentioned expression templates in ‘real world’ application, more precise I exchanged the vertex skinning code in my character animation system to use dereffered evaluation and the JVM definately cannot handle these. The result is a huge drop in FPS.

sigh

Show me the exact code and I guess I will once AGAIN go throuygh the execercise of explainaing to you why you hurt yourself.

oh what a nice offer
you can find the extracted code here. The two different approaches can be found in the forjeff.VertexBlend class, more precisely the expresssion and the javaTran method. The algorithms are all based on expression templates article I mentioned before.
Unfortunately, I can’t upload the whole application due to licensing reasons:

1. I have no rights on the character (but if somone has a 3DSMAX 6 Model with physique or skin modifier attached I can use it with my exporter)
2. The final license isn’t decided yet. Since the extraction is suspected not to be part of the final applcaition I can simply put it under GPL, to show it here.
   Anyway, I believe it already consumes a serious amount of time to go through the extracted code.

@Jeff

Furthermore it a serious problem with microbenchmarks not beeing meaningful. They should, at least if the test starts after executing the code before for a given time and every computed results gets used afterwards (e.g. printing the sum). Otherwise it is a pain in the XXX to write performance cirtical code that does not depend on complexity.

The answer is well known.
Write clear, clean well encapsulated REAL code. Profile. Tune based on the profile.

That’s my point, going to a profilers output for everything comsumes much more time than performing a simple mricobenchmark. So if the later can’t be used, production time is rising. Furthermore isn’t it possible that code could be efficient in real scenario A but worse in real scenario B ?

@Jeff

Most likely either it wasnt sufficiently warmed up or you werent running server VM.

I used a warm-up phase about 5min. so if this isn’t sufficient than java games got a big problem with a low FPS the first 5min playing a FPS
I tested both client and server for comparison, but one thing I don’t undestand is that server was barely faster than the client VM - that’s why I asked for flags and that stuff…

finally the method I mentioned would only work with the generic way:

HasMap<String,Float> map = new HasMap<String,Float>();

since Float class is final s.th. like

HasMap<String,Float> map = new HasMap<String,? extends Float>();

cannot occur. (Bad exmaple I know, but I want to emphasize that you cannot put subclasses of Float into the map, which is important for the optimization).
Furthermore assuming that Float can be compared with a (const) float* since it is a reference type and these are like pointers (NullPointerException in Java ;)) and the map values are organized in an array style it would look like:

float** values; // dynamic array of float pointers

my argument was that because all that final/const stuff it could be replaced with

float* values; // dynamic array of floats

Unfortunatly I already got the topic for my my M.Sc Thesis, but a sample app without a parser and simplified expressions, left expressions and literals all annotated with the modifiers (final, public, …) should be enough to illustrate. Maybe I got time after my final exams on saturday.
(Ugh, that reminds I have to learn instead of having nice discusssions :()

[zero]

Stupid me

I got my error: Wrapper classes can be null, which prohibits replacing float** to float*. Some construct ‘NotNull’, like available in C# 2.0, would be needed to allow optimization under all circumstances. A solution would be Hashmap<String,NotNull>. (no flaiming please, since IMHO only providing anonumous methos instead of classes prohibits clean code - needless to say that the java implmenation is much more sophisticated since the accessed local variables have to be declared final, which make it more robust)

Summing up, although in the test situation I posted (frist code) and the math class for Jeff, this problem (null renderences) cannot occur since only float arrays are used and the wrapper class conversion occur only to allow generic interfaces. On the other hand with null beeing possible, this makes the optimization a special case, which probably is hard to implement by a JIT.

Sorry my fault.

[Jeff]

I’m glad you solved your problemm. A last comment or so…

@zero

That’s my point, going to a profilers output for everything comsumes much more time than performing a simple mricobenchmark. So if the later can’t be used, production time is rising.

False economy. You will waste far more time running and analyzing microbenchmarks on what turn out to be non-issues in your real code then firing up a profiler and profiling your app. Read Abrash’s Zen of Optimization. One of my favorite quotes of his…

“Premature optimization is the root of all evil.”

Maybe you havent tried a Java profiler, btw. Once ypou have the Netbeans profiler installed running it is as Ieasy as clicking the button next to the run button in the IDE. Running any of the other professional profilers (eg OptimizeIt) isnt any harder.

Furthermore isn’t it possible that code could be efficient in real scenario A but worse in real scenario B ?

Which, to reiterate, is why you profile your app, so you know what matters and why in your use case.