You're absoluely right that therr are library problems. Alot of them have to do with implementation details, which are being worked on. (Anoyone whose tried Swing under JDK1.2 v. the 1.3 thats currently out has seen the results, and there are better thinsg still in the works.)
A few of them have to do with the nature of the libraries as very high-level, idiot proof things. Lower level facillities are gradually appearign in java. I've been playing with java for games myself, and as part of that I've written JNI to talk to DX directly. Doing that, Java easily flips frames at the limit of my video-synch (70hz) on my PC.
There are a few key things missing from Java for real ultra-high performance stuff. A number of these are being added... I can't say much more now but I'll gladly post abotu them when they are public. (Actually, when one of them is public, I'll be able to finish and post my DirectJava library, which I intend to make open-source.)
Now I hate to disagree with someone whose on the same philisophical side... but I need to disagree with you on bounds checking. Unless you know of some approach I don't, AFAIK there is no way to eliminate it from random-access reading and writing of arrays.
What you mentioned about loops is called "hoisting" and yes this is happeneing, but an array implementation of a stack, for instance, must still check every access to make sure its within the memory area of the array proper. We have to be careful not over-sell hoisting and lead people the wrong way in their programming.
>I suggest you actually do some experiments >yourself. Java and C++ are close enough that >it's quite easy to compile virtually identical >code in both
Your premise is compeltely off. To restate the above: "Java shouls run code tuned for C++ as fast as C++."
Thats nonsense. Many of the things we do in C++ to encourage it to perform HURT Java performance, and vice versa. Just taking a piece of C++ code and recompiling it is gaurranteed to have lousy results... and taking peice of well tuned Java code and simply recompiling it in C++ will have EQUALLY bad results.
Just a few sample issues: (1) Arrays
In C/C++, arrays are used extensively in high prformance programming. When one wants to speed up a recursive routine, one re-writes the routine with a lcoal arrwy asbed stack.
In Java, array access incurrs bounds check penalties. It is FASTER in tegh latest generation of VMs to recurse then build a lcoal stack.
(2) Virtual methods In high performance C++ one must code to avoid virtual methods because they cannot be inlined. In Java it is good practice TO use virtual methods (a non-virtual in Java is a final) because the latest VMs are very sophsiticated in determining for themselves if something is in-linable.
In general java today is MUCH better at in-lining then ANY C++ compiler.
(3) Tuning Time
It is at this point I believe an undisputed fact that a Java coder can write correct code faster then a C++ coder. (My own experience, and that of it seems many others, has been about an order of magnitude difference in speed.) In the REAL world, time is limited. Faster coding means more time to tune, therefor for the same period of time coding, an equally proficient Java coder will produce a better tuned application.
These, and many other factors, are totally absent from your "test".
The sad thing is, if you had been prgoramming C++ as long as I have, this would all sound familiar. These exact same dispersions were cast on C++ when it arrived on the scene. People had to learn how to use the tool before it payed off. Really learn Java, then make your comparisons.
I've now seen a bunch of real-world benchmarks that more or less explain what everyone has seen. They're internal numbers that I can't release, but in general...
The 800: 6200 (approx 8x difference) v. jdk1.2 seems reasonable on purely computational things. This confused me until I remembered that Linux is the one place where the jdk1.2 ISN'T hotspot. This is a classic v. much more modern VM comparison. Hotspot can be expected to perform similarly when released on Linux.
The varying GUI numbers are explained by the fact that it performas somehwt differently on different GUI tasks. A few its very good at now, some it still needs some work on.
In general, on Linux IBM 1.1.8 is still beating JDK1.2.2 and IBM 1.3 respectably in most GUI things. IBM 1.3 is kicking repectable rear in non-gui tasks.
Others have already reported some scaling issues with 1.3 I don't have tests for those.
It's been mentioend a few tiems. (Okay its been mentioned a few times by me, and once or twice by others;) ) That niether Volano or Caffine are terribly realistic benchkmarks. I've suggested SPEC a few times. Here's where to get it: http://www.spec.org/osg/jvm98 All my cautions about not trusting ANY synthetic benchmark overly much still apply.
Its is possible you are running into the "on-stack replacement" issue in the JDK1.2 version of HotSpot. This is a problem that only affected micro-benchamrks, not real apps, but was fixed in 1.3 anyway because it was confusing people trying to mesaure things.
There's a discussion of it here:
http://java.sun.com/products/hotspot/1.0/Q+A.htm l
Re:IBM Native Threads implementation inefficient
on
IBM JDK 1.3 For Linux
·
· Score: 1
This matches with the java Lobby results, i suspect. Good performance on servlets, crummy performance on GUI stuff.
Re:IBM Native Threads implementation inefficient
on
IBM JDK 1.3 For Linux
·
· Score: 1
Volano, the experts tell me, is also is really just a messaging benchmark. Thats accurate for some kinds of apps but hardly all or even necessarily a majority. In re TowerJ. Again, this is second hand, but I am told it has a huge number of tweaking knobs. I'd like to know if this is performance runnign "vanilla" or after intensive tweking for this particualr bench mark. If the latter you have to ask how much this really differs from benchmark 'spoofing", which most of us I think agree is out-of-bounds. Finally, and I repeat this often, in the end any synthetic benchmark tells you at best how that system runs that particular synthetic benchmark. A spread of benchamrks is better. A spread of benchamrks on a spread of ahrdware is better still. But the only REAL test of how your app will perform under a given VM or other execution environment is your app. "There are three kinds of lies: Lies, Damn Lies, and Benchmarks" --- me, paraphrasing Mark Twain, whenever I give talks
Having come from the game industry, I'll defend a certain degree of conservatism (but only a certain degree.)
Game programers are very slow to adopt new technology. Thsi makes sense for them. They are generally on extremely (one might say rediculously) short schedules with minimal resources. They have barely enough time to apply what they do know to the problem and, shoudl the proejct fail, they generally get sacked -- no matter WHOSE fault or faults it was.
Game programmers need to be really sure that doing soemthing new is going to pay off immediately. They may not be the only oens in this position.
Now what is dumb, and shows a lesser enginner at work, is to say "it CAN'T be better then waht I already know." Being defensive just gaurantees you'll be otu of work eventually because all technolgoies age and are replaced. (I remember the fight over C... where are the pure assembly code game programmers now???)
My point is, as an engineer its perfectly reasonable to be cautious, its perosnally dangerous though to be willfully blind.
Yep, there's room for all KINDS of new ideas in JITs. It opens up all kinds of thinsg that haven't been possible before and I'm sure we're goign to see a lot of exciting things come out of the compiler-gurus at places like IBM and Sun in the coming year or two.
The idea of "evolving code" is already happening in the sense of the "agressively inlined" or "dynamicly deoptomized" code (two terms for the same thing.) There are some advances on this idea that I know of already in development at Sun adn I'm sure there are equally exciting things happening at Big Blue:)
"Maybe next year, maybe in 5 years will a JIT compiler beat a good Java to native compiler with profile feedback. "
What do you mean by "profile feedback". If your talking about profiling and tuning your code, no JIT CLAIMS to remove this step, nor should it. The biggest wins in profiling are not ON the code-generation level, they are on the algorithmic level.
You can and should do a write-profile-tune loop with code going into a JIT just as you do with code going into a static compiler.
In fact, since Java has the VM machinary there it has a great opportunity to give you plenty of profiling feedback (see JVMPI).
(In point of fact, the ONLY product I've seen claim to eliminate this step is a static compiler, and THATS marketing BS. A compiler CAN'T tell if your doing too much work in your algorithims for the results you need-- that requires a level of AI undertsanding of the entire purpose of the program and takes us into Start Trek-ville and the DWIM statement.)
The most funny/ironic thing about all of this is..... I've heard it all before.
I was one of the early adopters of C++ and the verbage was virtually identical, compelte with all the empty flame wars.
If you had told me 10 years ago that the time would come when people talked about C and C++ in the same breath when it came to performance I would have said you were at elast over-optimistic, if not outright nuts.
The problem in the beginning was that people didn't udnerstand C++ and were trying to write C code in it. The problem now is that people don't understand Java and try to write C++ code in it.
Having learned from the past, I know now with certainty that the time will come when people say, "But will NEVER be as fast as C++/Java!"
And they'll be wrong again. Thsoe who do not study history are doomed to repeat it.
There's nothing here to respond to. You are entitled to your opinion.
I'll call your bluff in return. Show me a static compiler that can run a reasonably real-world non-trivial purely numerical problem in a truely java fashion (which means safety, no dropping bounds checking or other cheats) against the Windows 1.3 Hotspot with appreciably better results.
This includes supplying me with access to the source and the compiler so I can double check it for "funny business."
I've been doing just Java performance work for over a year, including serious research into the whys and wherefores of why Java code does or doesnt perform under different situations and I haven't seen this.
Also, for a more detailed and more easily read discussion of the HotSpot technology, you can look at Appendix B in the book I already mentioned that will be out next month.
("Java(tm) Platform Performance: Strategies and Tactics")
Well its odd given the annecdotal evidence of peopel running real apps-- they don't seem to be reporting an order of mangitude difference. In fact, early reports on Swing apps are that Sun jdk1.2.2 with the Inprise JITa re actually visibly faster.
When synthetic benchmarks don't reflect real world behavior there is usually something funky about the benchmark. Benchmarks don't act like real world apps. iIt is certainly possible to tune for a given benchmark, or even outright spoof it.
I wouldn't accuse IBM of spoofing, but I have some real skepticism that what you are seeing is anything more than an anomoly. Try running SPEC and some of the other more modern benchmarks and comapre notes with others doing the same. The best tests are always real-world apps, but certainly a range of benchamrkas (Caffine is rather old among other things) on a range of hardware will give you a better picture then one test on one configuration.
I give talks on this topic and I always tell people not to put too much faith in ANY synthetic benchmark numbers
>>(2) There is no reason third parties can't >>create their own high-efficiency >>implmentations.
>Not when the inefficiencies are embedded in the >java.lang specifications. Like the moronic >decision to synchronize all over the place.
Hard exampels please? Very few things in the Java libs are specified as thread safe today.
Vector and Hashtable were originally implemented thread-safe. Java2 repalced them in with the entire collections set of classes, which are not by default thread safe. Collections provides you with wrappers if you want idiot-proof synchronization. In general this seems to be the trend of Java APIs.
It's also a suspicious one. Are you sure you were running the 1.2 with the Inprise JIT and the JIT enabled? This doesn't seem to jibe with the real-world comparisions being posted on java lobby. I curious what your set up shows under SPEC. Ofcourse to paraphrase Mark Twain. There are 3 kinds of lies: lies, damn lies, and benchmarks.
You've raised a different issue here-- the question of library efficiency.
Since you've accepted the premise that Java can be as fast or faster an execution environemnt as C/C++, we're really talking about quality of code.
There are a few answers to this: (1) Efficiency has been a focus for voer a year at Java Software (Sun). Sun has been doing intensive clean-up work on the libraries, making them faster and smaller. The gains so many have commented on in 1.3 on windows in both execution size and GUI performance derive in large part from library clean-up. This is an on-going effort at Sun with a group dedicated now to JDK perfromance issues.
(2) There is no reason third parties can't create their own high-efficiency implmentations.
(3) There are a small number of places where the APIs were missing critical functions for efficient coding. (Ex: Allowing a thread to listen() to more then one socket at a time.) These are being identified and fixed.
(Sorry, I accdientally posted as HTML and silly slashdot wont let me delete and repost when that happens nor add another response beneath so I had to up here.)
Troy,
The basic numbers are in the book I mentioned. They are somewhat annecdotal but based on real world problems (like calculating a Bresenham line.) If you want to email me at jeffpk@iname.com I can probably dig you up some "harder" test type numbers.
I would have to be honest and say that I don't knwo enough about FORTRAN compilers to answer your second question. Its possible that FORTRAN creates such trivial linear code that a lot of the value of run-time analysis goes away.
There is anoter issue with older languages though that is particularly obvious when benchamrking java v. hand crafted assembly.
The REAL performance gains in any program of signifcant size can be found not in the byte crunching but in algorthim selection and tuning. This is very hard to do in lower level languages. The compelxity of the problem quickly becoems the dominant conrolling factor.
An object oriented langauge like Java makes isolation of functional units clean and easy, resulting in a much more tunable program.
So while I wouldn't say a modern JIT produces tiny amounts of code better then a processor espert could hand code (though its getting damn close to equal), and I don't knwo enough about FORTRAN to comment intelligently on its code generation, I AM confident in saying thawt Java today is as good or better then C/C++ and is more easily debugged and tuned.
SO given a fixed amount of time to do a non-trivial program, I'd lay money I could get a faster runnin result in Java then any other language I know of.
Re:Bold assertion there... (Re:Misconceptions)
on
IBM JDK 1.3 For Linux
·
· Score: 1
Troy, The basic numbers are in the book I mentioned. They are somewhat annecdotal but based on real world problems (like calculating a Bresenham line.) If you want to email me at jeffpk@iname.com I can probably dig you up some "harder" test type numbers. I would have to be honest and say that I don't knwo enough about FORTRAN compilers to answer your second question. Its possible that FORTRAN creates such trivial linear code that a lot of the value of run-time analysis goes away. There is anoter issue with older languages though that is particularly obvious when benchamrking java v. hand crafted assembly. The REAL performance gains in any program of signifcant size can be found not in the byte crunching but in algorthim selection and tuning. This is very hard to do in lower level languages. The compelxity of the problem quickly becoems the dominant conrolling factor. An object oriented langauge like Java makes isolation of functional units clean and easy, resulting in a much more tunable program. So while I wouldn't say a modern JIT produces tiny amounts of code better then a processor espert could hand code (though its getting damn close to equal), and I don't knwo enough about FORTRAN to comment intelligently on its code generation, I AM confident in saying thawt Java today is as good or better then C/C++ and is more easily debugged and tuned. SO given a fixed amount of time to do a non-trivial program, I'd lay money I could get a faster runnin result in Java then any other language I know of.
Lots, Im sure if you did a net search you'ld find them.
The "Who wants to be a millionare" computer game I am told is a pure Java application. This is a shipping full featured shrink-wrapped product-- not an applet.
Similarly I just came across a pure Java accounting program today. (Secure-somebody. I have the information at work.)
Ofcourse we have things like WebLogics EJB applciation serevr which is written in Java. In short there are a ton of em.
You just need to look for em. If you really want to fnd them, I'd start by lookign at the archives of the Java Lobby (www.javalobby.com)
> . The optimizations performed as not nearly as >aggressive as static compilers try, why ? >Because at runtime you cant afford the time >penalty This statement shwos a compelte lack of understanding about what HotSpot does. HotSpot focuses the compilation effort on the code that gets most used ( the "HotSpots") and thus has the time to do all the optimizatiosn it needs. The actualy optimizatiosn are actually MORE agressive because Hotspot can guess agressively in ambiguos optimization situations and back those optimizatiosn out later if they prove wrong. I gave a more complete, but still brief, explaination of this in the top thread -- look at the message titled "Misconceptions." More detailed theoretical information can be found in white papers at java.sun.com in the HotSpot section. A whole section on the real life costs/benefits of Java code v. native code (including real world measurements) is in the book "Java Platform Performance: Strategies and Tactics" which will be released at JavaOne next month. (
Modern Java VMs, such has Sun's HotSpot on Windows or IBM's 1.1.8, produce code that is as fast or faster then that produced by static compilers.
Some things to understand: (1) Java code IS compiled. Its just compiled at run-time rather then build-time. The result is the same however-- machine code running on your machine.
(2) JITs have a number of advantages over static compilers: (a) A static compiler must compile for a lowest common denominator platform (typicly Pentium). A JIT can determine the processor type at run-time and produce processor-tuned code.
(b) A static compiler must "guess safe" in situations where code is ambiguous. A JIT can go ahead and take risky optimizations because it can un-optimize if the need arises.
One place this occurs a lot is in in- lining. The static compiler can only safely in-line finals. The JIT can try to in-line anything and adjust by how the code actually gets used. (HotSpot calls this "agressive inlining" and you can read about it at the HotSpot section of java.sun.com)
Simple fact. For raw computation that doesn't incurr array bounds checking, Java is as fast or faster today then C/C++. (And static compiling doesn't help you with the bounds checking penalty.)
There are some actual experiemntal numbers and a chapter discussing this and other Java v. native code issues in "Java(tm) Platform performance: Strategies and tactics" coming out at JavaOne. (Its already up for pre-order at amazon...)
Slashdot Mirror
You're absoluely right that therr are library problems. Alot of them have to do with implementation details, which are being worked on. (Anoyone whose tried Swing under JDK1.2 v. the 1.3 thats currently out has seen the results, and there are better thinsg still in the works.)
A few of them have to do with the nature of the libraries as very high-level, idiot proof things. Lower level facillities are gradually appearign in java. I've been playing with java for games myself, and as part of that I've written JNI to talk to DX directly. Doing that, Java easily flips frames at the limit of my video-synch (70hz) on my PC.
There are a few key things missing from Java for real ultra-high performance stuff. A number of these are being added... I can't say much more now but I'll gladly post abotu them when they are public. (Actually, when one of them is public, I'll be able to finish and post my DirectJava library, which I intend to make open-source.)
Now I hate to disagree with someone whose on the same philisophical side... but I need to disagree with you on bounds checking. Unless you know of some approach I don't, AFAIK there is no way to eliminate it from random-access reading and writing of arrays.
What you mentioned about loops is called "hoisting" and yes this is happeneing, but an array implementation of a stack, for instance, must still check every access to make sure its within the memory area of the array proper. We have to be careful not over-sell hoisting and lead people the wrong way in their programming.
>I suggest you actually do some experiments >yourself. Java and C++ are close enough that >it's quite easy to compile virtually identical >code in both
Your premise is compeltely off. To restate the above: "Java shouls run code tuned for C++ as fast as C++."
Thats nonsense. Many of the things we do in C++ to encourage it to perform HURT Java performance, and vice versa. Just taking a piece of C++ code and recompiling it is gaurranteed to have lousy results... and taking peice of well tuned Java code and simply recompiling it in C++ will have EQUALLY bad results.
Just a few sample issues:
(1) Arrays
In C/C++, arrays are used extensively in high prformance programming. When one wants to speed up a recursive routine, one re-writes the routine with a lcoal arrwy asbed stack.
In Java, array access incurrs bounds check penalties. It is FASTER in tegh latest generation of VMs to recurse then build a lcoal stack.
(2) Virtual methods
In high performance C++ one must code to avoid virtual methods because they cannot be inlined. In Java it is good practice TO use virtual methods (a non-virtual in Java is a final) because the latest VMs are very sophsiticated in determining for themselves if something is in-linable.
In general java today is MUCH better at in-lining then ANY C++ compiler.
(3) Tuning Time
It is at this point I believe an undisputed fact that a Java coder can write correct code faster then a C++ coder. (My own experience, and that of it seems many others, has been about an order of magnitude difference in speed.) In the REAL world, time is limited. Faster coding means more time to tune, therefor for the same period of time coding, an equally proficient Java coder will produce a better tuned application.
These, and many other factors, are totally absent from your "test".
The sad thing is, if you had been prgoramming C++ as long as I have, this would all sound familiar. These exact same dispersions were cast on C++ when it arrived on the scene. People had to learn how to use the tool before it payed off. Really learn Java, then make your comparisons.
Okay,
I've now seen a bunch of real-world benchmarks that more or less explain what everyone has seen. They're internal numbers that I can't release, but in general...
The 800: 6200 (approx 8x difference) v. jdk1.2 seems reasonable on purely computational things. This confused me until I remembered that Linux is the one place where the jdk1.2 ISN'T hotspot. This is a classic v. much more modern VM comparison. Hotspot can be expected to perform similarly when released on Linux.
The varying GUI numbers are explained by the fact that it performas somehwt differently on different GUI tasks. A few its very good at now, some it still needs some work on.
In general, on Linux IBM 1.1.8 is still beating JDK1.2.2 and IBM 1.3 respectably in most GUI things. IBM 1.3 is kicking repectable rear in non-gui tasks.
Others have already reported some scaling issues with 1.3 I don't have tests for those.
You can get SPEC from:
http://www.spec.org/osg/jvm98/.
It's been mentioend a few tiems. (Okay its been mentioned a few times by me, and once or twice by others ;) ) That niether Volano or Caffine are terribly realistic benchkmarks. I've suggested SPEC a few times. Here's where to get it: http://www.spec.org/osg/jvm98 All my cautions about not trusting ANY synthetic benchmark overly much still apply.
Caffine is an old Benchmark.
m l
Its is possible you are running into the "on-stack replacement" issue in the JDK1.2 version of HotSpot. This is a problem that only affected micro-benchamrks, not real apps, but was fixed in 1.3 anyway because it was confusing people trying to mesaure things.
There's a discussion of it here:
http://java.sun.com/products/hotspot/1.0/Q+A.ht
This matches with the java Lobby results, i suspect. Good performance on servlets, crummy performance on GUI stuff.
Volano, the experts tell me, is also is really just a messaging benchmark. Thats accurate for some kinds of apps but hardly all or even necessarily a majority. In re TowerJ. Again, this is second hand, but I am told it has a huge number of tweaking knobs. I'd like to know if this is performance runnign "vanilla" or after intensive tweking for this particualr bench mark. If the latter you have to ask how much this really differs from benchmark 'spoofing", which most of us I think agree is out-of-bounds. Finally, and I repeat this often, in the end any synthetic benchmark tells you at best how that system runs that particular synthetic benchmark. A spread of benchamrks is better. A spread of benchamrks on a spread of ahrdware is better still. But the only REAL test of how your app will perform under a given VM or other execution environment is your app. "There are three kinds of lies: Lies, Damn Lies, and Benchmarks" --- me, paraphrasing Mark Twain, whenever I give talks
Having come from the game industry, I'll defend a certain degree of conservatism (but only a certain degree.)
Game programers are very slow to adopt new technology. Thsi makes sense for them. They are generally on extremely (one might say rediculously) short schedules with minimal resources. They have barely enough time to apply what they do know to the problem and, shoudl the proejct fail, they generally get sacked -- no matter WHOSE fault or faults it was.
Game programmers need to be really sure that doing soemthing new is going to pay off immediately. They may not be the only oens in this position.
Now what is dumb, and shows a lesser enginner at work, is to say "it CAN'T be better then waht I already know." Being defensive just gaurantees you'll be otu of work eventually because all technolgoies age and are replaced. (I remember the fight over C... where are the pure assembly code game programmers now???)
My point is, as an engineer its perfectly reasonable to be cautious, its perosnally dangerous though to be willfully blind.
Yep, there's room for all KINDS of new ideas in JITs. It opens up all kinds of thinsg that haven't been possible before and I'm sure we're goign to see a lot of exciting things come out of the compiler-gurus at places like IBM and Sun in the coming year or two.
:)
The idea of "evolving code" is already happening in the sense of the "agressively inlined" or "dynamicly deoptomized" code (two terms for the same thing.) There are some advances on this idea that I know of already in development at Sun adn I'm sure there are equally exciting things happening at Big Blue
I just noticed this part of your statement...
"Maybe next year, maybe in 5 years will a JIT compiler beat a good Java to native compiler with profile feedback. "
What do you mean by "profile feedback". If your talking about profiling and tuning your code, no JIT CLAIMS to remove this step, nor should it. The biggest wins in profiling are not ON the code-generation level, they are on the algorithmic level.
You can and should do a write-profile-tune loop with code going into a JIT just as you do with code going into a static compiler.
In fact, since Java has the VM machinary there it has a great opportunity to give you plenty of profiling feedback (see JVMPI).
(In point of fact, the ONLY product I've seen claim to eliminate this step is a static compiler, and THATS marketing BS. A compiler CAN'T tell if your doing too much work in your algorithims for the results you need-- that requires a level of AI undertsanding of the entire purpose of the program and takes us into Start Trek-ville and the DWIM statement.)
The most funny/ironic thing about all of this is..... I've heard it all before.
I was one of the early adopters of C++ and the verbage was virtually identical, compelte with all the empty flame wars.
If you had told me 10 years ago that the time would come when people talked about C and C++ in the same breath when it came to performance I would have said you were at elast over-optimistic, if not outright nuts.
The problem in the beginning was that people didn't udnerstand C++ and were trying to write C code in it. The problem now is that people don't understand Java and try to write C++ code in it.
Having learned from the past, I know now with certainty that the time will come when people say, "But will NEVER be as fast as C++/Java!"
And they'll be wrong again. Thsoe who do not study history are doomed to repeat it.
There's nothing here to respond to. You are entitled to your opinion.
I'll call your bluff in return. Show me a static compiler that can run a reasonably real-world non-trivial purely numerical problem in a truely java fashion (which means safety, no dropping bounds checking or other cheats) against the Windows 1.3 Hotspot with appreciably better results.
This includes supplying me with access to the source and the compiler so I can double check it for "funny business."
I've been doing just Java performance work for over a year, including serious research into the whys and wherefores of why Java code does or doesnt perform under different situations and I haven't seen this.
You are totally 100% incorrect.
. html#7d
Hotspot agressively inlines and then un-inlines when it finds a method is used in a non-final way. The buzz word for this is "agressive inlining."
Look at the section on "Dynamic Deoptimization" in the following white-paper:
http://java.sun.com/products/hotspot/whitepaper
Also, for a more detailed and more easily read discussion of the HotSpot technology, you can look at Appendix B in the book I already mentioned that will be out next month.
("Java(tm) Platform Performance: Strategies and Tactics")
Well its odd given the annecdotal evidence of peopel running real apps-- they don't seem to be reporting an order of mangitude difference. In fact, early reports on Swing apps are that Sun jdk1.2.2 with the Inprise JITa re actually visibly faster.
When synthetic benchmarks don't reflect real world behavior there is usually something funky about the benchmark. Benchmarks don't act like real world apps. iIt is certainly possible to tune for a given benchmark, or even outright spoof it.
I wouldn't accuse IBM of spoofing, but I have some real skepticism that what you are seeing is anything more than an anomoly. Try running SPEC and some of the other more modern benchmarks and comapre notes with others doing the same. The best tests are always real-world apps, but certainly a range of benchamrkas (Caffine is rather old among other things) on a range of hardware will give you a better picture then one test on one configuration.
I give talks on this topic and I always tell people not to put too much faith in ANY synthetic benchmark numbers
HotSpot drasticly reduces the cost of syncrhonization, such that you are only paying it where threads are actually going to collide.
Still i agree with you that synchronization should always be doen minimally and ideally by the programmer.
As far as I am aware, Java2 lets you do this. If there are places that are still over-synchrinized I'd like to hear about them.
>>(2) There is no reason third parties can't >>create their own high-efficiency >>implmentations.
>Not when the inefficiencies are embedded in the >java.lang specifications. Like the moronic >decision to synchronize all over the place.
Hard exampels please? Very few things in the Java libs are specified as thread safe today.
Vector and Hashtable were originally implemented thread-safe. Java2 repalced them in with the entire collections set of classes, which are not by default thread safe. Collections provides you with wrappers if you want idiot-proof synchronization. In general this seems to be the trend of Java APIs.
It's also a suspicious one. Are you sure you were running the 1.2 with the Inprise JIT and the JIT enabled? This doesn't seem to jibe with the real-world comparisions being posted on java lobby. I curious what your set up shows under SPEC. Ofcourse to paraphrase Mark Twain. There are 3 kinds of lies: lies, damn lies, and benchmarks.
You've raised a different issue here-- the question of library efficiency.
Since you've accepted the premise that Java can be as fast or faster an execution environemnt as C/C++, we're really talking about quality of code.
There are a few answers to this:
(1) Efficiency has been a focus for voer a year at Java Software (Sun). Sun has been doing intensive clean-up work on the libraries, making them faster and smaller. The gains so many have commented on in 1.3 on windows in both execution size and GUI performance derive in large part from library clean-up. This is an on-going effort at Sun with a group dedicated now to JDK perfromance issues.
(2) There is no reason third parties can't create their own high-efficiency implmentations.
(3) There are a small number of places where the APIs were missing critical functions for efficient coding. (Ex: Allowing a thread to listen() to more then one socket at a time.) These are being identified and fixed.
(Sorry, I accdientally posted as HTML and silly slashdot wont let me delete and repost when that happens nor add another response beneath so I had to up here.)
Troy,
The basic numbers are in the book I mentioned. They are somewhat annecdotal but based on real world problems (like calculating a Bresenham line.) If you want to email me at jeffpk@iname.com I can probably dig you up some "harder" test type numbers.
I would have to be honest and say that I don't knwo enough about FORTRAN compilers to answer your second question. Its possible that FORTRAN creates such trivial linear code that a lot of the value of run-time analysis goes away.
There is anoter issue with older languages though that is particularly obvious when benchamrking java v. hand crafted assembly.
The REAL performance gains in any program of signifcant size can be found not in the byte crunching but in algorthim selection and tuning. This is very hard to do in lower level languages. The compelxity of the problem quickly becoems the dominant conrolling factor.
An object oriented langauge like Java makes isolation of functional units clean and easy, resulting in a much more tunable program.
So while I wouldn't say a modern JIT produces tiny amounts of code better then a processor espert could hand code (though its getting damn close to equal), and I don't knwo enough about FORTRAN to comment intelligently on its code generation, I AM confident in saying thawt Java today is as good or better then C/C++ and is more easily debugged and tuned.
SO given a fixed amount of time to do a non-trivial program, I'd lay money I could get a faster runnin result in Java then any other language I know of.
Troy, The basic numbers are in the book I mentioned. They are somewhat annecdotal but based on real world problems (like calculating a Bresenham line.) If you want to email me at jeffpk@iname.com I can probably dig you up some "harder" test type numbers. I would have to be honest and say that I don't knwo enough about FORTRAN compilers to answer your second question. Its possible that FORTRAN creates such trivial linear code that a lot of the value of run-time analysis goes away. There is anoter issue with older languages though that is particularly obvious when benchamrking java v. hand crafted assembly. The REAL performance gains in any program of signifcant size can be found not in the byte crunching but in algorthim selection and tuning. This is very hard to do in lower level languages. The compelxity of the problem quickly becoems the dominant conrolling factor. An object oriented langauge like Java makes isolation of functional units clean and easy, resulting in a much more tunable program. So while I wouldn't say a modern JIT produces tiny amounts of code better then a processor espert could hand code (though its getting damn close to equal), and I don't knwo enough about FORTRAN to comment intelligently on its code generation, I AM confident in saying thawt Java today is as good or better then C/C++ and is more easily debugged and tuned. SO given a fixed amount of time to do a non-trivial program, I'd lay money I could get a faster runnin result in Java then any other language I know of.
Lots, Im sure if you did a net search you'ld find them.
The "Who wants to be a millionare" computer game I am told is a pure Java application. This is a shipping full featured shrink-wrapped product-- not an applet.
Similarly I just came across a pure Java accounting program today. (Secure-somebody. I have the information at work.)
Ofcourse we have things like WebLogics EJB applciation serevr which is written in Java. In short there are a ton of em.
You just need to look for em. If you really want to fnd them, I'd start by lookign at the archives of the Java Lobby (www.javalobby.com)
> . The optimizations performed as not nearly as >aggressive as static compilers try, why ? >Because at runtime you cant afford the time >penalty This statement shwos a compelte lack of understanding about what HotSpot does. HotSpot focuses the compilation effort on the code that gets most used ( the "HotSpots") and thus has the time to do all the optimizatiosn it needs. The actualy optimizatiosn are actually MORE agressive because Hotspot can guess agressively in ambiguos optimization situations and back those optimizatiosn out later if they prove wrong. I gave a more complete, but still brief, explaination of this in the top thread -- look at the message titled "Misconceptions." More detailed theoretical information can be found in white papers at java.sun.com in the HotSpot section. A whole section on the real life costs/benefits of Java code v. native code (including real world measurements) is in the book "Java Platform Performance: Strategies and Tactics" which will be released at JavaOne next month. (
According to some of the early reviews on
http://www.javalobby.com
Sun's 1.2 for Linux beats the pants off of IBMs 1.3 for GUI apps.
This whole thread is built on a misconception.
Modern Java VMs, such has Sun's HotSpot on Windows or IBM's 1.1.8, produce code that is as fast or faster then that produced by static compilers.
Some things to understand:
(1) Java code IS compiled. Its just compiled at run-time rather then build-time. The result is the same however-- machine code running on your machine.
(2) JITs have a number of advantages over static compilers:
(a) A static compiler must compile for a lowest
common denominator platform (typicly
Pentium). A JIT can determine the
processor type at run-time and produce
processor-tuned code.
(b) A static compiler must "guess safe" in
situations where code is ambiguous. A
JIT can go ahead and take risky
optimizations because it can un-optimize
if the need arises.
One place this occurs a lot is in in-
lining. The static compiler can only
safely in-line finals. The JIT can
try to in-line anything and adjust by
how the code actually gets used.
(HotSpot calls this
"agressive inlining" and you can read about
it at the HotSpot section of java.sun.com)
Simple fact. For raw computation that doesn't incurr array bounds checking, Java is as fast or faster today then C/C++. (And static compiling doesn't help you with the bounds checking penalty.)
There are some actual experiemntal numbers and a chapter discussing this and other Java v. native code issues in "Java(tm) Platform performance: Strategies and tactics" coming out at JavaOne. (Its already up for pre-order at amazon...)