Mark, It's true.
My interpretation of Sun's documents: In the more recent versions of Java (1.4, 1.5, etc.), the runtime analysis in the -server option of Sun's Hotspot JVM is able to do several different types of optimization around "potentially final" and "mostly final" methods. The most recent versions have mostly eliminated the need to suggest optimization paths to the compiler via the "final" or "static" keywords. Additionally, there are cases where the way the polymorphic calls are actually dropped from an indirection (costly) to a Boolean test (cheapest operation on almost all processor types). It occurs when Hotspot notices the call favors one path over others, remaps the call from being an always deference/indirection to a direct call with a single Boolean test to shuttle off all non-critical-path calls to the slower dereference/indirection mechanism, and the primary call path executes with virtually no cost (a Boolean check is vastly less expensive than all the overhead of a polymorphic context transition). Add to this the fact that the register management of the Java call stack mechanism has been managed so that stack based (as opposed to heap based) optimizations can be utilized with higher effectiveness reduces even more time issues with heap memory fetches. Again, this is done during execution so that non-obvious (at least at compile time) stack use optimization can cross methods. In compiled only languages, this requires the programmer design it in explicitly. With Java, it just happens dynamically. (see caveat in PS) There is a cost for these optimizations. Some of the CPU is being burned in monitoring interpreted code to notice the patterns to optimize. And once an optimization is in place, if the class loader happens to load an additional class which impacts the optimized code path, the optimizations are backed out until the context can be monitored sufficiently for the critical code path to be re-optimized. It’s quite dynamic, and once produced, very effective speed-wise. This does not mean that any programmer can make Java work well. It still takes focusing on design level values, ones that are potentially much more effectively learned in languages like C++/C or assembly. Understanding the fundamentals is almost always an advantage as it enables one to design even more optimally in languages like Java. What I am enjoying is how much I can stay with my OO design principles, engage in only a moderate efficiency focus on less than 10% of my code base and end up with a screaming fast result. I won't say that it is guaranteed to outperform hand optimized C++/C. I am willing to say that the time it takes me to get the +95% as fast result is an order of magnitude smaller in Java than it was in my C++/C/assembly days. I am able to play with many more experiments in the saved time. It is a slight loss short term (not stuck in efficiency fixation local optima) for a huge long term gain (more effectively moving towards global optima, or at least significantly superior local optima-s). My experience tells me, at least with Java and Sun's approach to performance enhancement, staying with generally accepted OO design principles yields nice results immediately, and even better results as Sun continues to expand the number of optimizations that are only possible with on the spot run-time analysis. A compiler can only make educated (theory) guesses at the future execution profile of a code base. Some even use an execution profile log to assist in their engaging in further optimizations at compile time. Sun's approach augments really good guessing (theory) with up-to-date and in context direct observation (practice). This "mixed method" approach has proven to be significantly more performant and adaptive than the more traditional techniques of just compilation optimization. And given how competitive MS is (regardless of whether you like/dislike and/or agree/disagree with them), I expect .Net/C# to make similar leaps. And I expect that both Sun/Java and MS/.Net/C# will create an arms race that benefits all their users. Jim PS. It is somewhat difficult to talk about memory management between Java and C++/C because their memory models are different. ----- Original Message ---- From: Mark Boon <[EMAIL PROTECTED]> To: computer-go <computer-go@computer-go.org> Sent: Wednesday, November 29, 2006 9:22:14 AM Subject: Re: [computer-go] Making Java much faster On 29-nov-06, at 08:43, Stuart A. Yeates wrote: Other tricks for faster java include ensuring that, wherever possible, you use the final, static and private keywords. This enables the compiler to apply more compilation tricks in more places. More and more I find that using 'final' or 'static' to have no effect on speed at all. Most of the time the compiler figures out it can treat a method as final or static. I don't think I have found a case were explicitly putting it helped recently. Since the classes are loaded dynamically, I've always found this a bit of magic of the compiler. Somebody must have implemented something clever. Mark _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
_______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
