It's exactly the claims about number crunching which I'm saying are overly broad given the limitations of your benchmark.
Perhaps I've completely misread your conclusions. I thought you said that Java was a poor tool for doing number crunching, specifically floating-point number crunching. If I misread that then I apologise and I'll have to reread, and you can skip the rest of this paragraph.;-) Your benchmark is much more limited than a accurate assesment of raw floating-point number crunching capability. Indeed, I have first hand experience that suggests for some types of floating point problems the performance differences between the languages are far less significant than indicated by your benchmark. Perhaps the best one could say is, "direct ports of short-run, trigonmetric, floating intensive Fortran applications will not run efficently with Java". That's a lot of qualifiers.
Certainly you say your benchmark demonstrates that Java's (and in fact it's the Sun VM's optimizations, not Java's, but that's a semantic issue) "run-time optimisations" don't do much for floating point math. Yet, as we've already discussed, and as you knew full well, your benchmark does not exploit these optimisations (otherwise -server should produce a better score than -client).
Hey, I'd be the first to admit that for the job you're doing in this benchmark Java is a poor tool for the task, and that there are plenty of other tasks for which it is ill suited for.
However, the conclusions you draw from this are that Java is a poor tool for a much broader set of applications and circumstances than your benchmark accurately measures.
Certainly, lots of floating point calculations are highly persistent, and take *days* to execute. In many cases, even if they don't take days to execute, the same code is executed with different datasets. These are the kind of problems for with the Sun's Java VM is capable of approaching Fortran and C++ performance. It's known that the optimisations which are applied in these circumstances can improve execution speed by several times. Based on that it's totaly unreasonable to use your benchmark to draw conclusions about Java's overall abilities in high-performance settings.
Your test also times everything including load time for the program. Because you don't isolate out just the floating-point calculations of the code, you don't have adequate controls on the other variables in the execution of your program.
You conclude that Java does not take advantage of processor specific optimisations (it actually does have processor specific optimisations). I don't see how this conclusion could be based on your tests, particularly since the Sun JVM demonstrated significantly more of a performance improvement on the Pentium IV box than gcc or gcj were able to show (indeed they were even better than the performance improvements with the "default" builds with the Intel compilers).
The infamous "lies, damn lies, and benchmarks" (paraphrasing a bit) is not so much about the benchmarks themselves, but how they tend to be used innappropriately to make generalisations well beyond what they accurately demonstrate.
In TowerJ's case, the only difference from the production product is the limited time period for use (15 days). However, I checked it out myself and it appears that if you click through they've actually recalled their downloads program. Now you have to register to get to the code (and they may not even give it to you then).
I can tell you from past experience though that it pretty much killed gcj in performance for this kind of stuff.
Sorry, I misread your post. The problem you are talking about is real, but usually not an issue (because usually if you don't catch the exception the program exits, and all memory is recovered). I thought you were talking about a different problem.
Seriously, if you know Java, you had to know that the stuff you were writing is Java was semantically different (and significantly so) in many ways from the Fortran and C++ code (in terms of what the program was telling the language to do). You also had to know that the way you were benchmarking the code was going to get anywhere near an accurate measurement of Java's overall thoroughput for executing this problem. Knowing that, how can you really feel that this is a reasonable performance assessment of Java?
I agree it's a Catch-22 problem. You will be criticised no matter what you do.
That being said, I'm not sure that you can effectively measure the performance characteristics of a language if you apply idioms to it from another language. It merely measures one language's ability to effectively execute another's runtime model. While this is an interesting measurement in and of itself, it is not an effective measurement as to whether a given language can solve the original problem in an efficient manner.
How's this for a solution: write the program in Java with a focus on the Java execution model, then translate it back in to Fortran. Now you'll have a version in both languages of both programs. This would make you pretty much safe in both camps.
I agree that the trig tests are valid for testing the performance of a given VM, but they aren't a valid reflection of the language. From a language perspective, there is no reason why Java's sin and atan2 functions can't execute as quickly as their Fortran equivalents. For that matter the same is true of C++ (and as you rightly suspect, the Fortran and C++ code that *is* using the same floating point library gets very similar results).
Actually, you can test it even if you don't own it. They provide a free trial download right off their home page.
The -O flag wasn't doing anything that improved performance on a JIT'd system, which is why it was removed. The problem is you're looking for optimisation flags in the wrong space. As long as the compiler is outputing byte codes any performance optimisations it might do are actually quite likely to make things worse. Admittedly, the SunVM doesn't have much in the way of floating point optimisation flags, but that is where performance optimisations kick in for JIT'd runtimes.
This is actually a classic example of how people screw up exceptions in C++. Aside from a not using unknown() to handle errant exceptions, the bigger problem is the notion that try/catch blocks are how you avoid memory leaks in C++. Take a look at this old problem to give yourself an idea of some of the complexities with exceptions. While the problem does not create a resource leak (indeed, it effectively LOSES resources), it demonstrates how it can go wrong in the most surprising ways.
While it is conceivable to get everything working right using try/catch blocks, you have to write a ton of insanely structured code, and it's very error prone.
What you want to use is the "resource acquisition is initialization" idiom. Here's some info on it here. It's all about the stack and destructors man.
I agree with your analysis of the C++ code. However, I disagree with your notion that porting line is a valid test of the relative CPU-bound performance of these languages. The program is invariably written as per the preferences of the original language, particularly with some pretty massive assumptions about what is most optimal. Using two-dimensional arrays instead of a Matrix class which is internally a 1-dimensional array is a very good example of this.
Sorry, to clarify, I understand that execution units in modern CPU's aren't very busy. However, this is for the most part not due to deficiencies in the expressiveness of programming languages/compilers. In general, most computer programmers have a fairly linear flow, and even if you wrote the code in assembler by hand you'd be hard pressed to keep the execution units busy all the time.
The original poster was specifically talking about read/write barriers. Fortran has special features which allow the compiler to make some very impressive assumptions about read/write dependancies. These features allow for much more powerful instruction reordering than the kind of stuff you are talking about. Indeed, as he said, these optimisations aren't possible in C/C++ either without the use of the restrict keyword. As I said, the stuff you are talking about is entirely possible to do in a JIT, and is in fact being done in all the major JVM's.
Okay, first of all, for embedded systems this is actually very important. For any embedded system that has to run for years, one of the key issues is that it absolutely must use a heap manager that avoids long-term fragmentation (or have a static heap... but that's another story). Java happens to have a prepackaged solution for this. This, plus small executable size due to the use of byte codes is one of the reasons Java is used for embedded projects.
Actually, the cost of hitting the disk is typically the most important impact on system peformance once you have an app who's working set can't fit into available RAM. That's because access for swapped virtual memory is orders of magnitude slower than virtual memory that in RAM. As you said, most systems today are not CPU limited, but rather memory limited, so switching to another app which also needs to access virtual memory is actually going to make things worse (just try running two programs who's working sets are larger than available RAM and you'll get the idea).
As for memory defragging eating bandwidth like there's no tomorrow, that's only half of the picture. Good GC systems aren't constantly defragging memory at top speed, so the penality is frequently invisible. Smart systems GC when there is available CPU time and memory bandwidth (check out BEA's JVM for example). More importantly, by defragging intelligently you actually increase the chances that sequential memory accesses will hit the various memory cache's on the system (it's really nice when the cache lines are all filled with actual related data instead of unrelated fragments with gaps).
The thing to keep in mind is that the people who write GC systems (or at least the good ones) aren't stupid about how they use memory. They spend a lot of time very carefully analysing memory management issues and put their findings into their system. As a result, most GC systems are better at doing memory management than your average programmer (although there are always special problems where a particular GC will perform particularly poorly).
Actually, some VM do cache friendly management. All of the VM's take care of basic byte-alignment issues.
The instruction ordering for which you need explicit declaration of read/write barriers for are large matrix math operations, and even then it only matters if you've got huge amounts of data parallelism from a vector processor. Everything2 has a better description than I can write. All of the modern JVM's currently do basic instruction reordering just like C++ compilers, and it's enough to keep the execution units in modern CPU's pretty busy. Things like the "restrict" keyword aren't going to help much with that.
As for "-client vs. -server". This is really basic Java stuff. Check out Sun's own docs on the matter. Where to start. *BOTH* VM's are HotSpot VM's. Both behave the way you describe the client. The difference is that the client VM does less profiling of the code and performs fewer optimisations (actually, there are many more differences, but this is what's relevant to what you said). The benchmark taking a "couple of minutes" to run is not enough for the -server VM to really shine. It's designed for programs that at least run for hours.
Finally, it's actually NOT the number of minutes that the code runs that really determines what optimisations are good/bad for performance. It's the number of times the same code is run. And while some of the code is undoubtedly getting optimised, it is not enough for it to get all the optimisations, and it is certainly not enough for the optimisations to outweigh the penalty for profiling that was incurred during the earlier execution.
Believe it or not, I'm not a Java "ZEALOT". Indeed, at my current place of employ I don't write any Java, and I have written more C++ code than Java in general. I would write similar content about other interpreted languages (Self, LISP, APL, Smalltalk, etc.) had the original article referenced them in a similar manner. These kinds of silly, mindless comments come up all the time, and they show a total lack of knowledge about how to benchmark systems, and more importantly a lack of knowledge about the systems they are benchmarking.
He complains about the Java compilers complete lack of optimisation flags (duh... making optimisations to platform independant byte code is pretty useless, and generally counter productive... it's all done by the JRE, which actually has a number of flags for tweaking things, and there are many JRE's to choose from). He talks about how the JIT doesn't perform processor specific optimisations (it does in fact perform many processor specific optimisations, unfortunately his benchmark is written in such a way that none of them will get used). He talks about there being no interest in high-performance Java (the Java Grande group would beg to differ). Best of all, he keeps calling Java an interpretted language... even though he used gcj as part of his own benchmarks... Sigh.
Worst of all he uses gcj without trying out TowerJ, which is a much more established Java-binary compiler. Sigh.
He actually mentions that he has fixed this bug in his article, so I left it out. Plus, I didn't find any place in the Java code where he was allocating new arrays inside the loops (my guess is the code I got was after he fixed this).
That's really not surprising, his benchmark actually penalizes the -server version of Sun's VM compared to a conventional VM. Try using -server, running the benchmark 20,000 times in one process, and benchmark the 20,001st run in the same process. Then the -server option will definitely kick JView all over the place. Also, IBM's VM will probably compare pretty well in this benchmark, not to mention VM's specifically targetted to floating point operations.
I'll leave most of your stuff aside, because I do agree that a lot of silly things are said about Java's performance.
However, your comment that memory fragmentation is not a problem is a major misnomer. For starters, it assumes you have virtual memory, which is pretty hard to come by on embedded systems. Secondly, it assumes that you have an unlimited amount of virtual memory (because that's how much you'd need to avoid fragmentation problems for programs that run for an unlimited amount of time). Finally, it ignores the fact that fragmentation causes additional stress on the virtual memory subsystem which becomes a peformance issues essentially the first time you have to swap a page out to disk.
Okay, first of all, the Java VM is fully capable of doing cache friendly memory management... in fact it can actually discover things about the cache's behavior at run time that are not likely to be known a priori by the compiler/programmer. So it's actually quite reasonable for a Java VM to excel in this regard.
The instruction reordering issues you're talking about tends to only factor in when you have vector-processing CPU's. The limited vector-processing on the CPU's being tested is not enough to break the compiler's back, so it's not surprising Fortran is performing similarly to C++.
Sorry, but my code isn't available elsewhere. However, I point out a few things this guy got wrong in another post.
The difference between -client vs. -server is actually probably the opposite of what you are imagining. -client actually performs more optimisations at class load time, but fewer optimisations overall. This is in recognition of the fact that client programs tend to run for shorter periods of times.
The -server switch actually REDUCES the number of optimizations performed when loading a class. Instead, it adds extensive profiling to all code execution, and then the runtime will gradually optimise frequently executed code based on analysis of how it executes. The optimisations are introduced gradually, almost on an "as needed" type basis. This approach allows the JVM to perform optimisations which simply aren't practical for a compiler to do, because the compiler doesn't have access to the profiling information gathered at runtime. When faced without a JIT, many programmers effectively do peep-hole optimisations of this nature by hand, but they ultimately can't predict what future runtime environments are like, nor can they effectively perform global optimisations on large programs. Of course, there are other differences between -server and -client, but this is by far the most important one.
Hey, I'm not claiming which one is worse for programming in general. The point is that the pervious poster's claim that it's just as easy to avoid creating memory leaks in C++ as it is in Java is ludicrous, as both you and another poster have acknowledged.
In general, you'd be amazed how few leaks do tend to exist in Java programs, even written by relatively junior programmers. In particular, it's a lot easier to write/use libraries or frameworks without creating memory leaks. Sure you can find specific projects where you have a disaster on your hands, but I've actually been on a lot of J2EE projects, and less than 10% of them have exhibited the kind of problem you are talking about, as compared to the 80% of CORBA projects I've been involved with.
It's pretty clear this guy is not a Java programmer, or at least has limited knowledge of how to write efficient, well-designed programs in Java. Amazingly, that's actually not relevant. To get to the bottom line skip to the bottom of this post.
For starters, he's using 2-dimensional arrays, so of course Java is going to be slower. 2-dimensional arrays in C++ are actually 1-dimensional arrays with some syntactic sugar thrown in. In Java they are arrays of arrays (really akin to using vectors of pointers to vectors). Experienced Java programmers (and for that matter good C++ programmers) will use a Matrix class to both clean up the code structure and to provide a much more optimised 1-dimensional array structure for manipulations of the Matrix.
His benchmark doesn't have a warm-up run, and doesn't run nearly long enough to cause HotSpot to optimise the code thoroughly. Sure, this is fair if what you're measuring is how well the Java VM can execute a relatively short-run program (quick answer: not very well at all), but it is no indication of the kind of performance that Java can achieve.
The code essentially is not written like a standard Java program (and indeed, is a pretty evil C program if you ask me). I mean, any method with 30+ local variables is suspect in my book (particularly amusing is that some of them appear to be never used). As such, it doesn't play very well against the JVM's optimiser, which is oriented towards Java code with much different structure.
His TEST_LENGTH loop is long enough that he's potentially better off catching an array out of bounds exception than constantly checking the index.
This doesn't affect Java performance, but it's just silly to have a while(true) loop and then have a break on an if at the end of a block is just silly (it might trigger some optimization for a specific, broken C optimizer, but it's just silly to have that on a standard benchmark).
But ultimately this all doesn't matter. Why? Because the bottom line is this benchmark makes heavy uses of standard runtime functions (the trig and square root function). This means that large portions of this code are essentially out of the realm of the compiler, and in the hands of the runtime library. Doing stuff like this I can get widely different results just be linking in different floating point libraries. So, while he highlights the *compilers*, in fact what this is really stressing is the quality of the floating point libraries of the particular runtimes he's chosen. As such, it provides no insight in to the relative merits of using different compilers or languages. At worst, this might be misleading even for the specific application he has in mind. At best it suggests how a few different math libraries perform. The conclusions this guy draws from this are just rediculous.
There is no question that you can have a memory leak in a Java program. However, Java does remove a number of potential ways to create a memory leak that do occur in C++ (heck, 90% of C++ programs I see will leak heap memory if you have exceptions). Anyone who claims that "While it is possible to carefully write a Java program that doesn't leak, I don't think it's any easier than making a leakproof C++ program" either hasn't written a lot of C++, or hasn't written a lot of Java.;-)
For the record, I actually worked with the JPL evaluating Java's floating point performance. This was in the JDK 1.3 era, when HotSpot was still new. They had initially ported a highly optimised C library to Java and found the performance about in line with what this guy got (4-10x slower... actually it was an order of magnitude worse than this until they used the JIT;-). The Java code showed many of the same performance errors that this guy's code has, as is common when you just do a line-by-line translation to Java, rather than rewriting the code from scratch. I did rewrite the code base, and managed to get the performance within the 10%-30% range. Using JDK 1.4 I'd have a few other tricks available to me which would probably get it even closer (maybe even faster).
The -server option actually will imposive significant overhead for this benchmark. The -server option is not going to do any of it's significant optimisations without a TON of work.
All your statements about C++ having an advantage over Java in terms of memory management are silly of course, since the Java runtime performs these exact kind of optimisations with Java programs. Because the decision is made at runtime rather than compile time it is actually possible for the Java runtime to make better optimisations than the C++ compiler/developer (who's decisions all have to be made a priori). I'm not saying this means Java always wins, because it most certainly does not, but I'm just saying that the "disadvantage" you are talking about is actually a misunderstanding of the conceptual differences between these two models.
Dude, the whole idea with the Pringles-can's is that you DON'T use more power, rather you use a bigger antenna. Everyone I know doing the Pringles can setup is staying below the 1w power limit.
The nice thing about using better antenna's (particularly directional) is that you are in not impacting everyone else's available bandwidth.
People who have crashing problems generally have system stability problems. Overclocking, bad memory, cheap motherboards, cheap power supplies, cheap video cards, any of those can cause problems. And by "cheap" I mean low-quality not low price.
This seems unlikely, as a) the problem consistently happened when doing specific activities, and b) the problem was happening on a brand new Dell system using the NVidia card that came with it, c) the problem went away once the new drivers came out, d) Dell support encouraged me to install the beta drivers when I first had the problem, as they said the release drivers were unstable.
Similarly, the problems I'm having with my GeForce2Go are on a Dell laptop that has been around for quite some time. It works fine until I use dual screen, play 3D games, or in any other way take advantage of the more unique features of the card. Whenever the problem happens, XP reports the error as a problem in the NVidia driver. Methinks the overwhelming odds are with a problem in the driver.
Am I the only one who's had problems with some games crashing until this last batch of NVidia drivers came out. For that matter, the last batch didn't include an update for my GeForce2Go (stuck in OEM land), and it *still* crashes a lot.
Slashdot Mirror
It's exactly the claims about number crunching which I'm saying are overly broad given the limitations of your benchmark.
;-) Your benchmark is much more limited than a accurate assesment of raw floating-point number crunching capability. Indeed, I have first hand experience that suggests for some types of floating point problems the performance differences between the languages are far less significant than indicated by your benchmark. Perhaps the best one could say is, "direct ports of short-run, trigonmetric, floating intensive Fortran applications will not run efficently with Java". That's a lot of qualifiers.
Perhaps I've completely misread your conclusions. I thought you said that Java was a poor tool for doing number crunching, specifically floating-point number crunching. If I misread that then I apologise and I'll have to reread, and you can skip the rest of this paragraph.
Certainly you say your benchmark demonstrates that Java's (and in fact it's the Sun VM's optimizations, not Java's, but that's a semantic issue) "run-time optimisations" don't do much for floating point math. Yet, as we've already discussed, and as you knew full well, your benchmark does not exploit these optimisations (otherwise -server should produce a better score than -client).
Hey, I'd be the first to admit that for the job you're doing in this benchmark Java is a poor tool for the task, and that there are plenty of other tasks for which it is ill suited for.
However, the conclusions you draw from this are that Java is a poor tool for a much broader set of applications and circumstances than your benchmark accurately measures.
Certainly, lots of floating point calculations are highly persistent, and take *days* to execute. In many cases, even if they don't take days to execute, the same code is executed with different datasets. These are the kind of problems for with the Sun's Java VM is capable of approaching Fortran and C++ performance. It's known that the optimisations which are applied in these circumstances can improve execution speed by several times. Based on that it's totaly unreasonable to use your benchmark to draw conclusions about Java's overall abilities in high-performance settings.
Your test also times everything including load time for the program. Because you don't isolate out just the floating-point calculations of the code, you don't have adequate controls on the other variables in the execution of your program.
You conclude that Java does not take advantage of processor specific optimisations (it actually does have processor specific optimisations). I don't see how this conclusion could be based on your tests, particularly since the Sun JVM demonstrated significantly more of a performance improvement on the Pentium IV box than gcc or gcj were able to show (indeed they were even better than the performance improvements with the "default" builds with the Intel compilers).
The infamous "lies, damn lies, and benchmarks" (paraphrasing a bit) is not so much about the benchmarks themselves, but how they tend to be used innappropriately to make generalisations well beyond what they accurately demonstrate.
In TowerJ's case, the only difference from the production product is the limited time period for use (15 days). However, I checked it out myself and it appears that if you click through they've actually recalled their downloads program. Now you have to register to get to the code (and they may not even give it to you then).
I can tell you from past experience though that it pretty much killed gcj in performance for this kind of stuff.
Sorry, I misread your post. The problem you are talking about is real, but usually not an issue (because usually if you don't catch the exception the program exits, and all memory is recovered). I thought you were talking about a different problem.
Seriously, if you know Java, you had to know that the stuff you were writing is Java was semantically different (and significantly so) in many ways from the Fortran and C++ code (in terms of what the program was telling the language to do). You also had to know that the way you were benchmarking the code was going to get anywhere near an accurate measurement of Java's overall thoroughput for executing this problem. Knowing that, how can you really feel that this is a reasonable performance assessment of Java?
I agree it's a Catch-22 problem. You will be criticised no matter what you do.
That being said, I'm not sure that you can effectively measure the performance characteristics of a language if you apply idioms to it from another language. It merely measures one language's ability to effectively execute another's runtime model. While this is an interesting measurement in and of itself, it is not an effective measurement as to whether a given language can solve the original problem in an efficient manner.
How's this for a solution: write the program in Java with a focus on the Java execution model, then translate it back in to Fortran. Now you'll have a version in both languages of both programs. This would make you pretty much safe in both camps.
I agree that the trig tests are valid for testing the performance of a given VM, but they aren't a valid reflection of the language. From a language perspective, there is no reason why Java's sin and atan2 functions can't execute as quickly as their Fortran equivalents. For that matter the same is true of C++ (and as you rightly suspect, the Fortran and C++ code that *is* using the same floating point library gets very similar results).
Actually, you can test it even if you don't own it. They provide a free trial download right off their home page.
The -O flag wasn't doing anything that improved performance on a JIT'd system, which is why it was removed. The problem is you're looking for optimisation flags in the wrong space. As long as the compiler is outputing byte codes any performance optimisations it might do are actually quite likely to make things worse. Admittedly, the SunVM doesn't have much in the way of floating point optimisation flags, but that is where performance optimisations kick in for JIT'd runtimes.
Bzzt... You fail!
This is actually a classic example of how people screw up exceptions in C++. Aside from a not using unknown() to handle errant exceptions, the bigger problem is the notion that try/catch blocks are how you avoid memory leaks in C++. Take a look at this old problem to give yourself an idea of some of the complexities with exceptions. While the problem does not create a resource leak (indeed, it effectively LOSES resources), it demonstrates how it can go wrong in the most surprising ways.
While it is conceivable to get everything working right using try/catch blocks, you have to write a ton of insanely structured code, and it's very error prone.
What you want to use is the "resource acquisition is initialization" idiom. Here's some info on it here. It's all about the stack and destructors man.
I agree with your analysis of the C++ code. However, I disagree with your notion that porting line is a valid test of the relative CPU-bound performance of these languages. The program is invariably written as per the preferences of the original language, particularly with some pretty massive assumptions about what is most optimal. Using two-dimensional arrays instead of a Matrix class which is internally a 1-dimensional array is a very good example of this.
Sorry, to clarify, I understand that execution units in modern CPU's aren't very busy. However, this is for the most part not due to deficiencies in the expressiveness of programming languages/compilers. In general, most computer programmers have a fairly linear flow, and even if you wrote the code in assembler by hand you'd be hard pressed to keep the execution units busy all the time.
The original poster was specifically talking about read/write barriers. Fortran has special features which allow the compiler to make some very impressive assumptions about read/write dependancies. These features allow for much more powerful instruction reordering than the kind of stuff you are talking about. Indeed, as he said, these optimisations aren't possible in C/C++ either without the use of the restrict keyword. As I said, the stuff you are talking about is entirely possible to do in a JIT, and is in fact being done in all the major JVM's.
Okay, first of all, for embedded systems this is actually very important. For any embedded system that has to run for years, one of the key issues is that it absolutely must use a heap manager that avoids long-term fragmentation (or have a static heap... but that's another story). Java happens to have a prepackaged solution for this. This, plus small executable size due to the use of byte codes is one of the reasons Java is used for embedded projects.
Actually, the cost of hitting the disk is typically the most important impact on system peformance once you have an app who's working set can't fit into available RAM. That's because access for swapped virtual memory is orders of magnitude slower than virtual memory that in RAM. As you said, most systems today are not CPU limited, but rather memory limited, so switching to another app which also needs to access virtual memory is actually going to make things worse (just try running two programs who's working sets are larger than available RAM and you'll get the idea).
As for memory defragging eating bandwidth like there's no tomorrow, that's only half of the picture. Good GC systems aren't constantly defragging memory at top speed, so the penality is frequently invisible. Smart systems GC when there is available CPU time and memory bandwidth (check out BEA's JVM for example). More importantly, by defragging intelligently you actually increase the chances that sequential memory accesses will hit the various memory cache's on the system (it's really nice when the cache lines are all filled with actual related data instead of unrelated fragments with gaps).
The thing to keep in mind is that the people who write GC systems (or at least the good ones) aren't stupid about how they use memory. They spend a lot of time very carefully analysing memory management issues and put their findings into their system. As a result, most GC systems are better at doing memory management than your average programmer (although there are always special problems where a particular GC will perform particularly poorly).
Actually, some VM do cache friendly management. All of the VM's take care of basic byte-alignment issues.
The instruction ordering for which you need explicit declaration of read/write barriers for are large matrix math operations, and even then it only matters if you've got huge amounts of data parallelism from a vector processor. Everything2 has a better description than I can write. All of the modern JVM's currently do basic instruction reordering just like C++ compilers, and it's enough to keep the execution units in modern CPU's pretty busy. Things like the "restrict" keyword aren't going to help much with that.
As for "-client vs. -server". This is really basic Java stuff. Check out Sun's own docs on the matter. Where to start. *BOTH* VM's are HotSpot VM's. Both behave the way you describe the client. The difference is that the client VM does less profiling of the code and performs fewer optimisations (actually, there are many more differences, but this is what's relevant to what you said). The benchmark taking a "couple of minutes" to run is not enough for the -server VM to really shine. It's designed for programs that at least run for hours.
Finally, it's actually NOT the number of minutes that the code runs that really determines what optimisations are good/bad for performance. It's the number of times the same code is run. And while some of the code is undoubtedly getting optimised, it is not enough for it to get all the optimisations, and it is certainly not enough for the optimisations to outweigh the penalty for profiling that was incurred during the earlier execution.
Believe it or not, I'm not a Java "ZEALOT". Indeed, at my current place of employ I don't write any Java, and I have written more C++ code than Java in general. I would write similar content about other interpreted languages (Self, LISP, APL, Smalltalk, etc.) had the original article referenced them in a similar manner. These kinds of silly, mindless comments come up all the time, and they show a total lack of knowledge about how to benchmark systems, and more importantly a lack of knowledge about the systems they are benchmarking.
He complains about the Java compilers complete lack of optimisation flags (duh... making optimisations to platform independant byte code is pretty useless, and generally counter productive... it's all done by the JRE, which actually has a number of flags for tweaking things, and there are many JRE's to choose from). He talks about how the JIT doesn't perform processor specific optimisations (it does in fact perform many processor specific optimisations, unfortunately his benchmark is written in such a way that none of them will get used). He talks about there being no interest in high-performance Java (the Java Grande group would beg to differ). Best of all, he keeps calling Java an interpretted language... even though he used gcj as part of his own benchmarks... Sigh.
Worst of all he uses gcj without trying out TowerJ, which is a much more established Java-binary compiler. Sigh.
He actually mentions that he has fixed this bug in his article, so I left it out. Plus, I didn't find any place in the Java code where he was allocating new arrays inside the loops (my guess is the code I got was after he fixed this).
That's really not surprising, his benchmark actually penalizes the -server version of Sun's VM compared to a conventional VM. Try using -server, running the benchmark 20,000 times in one process, and benchmark the 20,001st run in the same process. Then the -server option will definitely kick JView all over the place. Also, IBM's VM will probably compare pretty well in this benchmark, not to mention VM's specifically targetted to floating point operations.
I'll leave most of your stuff aside, because I do agree that a lot of silly things are said about Java's performance.
However, your comment that memory fragmentation is not a problem is a major misnomer. For starters, it assumes you have virtual memory, which is pretty hard to come by on embedded systems. Secondly, it assumes that you have an unlimited amount of virtual memory (because that's how much you'd need to avoid fragmentation problems for programs that run for an unlimited amount of time). Finally, it ignores the fact that fragmentation causes additional stress on the virtual memory subsystem which becomes a peformance issues essentially the first time you have to swap a page out to disk.
Okay, first of all, the Java VM is fully capable of doing cache friendly memory management... in fact it can actually discover things about the cache's behavior at run time that are not likely to be known a priori by the compiler/programmer. So it's actually quite reasonable for a Java VM to excel in this regard.
The instruction reordering issues you're talking about tends to only factor in when you have vector-processing CPU's. The limited vector-processing on the CPU's being tested is not enough to break the compiler's back, so it's not surprising Fortran is performing similarly to C++.
Sorry, but my code isn't available elsewhere. However, I point out a few things this guy got wrong in another post.
The difference between -client vs. -server is actually probably the opposite of what you are imagining. -client actually performs more optimisations at class load time, but fewer optimisations overall. This is in recognition of the fact that client programs tend to run for shorter periods of times.
The -server switch actually REDUCES the number of optimizations performed when loading a class. Instead, it adds extensive profiling to all code execution, and then the runtime will gradually optimise frequently executed code based on analysis of how it executes. The optimisations are introduced gradually, almost on an "as needed" type basis. This approach allows the JVM to perform optimisations which simply aren't practical for a compiler to do, because the compiler doesn't have access to the profiling information gathered at runtime. When faced without a JIT, many programmers effectively do peep-hole optimisations of this nature by hand, but they ultimately can't predict what future runtime environments are like, nor can they effectively perform global optimisations on large programs. Of course, there are other differences between -server and -client, but this is by far the most important one.
Hey, I'm not claiming which one is worse for programming in general. The point is that the pervious poster's claim that it's just as easy to avoid creating memory leaks in C++ as it is in Java is ludicrous, as both you and another poster have acknowledged.
In general, you'd be amazed how few leaks do tend to exist in Java programs, even written by relatively junior programmers. In particular, it's a lot easier to write/use libraries or frameworks without creating memory leaks. Sure you can find specific projects where you have a disaster on your hands, but I've actually been on a lot of J2EE projects, and less than 10% of them have exhibited the kind of problem you are talking about, as compared to the 80% of CORBA projects I've been involved with.
...what they are doing.
It's pretty clear this guy is not a Java programmer, or at least has limited knowledge of how to write efficient, well-designed programs in Java. Amazingly, that's actually not relevant. To get to the bottom line skip to the bottom of this post.
For starters, he's using 2-dimensional arrays, so of course Java is going to be slower. 2-dimensional arrays in C++ are actually 1-dimensional arrays with some syntactic sugar thrown in. In Java they are arrays of arrays (really akin to using vectors of pointers to vectors). Experienced Java programmers (and for that matter good C++ programmers) will use a Matrix class to both clean up the code structure and to provide a much more optimised 1-dimensional array structure for manipulations of the Matrix.
His benchmark doesn't have a warm-up run, and doesn't run nearly long enough to cause HotSpot to optimise the code thoroughly. Sure, this is fair if what you're measuring is how well the Java VM can execute a relatively short-run program (quick answer: not very well at all), but it is no indication of the kind of performance that Java can achieve.
The code essentially is not written like a standard Java program (and indeed, is a pretty evil C program if you ask me). I mean, any method with 30+ local variables is suspect in my book (particularly amusing is that some of them appear to be never used). As such, it doesn't play very well against the JVM's optimiser, which is oriented towards Java code with much different structure.
His TEST_LENGTH loop is long enough that he's potentially better off catching an array out of bounds exception than constantly checking the index.
This doesn't affect Java performance, but it's just silly to have a while(true) loop and then have a break on an if at the end of a block is just silly (it might trigger some optimization for a specific, broken C optimizer, but it's just silly to have that on a standard benchmark).
But ultimately this all doesn't matter. Why? Because the bottom line is this benchmark makes heavy uses of standard runtime functions (the trig and square root function). This means that large portions of this code are essentially out of the realm of the compiler, and in the hands of the runtime library. Doing stuff like this I can get widely different results just be linking in different floating point libraries. So, while he highlights the *compilers*, in fact what this is really stressing is the quality of the floating point libraries of the particular runtimes he's chosen. As such, it provides no insight in to the relative merits of using different compilers or languages. At worst, this might be misleading even for the specific application he has in mind. At best it suggests how a few different math libraries perform. The conclusions this guy draws from this are just rediculous.
There is no question that you can have a memory leak in a Java program. However, Java does remove a number of potential ways to create a memory leak that do occur in C++ (heck, 90% of C++ programs I see will leak heap memory if you have exceptions). Anyone who claims that "While it is possible to carefully write a Java program that doesn't leak, I don't think it's any easier than making a leakproof C++ program" either hasn't written a lot of C++, or hasn't written a lot of Java. ;-)
For the record, I actually worked with the JPL evaluating Java's floating point performance. This was in the JDK 1.3 era, when HotSpot was still new. They had initially ported a highly optimised C library to Java and found the performance about in line with what this guy got (4-10x slower... actually it was an order of magnitude worse than this until they used the JIT ;-). The Java code showed many of the same performance errors that this guy's code has, as is common when you just do a line-by-line translation to Java, rather than rewriting the code from scratch. I did rewrite the code base, and managed to get the performance within the 10%-30% range. Using JDK 1.4 I'd have a few other tricks available to me which would probably get it even closer (maybe even faster).
The -server option actually will imposive significant overhead for this benchmark. The -server option is not going to do any of it's significant optimisations without a TON of work.
All your statements about C++ having an advantage over Java in terms of memory management are silly of course, since the Java runtime performs these exact kind of optimisations with Java programs. Because the decision is made at runtime rather than compile time it is actually possible for the Java runtime to make better optimisations than the C++ compiler/developer (who's decisions all have to be made a priori). I'm not saying this means Java always wins, because it most certainly does not, but I'm just saying that the "disadvantage" you are talking about is actually a misunderstanding of the conceptual differences between these two models.
Dude, the whole idea with the Pringles-can's is that you DON'T use more power, rather you use a bigger antenna. Everyone I know doing the Pringles can setup is staying below the 1w power limit.
The nice thing about using better antenna's (particularly directional) is that you are in not impacting everyone else's available bandwidth.
People who have crashing problems generally have system stability problems. Overclocking, bad memory, cheap motherboards, cheap power supplies, cheap video cards, any of those can cause problems. And by "cheap" I mean low-quality not low price.
This seems unlikely, as a) the problem consistently happened when doing specific activities, and b) the problem was happening on a brand new Dell system using the NVidia card that came with it, c) the problem went away once the new drivers came out, d) Dell support encouraged me to install the beta drivers when I first had the problem, as they said the release drivers were unstable.
Similarly, the problems I'm having with my GeForce2Go are on a Dell laptop that has been around for quite some time. It works fine until I use dual screen, play 3D games, or in any other way take advantage of the more unique features of the card. Whenever the problem happens, XP reports the error as a problem in the NVidia driver. Methinks the overwhelming odds are with a problem in the driver.
Am I the only one who's had problems with some games crashing until this last batch of NVidia drivers came out. For that matter, the last batch didn't include an update for my GeForce2Go (stuck in OEM land), and it *still* crashes a lot.