All it takes is one vote. Make it yours. Login and vote now.
By Volume4
via adam-bien.com
Published: Dec 09 2007 / 19:04
"Java is slow, interpreted language." This statement was true at least in the very first years (or months) of Java. Since JDK 1.3/1.4 the peformance is getting better and better. The newest JVMs becomes even more efficient, than C. The c-compiler is static, so once compiled code cannot be optimized any more. The HotSpot is able to perform optimization on the fly, but the optimizations are based on statistics, which are not available at compile-time. Now the conclusion: because HotSpot is written in C itself, it cannot be so fast as Java :-). Beyond that C is not very good to maintain. This is basically the idea of the research project maxwell (actually a cool name). James Gosling mentioned this project during the informal interview at the Sun Tech Days in Frankfurt, and said something like: "it begins to turnaround". It's really an interesting idea - a short (21 pages) description is available as well.
Comments
dzonelurker replied ago:
Java faster than C? Don't take me for a fool.
sigzero replied ago:
Actually in some benchmarks it is. Why is that so hard to believe?
Nick Brown replied ago:
Great, I'll remember that next time I have to run a particular benchmark as fast as I can. Unfortunately, when most people claim about their code being too slow they are talking about in the context of a real life application, where all evidence points to Java as being slower.
Nick Brown replied ago:
Oh, and of course it goes without saying, the performance will depend greatly on how well the code is written. Most of the "Java is faster" benchmarks I've seen are comparing Java against poorly written C code.
amalter replied ago:
I think a much more accurate statement would be Java is often as fast or faster than C++. This seems to hold up for both benchmarks and real world situations. Pure C is almost always faster unless you are in a lab perfect runtime JIT situation.
willcode4beer replied ago:
Like all things, it depends.
The point in the article was about runtime optimization. There are a certain class of programs where runtime optimization will allow them to run faster than before.
With JIT compilation, java is converted to native code, so, at this level, it could theoretically be as fast as any normal compile to native language (C/C++/Fortran/whatever). By performing runtime analysis other optimizations can be applied to the native code, allowing it to run even faster. I'm not sure sure of the benefit of doing this in the JVM itself. Seems like it might be better to analyze it and apply the optimizations directly. There have been a few projects before for JVMs written in Java, they never seem to get anywhere. I think IBM has one in alphaWorks.
Benchmarks suck at this kind of thing because the benefits of runtime optimization tend to be better exploited on long running applications, like servers.
What would be nice would be to have a system where you could save (and share) the results of runtime analysis so that if you could get the benefits at JIT time when restarting a server, or adding a new server to a cluster.
tmnelson replied ago:
ISTR that Intel or HP had a C compiler system that would take data collected during profiling runs as an input file, and use that for guidance during the compile. I don't remember if it was just a research prototype or whether it ever became useful (this would have been back in the mid-80s, when C was the language of choice for most new development). There was also talk about "re-compilers" that would take execution traces and tweak the actual executable, but I'm guessing they never panned out either.
Voters For This Link (24)
Voters Against This Link (3)