Keith Devens .com

With all due respect to Matt2000

I disagree, and would bet the farm otherwise.

Having lived in both worlds for the past 23 years, I would have to say that if the programmer knows what he is doing, his compiled native code can and will run about 5-10 times faster than it step-brothers.

That being said, there are just some things I do not care about performance and I just care that they get coded fast. Those I trust to Java and Perl -- and to some extent PHP and .net.

Some of my work over the past four years has been rewriting optimized java code (I should say heavily optimized java code) into C and C++. Now let me say for the record, that taking advantage of OO - anything will slow down performance -- from a nudge to an ungodlike amount. But, as someone who sees that either the program must perform well, or you have to buy a server which will cost you an additional $300,000 dollars, the cost of porting optimized to native code optimized is well worth it.

Now if one of my employers were to ask me that the next project will run faster if I rewrote it, I could not say outright, it would. Some of the java libraries are very very good, and perl's ability to extract is very very close to optimal at times. So the improvement will be very slim in those cases. But--you may need to take my word on this -- if you have half a billion data points flowing from a sensor and need to do some numerical analysis realtime. You do not reach for the java or perl handbook. You do not even think about it.

I do not know what algorithm they ported from C++ to java. But I would like to see it if had anything to do with image manipulation or large matrix interpolation.

I guess I would agree with Matt in the case of your average joe developer. He does not have the time or the inclination to understand how the compiler works, or if taking a full blown OO approach makes sense given the task at hand and the life cycle of the project.

I'm mainly interested in learning about the types of analysis a JIT compiler can do that static analysis can't. And I've always been extremely skeptical of any Java speed claims.

Keith,

Well performance aside, the JIT can do just about the same thing. Performance and stability are the primary issues when picking JIT language.
In a traditional static native code compile model -- there are two primary dependancies: The Operating system, and the firmware.
In the JIT model, your code is sent to / used in a JIT which can change versions in a much more frequent and uncontrollable manner. Sometimes for good -- the libraries are improved upon. Sometimes for evil -- the libraries have been replaced by something which is not completely compatible.
One thing I do like about the client side JIT is that code can be deployed there pretty quick.

Ultimately, it comes down to this: Statically compiled programs rely on the developer to know much more about how things work. His libraries / APIs are not updated as often as those Java / JIT ones. So if he is doing something special -- he has to be on top of it -- update it himself, make his own libraries if the ones out there are not fast enough for him. This (in my experience) does not happen with the Java developers or those utilizing the JIT. It really has changed over the past four years. Now many who want to use statically compiled languages are software engineers not programmers. This is really due in part to the Microsoft dot net push in which everything and every language can compile down to code in which the JIT can run. The development community is be spoiled by this to some extent. But again, ultimately they are getting what they want -- a solution.