Java Faster Than C++? 1270
jg21 writes "The Java platform has a stigma of being a poor performer, but these new performance benchmark tests suggest otherwise. CS major Keith Lea took time out from his studies at student at Rensselaer Polytechnic Institute in upstate New York's Tech Valley to take the benchmark code for C++ and Java from Doug Bagley's now outdated (Fall 2001) "Great Computer Language Shootout" and run the tests himself. His conclusions include 'no one should ever run the client JVM when given the choice,' and 'Java is significantly faster than optimized C++ in many cases.' Very enterprising performance benchmarking work. Lea is planning next on updating the benchmarks with VC++ compiler on Windows, with JDK 1.5 beta, and might also test with Intel C++ Compiler. This is all great - the more people who know about present-day Java performance, the better.""
Just one game (Score:2, Interesting)
Could use a good analysis (Score:5, Interesting)
I looked at his results page quite extensively, but failed to find a good analysis/justification of the results. Just saying that the Server JVM is better than the Client JVM is *not* enough.
I want to know where the C++ overhead comes from, which Java manages to avoid - does the JVM do better optimization because it is given a better intermediate code (bytecode)? Is it better at doing back/front end optimizations (unlikely given gcc's maturity).
I tried to look for possible discrepancies in the results, but the analysis will definitely take more time - and I think it's the job of the experimenter to do a proper analysis of the results. Liked his choice of benchmarks though.
That just means... (Score:3, Interesting)
I don't actually care hugely about performance (Score:5, Interesting)
I care that Java is an inconvenient pain to develop in and use. I care that I have to start a mini-OS just to run a Java program. I care that the language is under the control of one vendor. I care that the 'intialization == resource allocation' model doesn't work in Java. I care that the type system is too anemic to support some of the more powerful generic programming constructs. I care that I don't get a choice about garbage collection. I care that I don't get to fiddle bits in particular memory locations, even if I want to.
I think Java is highly overrated. I would prefer that a better C++ (a C-like memory model, powerful generic programming, inheritance, and polymorphism) that lacked C++'s current nightmare of strangely interacting features and syntax.
I use Python when I don't need C++s speed or low-level memory model, and I'm happier for it. It's more flexible than Java, much quicker to develop in, and faster for running small programs. Java doesn't play well with others, and it was seemingly designed not to.
Besides, I suspect that someone who knew and like C++ really well could tweak his benchmarks to make C++ come out faster again anyway. That's something I've noticed about several benchmarks that compare languages in various ways.
Re:Sorry, no. (Score:5, Interesting)
If you have a program that runs for awhile (so the startup time is small compared to the time the program takes to run), and does not do intensive output to the console, then Java is a reasonable choice in my opinion. Combined with SWT, Java applications can be quite snappy (see Eclipse, Azureus), and the end user will probably never know the difference.
- shadowmatter
Some performance myths (Score:5, Interesting)
Now, regarding java performance ... Java isn't slow per se, JVMs and some apis (most notably swing) are. Furthermore, JVMs usually have a slow startup, which gave java a bad name (for desktop apps startup matters a lot, for servers it's hardly a big deal). Java can be interpreted, but it doesn't have to be so (all "modern" JVMs compile to binary code on the fly)
Bytecode-based environments will, IMNSHO, eventually lead to faster execution than with pre-compilation. The reason is profiling and specialized code generation. With today's processors, profiling can lead sometimes to spectacular improvements - as much as 30% performance improvements on Itanium for instance. Although Itanium is arguably dead, other future architectures will likely rely on profiling as well. If you don't believe me, check the research in processor architecture and compiling.
The big issue with profiling is that the developper has to do it, and on a dataset that's not necessarily similar to the user's input data. Bytecode environments can do this on-the-fly, and with very accurate data.
What about gcj? (Score:5, Interesting)
-josh
java *can* be fast... (Score:5, Interesting)
I am starting on a new standalone server now doing something different, but I am going to stick with Java, and will be happy to see what 1.5 does for me.
But I have seen Java run slow before, and I will tell you this: in every instance it is due to someone writing some needlessly complicated J2EE application with layer upon bloaty layer of indirection. All the wishing in the world won't make one of those behemoths run fast, but it's not fair to blame Java. Maybe blame Sun for EJB's and their best practices, or blame BEA for selling such a pig.
Stuff I like in the Java world:
Just-in-time compilation (Score:1, Interesting)
Now if only Swing wasn't so bloody inefficient....
Can I have an infinite budget to write the code? (Score:5, Interesting)
We knew java in theory should be worse than C++ at manipulating large blocks of raw data, so we spent some time architecting, prototyping, and profiling java. We quickly learned the limitations and strengths.
The result? After 4 engineers worked for 6 months, we had a program that was rock solid, had more features, had a modern UI, and was WAY faster. Night and day; the old program felt like a hog, and the new program was zippy as anything. And the new code is fewer lines, and (in our opinion) way more maintainable. Since the original release, we've added severeal new features after day or two of work; the same features never would have happened on the old version, because they would have been too risky.
So the question is this? Could we have re-written or refactored the C++ program and gotten the same speed benefits? No doubt, such a thing is possible. But we are all convinced there is NO WAY we could have done it with as little effort. The C++ version would have taken longer to write and debug.
Now you're talking Profiling (Score:5, Interesting)
So, if the JIT computes Hot/Cold Paths, and optimizes the Hot paths, then it should work better and better on successive runs (as more and more profiling information is gathered). On the other hand, there will be cases where it performs worse, as profiles are gathered for specific inputs.
That means that if an average of say 5 runs (on the same input) is taken, it will have an unfair advantage (since gcc did NOT have the advantage of profiling information (see man gprof or similar)). Using Profiling as an optimization tool is *always* unfair unless both tools are provided with the advantage of the same profiling information. This is a valid question for the author then: if the JIT/javac/JVM uses profiling information, gcc should too, for fair comparison.
PS: I have seen this argument being made by my Professor and audiences at compiler conferences.
Re:Caught up with the speed, but still the ugliest (Score:1, Interesting)
Re:Can I have an infinite budget to write the code (Score:1, Interesting)
Right on.
Unix GUIs are far easier to implement with Java than with C++. Athena/Xlib are a huge fargin' hassle and no-one ever gets the widgets right. Motif is too expensive to license.
In my two decades of experience, even multi-million dollar engineering apps still don't understand the concept of WINDOW RESIZING!!!
I wish all Unix GUIs were done in Java.
Re:Caught up with the speed, but still the ugliest (Score:2, Interesting)
You will not be able to get windows cleartype or X11 anti aliasing font smoothing in a swing app.
Sun needs to embrace SWT or make something better ( thats not hard ) but whatever they declare for standard has to honor the platforms native appearance, there is no other way.
P.S: yes i have seen beautiful swing apps, yet they look out of place.
Re:Benchmarks (Score:3, Interesting)
I put it on the web because I thought it would interest others. Even though I put disclaimers on the page, and I try not to make any claims, I see some people say the shootout shows that "language X is faster than language Y".
That claim is probably premature and hence, bogus. I suppose you could make the claim that, in "Doug's word frequency test, on a PII-450 running Linux 2.4, given a certain input, language X is faster than language Y" Assuming, of course, that I haven't made any mistakes. Some of my tests are also arguably poorly designed and meaningless. (Hey, if you have some better ideas, please write to me).
Benchmarks are notoriously misleading, and perhaps mine aren't any better, although I do try. Benchmarks tell you about results in a very specific case. Drawing a general conclusion is problematic.
Re:Sorry, no. (Score:3, Interesting)
Desktop app use cases may be different, in which case your test may be valid. Start-up time is definitely a significant part of the user experience. At one point Java 1.5 was supposed to have shared VMs, so that Java can start at system load time. Other VMs would just then be a matter of forking another process off the already running VM, thus increasing startup time. My understanding is this has fallen off the truck for that release, but people are working on it.
Re:Caught up with the speed, but still the ugliest (Score:2, Interesting)
Apple's swing implementation is pretty fast, good looking, usable and well (but not *fully*, you have to implement your own Apple-W handlers and such, which is i guess to be expect) integrated with the host OS.
Additionally, the support for JNLP/WebStart is very satifictory on both XP and OSX. A fine java deployment techonology that I believe is underrated.
The performance hit is negligible... (Score:3, Interesting)
Re:This doesn't make any sense... (Score:2, Interesting)
The methodology used here sucks (Score:4, Interesting)
This didn't exactly fill me with optimism either:
This would seem to imply that the author does not know much about either shell scripting or Makefiles. I'm not sure I'm willing to trust benchmarks from somebody who can't figure out an automated way to build and run them.Re:Sorry, no. (Score:4, Interesting)
While it is entirely possible [in c/c++] to use a profiler to generate compiler hints so as to generate even more efficient code, this is rarely performed, and often is not free. A VM otoh does get this capability for free.
Additionally, the java memory manager has a slight edge over tradditional malloc's for total throughput (though the best throughput configurations have horrible spuradic response times). It is also possible to choose a different memory manager for c/c++, but this too is rarely used.. Moreover, it is much harder to have 3'rd party code integrate well with a garbage-collector model. Java enforces garbage collection, and thus optionally gets the particular performance gains (being free to trade off throughput for responsiveness no matter what 3'rd part code is integrated).
As was pointed out, one of the strenghts of C/C++ are pass-by-value, which allows memory allocations to be avoided all-together, but at the cost of copy-time and robustness of code. If a method call requires instantiation, c/c++ have the option of passing in a local [stack resident] structure to be populated by the method. However, this is fodder for buffer-overflow exploits, and notorious for otherwise bad code (accidently caching the address of a value that lives on the stack). Thus, given that c++ will use "new" and thus generally perform a malloc, the same performance issues above apply, and c/c++ may have the additional overhead of copy-by-value.
The fact that you have to explicity declare a c++ parameter as pass-by-reference suggests that those interested in "good programming practices" (tm) will only make a pass-by-reference if you intend to modify it's contents. Thus "clean" code in c++ will be copy-intensive... For fairness, clean java code should always make immutable wrappers for any non-modifyable code, thus requiring an all together different liability (and thus I can't make any claims as to which would be faster; wrapper object instantiation or deep parameter-copy). Though all primatives are available in java as immutable objects (Strings, Dates, etc). Moreoever, clean OO-code should always use method getters, and make all fields private (not even protected). Both C++ and jit'd java can inline these getters.
I haven't looked at the benchmark code, but the above are common components which make a big difference when scaling to large enterprise applications, or even when merely writing a glue application which integrates many large 3'rd party libraries. In c++ you don't have a lot of control over the 3'rd party libraries (in terms of their design trade-offs), but with a VM, you are largely sheltered and have many configurable alternatives.
Re:I don't actually care hugely about performance (Score:4, Interesting)
Have you looked at Objective-C? I'm not an expert, but it sounds just like what you describe. As a downside though, I'm not sure how well supported it is on non-OS-X platforms.
Re:Sorry, no. (Score:4, Interesting)
Re:I don't actually care hugely about performance (Score:1, Interesting)
Do you care that you have to start a mini-OS when you use Python? It even has its own command-line. (I like Python, by the way, for scripting. I'm just sayings is all)
Re:Could use a good analysis (Score:5, Interesting)
Most of his tests are big loops (primes, string concatenation, etc.) These are cases where (as a sibling poster mentioned) hot path analysis can do you a world of good. A heavily tuned C++ program can do it just as well, or better, but the point of using a high-level language is that you don't have to do those optimizations yourself; you write the code in whatever way seems natural and you let the compiler optimize.
In a long-running Java program, you don't have that extra layer between the program and the CPU. The JIT does a real native compilation and passes control off to it. Once that's started, it runs just as fast as any other assembly code. Potentially faster, given that the JIT can look at the current run and optimize based on the way the code is going: the precise CPU it's running on, where things are in memory, how far it can afford to unroll a loop, what loop invariants it can lift, etc. It can even replace code as it runs.
The question then is, does the one-time (albeit run-time) optimization do more good than it costs?
That's especially easy on a hyperthreaded system. In a C++ program, these loops will run in a single thread on a single CPU, so if the JIT compiler runs on the other (virtual) CPU, you get its effort for free. Even the garbage collector can run on the other CPU, so you get the convenience of memory management with no total performance cost. (You do burn more CPU cycles, but you use up no extra wall-clock time.)
GCC is very mature, but it doesn't have the option of changing the code at run time. Especially on modern CPUs with their incredibly deep pipelines, arranging your code to avoid pipeline stalls will depend a lot on runtime considerations.
Also, Java has a few advantages over C++ in optimization. It's very easy to analyze Java programs to be certain that certain memory locations absolutely will not be modified. That's much harder in languages with native pointers. Those invariants allow you to compile out certain calculations that would have to be done at runtime in a C/C++ program. You can even start spreading loop cycles over multiple CPUs, but I'm pretty certain that the present JVMs aren't that smart.
These results are toy benchmarks, and not really indicative of real performance, even on purely non-GUI code. But I wanted to outline the reasons why the results aren't just silly, and they do have a theoretical basis.
Re:The Great Computer Language Shootout (Score:1, Interesting)
Re:Can I have an infinite budget to write the code (Score:2, Interesting)
I'm currently coding in C# (which sucks arse) and Java for object tracking in video. The Java code rocks - it's simple to write, it works and it's really fast. Video processing uses lots of loops with runtime constants which the hotspot JVMs seem to generate extremely fast code for.
You are eliminated the whole point of profiling. (Score:3, Interesting)
Re:One example of why the tests are BS (Score:2, Interesting)
The point he's making is that the C++ code is poorly written, and that might well affect benchmarking.
Also, if the activate function is virtual (no way to avoid it in Java), this is a runtime vtable lookup in the loop, whereas for a statically allocated object the address of the function would have been fixed at runtime. Granted, the cost is probably negligible to that of activate's implementation, but (a) it's impossible to know without actually profiling the code, and (b) the activate()'s implementation is likely to be as poorly written as the code that calls it.
Of course, all of this implies I was too lazy to actually look at the activate()'s code...this is Slashdot after all...
Re:This doesn't make any sense... (Score:3, Interesting)
I don't understand why if you can "just in time" compile it, you can't just compile it at build time and get it over with.
You can, of course, and there are Java compilers that do (e.g. gcj). What this benchmark really demonstrates is that doing it may be suboptimal. Sun's JVM does something more than "just in time" compilation, it also does interpretation and profiling. The first few times a bit of code gets executed, the JVM will not just-in-time compile it, preferring instead to interpret the bytecodes and gather some statistics.
After the same pathway has executed enough, the JVM will decide that it is a "hot spot" that will benefit from compilation to machine code. This compilation, however, will be performed with the benefit of the runtime statistics that were gathered while interpreting the code. Assuming that future executions will have characteristics similar to past executions (generally a reasonable assumption), the JVM will create machine code for what it knows is the typical execution profile.
This profiling and late optimization is where Java gets the chance to beat pre-compiled code, after it's warmed up, anyway.
Very good programmers who know their compilers and processors can do the same thing with compiled languages like C and C++. In fact, they can do a far better job because they have a better understanding of what the program does. However, that sort of optimization is hard work, error-prone, not very portable and interferes with maintainability.
The JVM doesn't optimize as well as a good programmer, but it's a whole lot cheaper.
Re:Caught up with the speed, but still the ugliest (Score:2, Interesting)
-
P.S: yes i have seen beautiful swing apps, yet they look out of place.
I guess it's a matter of taste. You may prefer that your java app looks the same as the other apps around it at the time, but I prefer my java app to look the same on my windows machine and on my linux machine.The main flaw of such benchmarks... (Score:3, Interesting)
shenanigans (Score:1, Interesting)
However, the new guy gets:
Somehow this new guy's tests conclude that Java is 10x faster than C++ in the exact same test? I call shenanigans.Re:A few points... (Score:5, Interesting)
A couple points:
- The "Great Shootout" benchmark times are sometimes way off because the run-time was too short to get an accurate reading. In those cases the tests should have been run with higher values to really stress the machine. That doesn't appear to be an issue in this test though (assuming his graph values are in seconds).
- Many of the C++ tests are not optimized. That is, they use C++ features like the iostream stuff (cout, and friends) which is extremely slow. The C versions are available and very fast. C++ is pretty much just an extension of C. You don't need to use C++ features if they slow you down. Another one is the hash stuff. In the C++ hash benchmark there are some goofy mistakes made by using the brackets [] operator where it forces several unnecessary lookups. You can also substitute a better STL hashing function that is faster (like MLton's insanely fast hasher).
- The test could be done by comparing C to Java. Anything in C++ can be made as fast as an equivalent C version but there are not many programmers that know how. Just assume anything in C++ will run as fast as a C version, and if it doesn't then you did something wrong. The hash tests would be easier in C++ though. If they were written properly they would kill the Java version.
With that said, I'm going to try these tests myself because I do not believe the results to be accurate. but who knows...
Re:Expert results (Score:5, Interesting)
"I was sick of hearing people say Java was slow, when I know it's pretty fast"
Nice, unbiased viewpoint there...
Explanation (Score:5, Interesting)
Reviewing the console log, we find that when java programs were tested with a large number of iterations, Java only performed better on one test.
I know that Java has many strengths, but speed isn't one of them. Looking at the results, we see the g++ runtimes are much more consistent than those of Java - on some tests, the Java Server is faster than the client by a factor of 20!? How could a programmer code without having any realistic expectation of the speed of his code. How embarrassed would you be to find that your "blazingly fast" app ran slower than molasses on the client machine, for reasons yet unknown?
When it comes to speed, compiled languages will always run faster than interpreted ones, especially in real-world applications.
But discussions of language speed are a moot point. What this really tested was the implementation, not the language. Speed is never a criteria upon which languages are judged - a "slow" language can always be brought up to speed with compiler optimizations (with a few exceptions). I suspect that if C++ was interpreted, and Java compiled, we'd see exactly the opposite results.
In short, the value of a language consists not in how fast it runs, but in what it enables the programmer to do.
LEA! LEA! The guy's name is LEA! (Score:2, Interesting)
Re:Can I have an infinite budget to write the code (Score:2, Interesting)
C# doesn't have checked exceptions.
C# allows the use of pointers.
C# has pass by reference.
C# has one major IDE (Visual Studio) which has a RAD philosophy which *does* prevent some valid C# code being written.
C# has properties a-la Delphi
C# isn't portable.
C# has a bitmap class which is as slow as hell compared to the Java equivallent.
C# has operator overloading
C# doesn't have inner classes that can access the members of their container clases
C# doesn't have anonymous classes
C# has delegates
There's just the differences I could pick off the top of my head.
A lot of the really significant differences aren't in the core language (though there are a few of those, which mainly strip back the safety and simplicity that Java provides) but in the libraries and IDE.
The IDE is really buggy and it forces RAD concepts on the programmer (shades of Delphi) which is a pain in the ass if you want to concentrate on code.
There are *plenty* of reasons to like Java and not C# - they are *not* "exactly the same"
Function calls (Score:5, Interesting)
For example:
[bdr@arthurdent tests]$ time
165580141
real 0m3.709s
user 0m3.608s
sys 0m0.005s
time
165580141
real 0m0.006s
user 0m0.002s
sys 0m0.002s
I think a lot of these benchmarks are showing that the Hotspot optimiser is very good at avoiding function call overheads.
Re:been there, done that (Score:3, Interesting)
Comment removed (Score:2, Interesting)
Re:Caught up with the speed, but still the ugliest (Score:4, Interesting)
Non-graphical Java code can indeed be very competitive with other languages, but it would help if the author bothered to implement the code for his tests intelligently.
The Fibonacci code is recursive, which is about the slowest possible way to implement it, and much of the other code uses high-level features of C++ which are a convenience for the programmer, but are not used when worried about speed.
This fibo code, for example, should be faster:This code was turned in by a student in a lab of mine. This was his first semester in CS, and this code outperforms the Java code quoted on the website considerably. (Try it!).
I am not saying that recursion and high-level C++ features should NOT be used, but I AM saying that if you are comparing the potential speed of languages, you should use tricks that each language provides to optimize speed.
Java will never be faster than properly optimized C++ compiled with an intelligent optimizing compiler except in bizarre corner cases, and tests like this are not terribly convincing demonstrations otherwise. Even the corner cases are removed by a sufficiently talented programmer.
This is also not to say that Java is bad. I think Java is a great language (except for GUI programming with SWING), and definitely makes many programming tasks faster to code and easier to debug than one can do in C++.
Timing strategies (Score:3, Interesting)
First of all, the C++ was crappy as many people pointed out.
Second of all, I'm sure that loading the C++ program takes some time more than just loading the byte codes (though that's probably mitigated somewhat by the byte code translation).
Third, the optimization options he used for gcc are a joke. -march=i686 is not even relevant to much larger platforms that can benefit from other optimizations.
And, 4th, and this is the big one, this guy does not know how to benchmark. Anyone who has actually benchmarked their own application knows that if you want to figure out how fast something is, you have to time it IN THE PROGRAM!!!! This would avoid allocation/cout/unnecessary function overhead, when all you're trying to test is a specific operation. I BET (and at some point I will test this) that if you used timing mechanisms INSIDE the programs, that C++ would come out much faster, with the exception of object management and memory stuff (excepting garbage collecting...). Even then, much of that stuff can be overcome by memory pooling, which a surprising number of people ignore.
Until someone does something like all these language comparisons are totally pointless because you are NOT ACTUALLY BENCHMARKING the topic you are looking at. Please lets have someone be intelligent about this for once....
Java == modern COBOL (Score:2, Interesting)
Thats what it should be benchmarked against. Comparing it to C is like comparing apples and oranges.
Re:More info, after some testing (Score:3, Interesting)
java-server: 14.93user 0.10system 0:15.67elapsed 95%CPU
g++-O2: 8.10user 0.03system 0:08.38elapsed 96%CPU
That places g++ about twice as fast as java, at that benchmark, assuming the code is correct.
C++ 60X Faster Than Java (Score:2, Interesting)
The Ack function was being called over and over with the same arguments. A little work with an STL map, and I created a cache for the function arguments and results. I think this is called memoizing a function.
Here are the results when I finished:
Same for hash.cpp (Score:5, Interesting)
This guy is a tool.
Re:What are -client and -server? (Score:3, Interesting)
It does mean something. However, here's something a little odd about the differences between C++ and Java: in C++, the compiler makes the decision about what to inline before it fully knows what is calling what. That is because the compiler runs before the linker. So C++ is working with more limited information. Meanwhile, the Java virtual machine has everything integrated. The compiler (the JIT) and the linker (the class loader) and the loader (also part of the class loader) run all together and can cooperate and communicate.
Why is this important? Because the C++ compiler must make all kinds of guesses when it makes these optimizations. If you have a 1-line function, it probably makes sense to inline it in every place it's called, because the speed will increase and the code size won't (the inlined code will probably be smaller than the code to make a function call). But say you have a 25-line function. Should you inline this? If it's called only in one place and nowhere else, it's still more efficient. But if it's called in 50 places, you waste a lot of space by making 25 copies of the function. So maybe you should inline it only in the one or two places where it counts. OK great, but which two places are these? The C++ compiler is left having to just guess. The Java virtual machine can instead just observe the program as it runs and *know* where inlining is worth it and where it isn't.
Also, what if you have a really small function in a library and you want to inline that? Well, in C++, if you dynamically link to that library, you *can't* inline the function. It's just not possible. But with Java, you can, because it's all just classes that are loaded by the class loader and then translated into machine code as needed. So you can inline functions that come from dynamic dependencies, like system libraries.
And then, as someone else said, Java can even inline virtual method calls! How can it do this? Again, by observing the conditions the code is *actually* executing under, not by theorizing about all possible conditions it might execute under. C++ has to allow for the possibility that every object is a different class and so must use a v-table. But Java can, in theory at least, know that while the object *could* be an instance of class X, Y, or Z, in reality the class loader has only loaded class Z, so therefore all instances must be instances of class Z. Presto, inlining is possible, at least until class X or class Y is loaded. But then, since the code is generated dynamically, when you load class X or Y, you could trash the inline code you generated and start over with virtual method calls now that you are having to plan for a different situation.
I should point out that you can get 99% of these performance boosts in C++ by hand-tweaking your code. You can figure out which methods need to not be declared virtual and remove the "virtual" keyword from those methods. If you need to make an inline call to some function in a system library, you can manually copy the code from that library into your source code and call it, as long as you're willing to rewrite and rebuild your C++ app when the library code (that you copied) changes. So these things are theoretically possible, but they are such a code maintenance and system administration nightmare, that they are virtually always far from practical. But with Java or other similar languages, they can all happen for you automatically behind the scenes.
Not silly at all (Score:3, Interesting)
But when you are trying to choose the right tool for a particular job, you need to be current on the details of just what advantages, and what degree of advantage, and in what circumstances, comparing current versions of all of the candidate tools.
This benchmark seems to be showing that things don't just remain the same. That, in fact, the circumstances in which C++ is a better choice than Java are becoming fewer and the advantage in those circumstances is becoming less.
The fact that Java VMs are primarily written in C or C++ indicates that at the time they were initially written, it was believed (I think correctly) that the C or C++ at that time would be a better platform for writing JVMs than the Java of that time, and that since then it has been considered better to extend the existing code than to scrap it and do a complete rewrite in Java.
That's all that this argument proves. Nothing more.
What I'm saying, though, should not be interpreted as a belief that today's Java would be a better choice than today's C++ for writing a Java JVM. I don't know what the relative advantages would be today.
But if C++ were STILL the best tool for writing a JVM from scratch today (certainly possible), that wouldn't mean much when trying to choose a tool for your own app, because most apps bear very little resemblance to a JVM.
Re:Um, it's online (Score:2, Interesting)
Now, the other question is why use the ? operator at all? It's no faster than an if statement in a case like this. This code fragment would be much easier to read, for example:
if (m == 0)
return (n + 1);
else if (n == 0)
return Ack(m - 1, 1);
else
return Ack(m-1, Ack(m, n-1));
(Please imagine it's indented properly because slashdot's ecode likes to strip spaces)
The other benefit to this code is it should be clear to even the worst optimizer what it can optimize and what it can't.
ABI compatibility (Score:2, Interesting)
It's a benchmark. We're benchmarking performance.
Correctness comes before performance. Failing to link at all by no means produces good performance because a test of performance on incorrect code is an invalid test. Using one C++ compiler to compile your system libraries and another C++ compiler to compile your applications will often result in either failure to link or incorrect code because of subtle ABI (application binary interface) differences among C++ implementations.
On the other hand, the Java platform ABI is well-defined for several years now.
And would you grant that the benchmark is a valid test of Sun's implementation of the Java language vs. the G++ implementation of the C++ language?
PCs are LBAs, and Halting for LBAs is solved (Score:2, Interesting)
If you hand me a correct algorithm for the halting problem, I'm sure it could be coded in C++ so it ran faster than in Java.
A Turing machine modified to have a limited-length tape is called a Linear Bounded Automaton (LBA). A PC is equivalent not to a Turing machine but to an LBA. There does exist a correct algorithm for the halting problem when applied to LBAs: emulate two copies in a tortoise-hare configuration and look for loops in their state.
Re:Um, it's online (Score:5, Interesting)
Write a java app that does nothing but repeatedly call System.gc(). Run it with the -verbose:gc option, and watch the garbage collector go. Mind you, this is not 100% proof, but the fact that it prints out [Full GC] over and over again makes me lean pretty strongly in the direction of "the garbage collector actually runs in response to a System.gc(), it's not just a hint".
One thing I would like Java to do is to allow me to delete objects manually. There are times when the garbage collector really sucks, but 95% of the time it's sufficient, in my experience. And yes, this experience comes from real-world apps.
Regarding the original topic, I would bet that there are cases where Java really could give C++ a run for its money. However, one liability that Java has compared to C at least is that making everything an object adds a whole lot of object overhead. I had to write a file search routine as part of a Java app, and originally wrote it strictly in Java. The sheer number of File objects that get created by such a routine is ridiculous, and there's really no way to reduce the overhead by reusing the objects -- File objects are immutable. Calling out to JNI resulted in a 3 to 5x performance boost. Does this one example prove anything? No, but it's a heck of a lot more real-world than simply appending a string to itself a few dozen times...
Re:Some performance myths (Score:3, Interesting)
Just in this case, it sucked much more than usual. -O2 is no match for something that does automatic loop unrolling and function inlining. And the loop unrolling doesn't even get enabled in -O3. My own preference is to start with O3 and enable loop unrolling and omit-frame-pointer, which seems to make a noticeable difference.
Re:Um, it's online (Score:3, Interesting)
He spoke *a lot* about 'efficiency', and IMHO, he did have a valid point. He compared C++ to C and FORTRAN and made good arguments why C/Fortran is slower than highly optimized C++ code nowadays (Because of the amount of information a C++ compiler can collect about the program's structure... in C everything is flattened to a low level by the programmer already and information is lost for the compiler).
Asked after his lecture if there are plans for a virtual machine for C++ (as an *alternative* to native code), Mr. Stroustrup strongly denied that. I think this is one of the more important reasons why Java is considered 'better' by many people. Because it *seems* that, with the VM, it's more portable. There is clearly not engineering reason for a C++ VM, but politically, it would give C++ the opportunity to gain ground against Java.
You have to, of course, use appropiate C++ paradigms, like templates emulating lazy evaluation etc. A "naive" matrix class in C++ is nice to write, but not very efficient to use.
Even if you cry out loud that efficiency doesn't matter any more, it's, at least somewhat, wrong. It's an arrogance of the programmers against the users of their programs. If one programmer saves 10 hours of time but for each user, using the program takes 10min longer (be it startup times or whatever), it's time-inefficient if only 100 people are using the program. And you have to take into account that the time of the users adds up more easily than that of the programmers. They're probably not running the program once, but multiple times...
Of course, java has it's uses, e.g. client-side interfaces running in the browser.
But the argument, stated over and over again, that Java is/can be faster because of runtime optimizations, is *really* flawed and just ignoring facts. There are compilers which can do optimizations on profiling data from the actual running program. Beat that java. A compiler tailored to the machine *and* the beloved runtime optimizations.
the halting problem is related (Score:3, Interesting)
What we're talking about here is converting recursive to iterative without using the friggin' stack. That would be finding a mathematically equivalent function that is not recursive. This looks pretty much equivalent to the Halting Problem, or Rice's Theorem for that matter. Trivial for a person in some cases like this, but not easy to generalize.
If there are heuristics to do that effectively, that I don't know. I will check that document you link to when I have the time.
In this case, result caching would do. Result-caching takes memory but it makes sense sometimes (not that often, mind you). One of the problems I see here is memory efficiency isn't considered at all. It's ok if your machine is 100% dedicated to a fancy benchmark, but running some memory-hungry java processes like this in parallel would make your computer start thrashing to the HD to a virtual halt.
Re:Um, it's online (Score:1, Interesting)
It suprised me that this was not the default and yes the startup time is slower but it is dramatically faster when running.
Re:Um, it's online (Score:2, Interesting)
Efficiency matters, but sometimes it doesn't come in the obvious ways. To set the tone, here are a few examples.
The Bubble sort takes only a few lines of code and has no significant memory requirements. A QuickSort takes 50 to 100 lines of code and uses a recursive algorithm requiring a stack of some sort. Yet for some reason many applications choose the QuickSort.
Virtual memory imposes a huge performance penalty on the system. Every memory access has to be translated into the physical address. Page tables take up a significant percentage of RAM. They complicate systems programming significantly. And somehow we would never dream of designing a serious system without virtual memory. And even after adding a FOURTH level of page tables, somehow the AMD64 is able to outperform the two and three level 32 bit chips.
Running software at different privilege levels introduces a huge penalty of context switching. An OS call, which cost only 4 to 10 cycles under DOS, now costs 1000 to 3000 cycles under a "modern" OS. Why would we actually prefer such gross inefficiencies?
Instead of setting up a direct cable link for data transmission across the US, which would create a direct link of only 3000 miles, many industries find it more efficient to sent the data 52,000 miles into space to have it bounced back by satellite.
The fastest way to get a missile from here to Russia is also via a trip into space.
What I'm trying to get at is that there are a lot of cases where the best solution looks wasteful until you get the big picture. You and I understand how a 4 level system of page table lookup can end up outperforming even a direct memory access scheme for some tasks, how kernel/user mode is a significant and necessary part of modern programming, even at the huge cost it adds to system calls, and how going the "long way" can be faster than the more direct route. So don't be afraid to consider alternatives that don't appeal to you at first glance.
So you don't like Java and other inefficient VM-based systems, and you don't believe that it can be faster? Yes, there are many systems for analyzing runtime behavior and using that data to perform static optimizations. But there's no reason Java can't apply those same optimizations. On the other hand, there are optimizations that Java can do that you CAN'T do with static code. For example, Java can inline a function across a shared-library boundary (this is a HUGE win). Java can remove expensive security access checks for an application that is already running at full trust level. Java can optimize the generated code for the current processor - Pentium 1 through 10? SIMD? Super-SIMD? MMX or no? Floating point? All of these cases can be handled really well by Java, and it can pick the instruction mix that matches your system perfectly. The static code generator has to make some compromises. You can load a different DLL for each processor, but honestly you can only distribute so many flavors of your library... and they'll be obsolete the next time Intel decides to change its optimization strategy. Running on a single proc system? You can seriously simplify your synchronization primitives, saving a LOT of cycles on multithreaded code. Lots of memory? Java can trade space for speed. Tight on memory? Java can trade speed for space. And it can change its mind from day to day, depending on what other apps you have running. The list goes on and on. Not all of the above optimizations have been implemented in production JVMs yet, but they have all been researched, and they aren't theoretical -- there are real performance tests that show they can make a difference. They just need a few more years to be built into the next generation of VMs.
A few other areas that people often don't think about: Bytecode is usually significantly more compact than the resulting machine code, especially on RISC chips. Throw in
Re:Um, it's online (Score:3, Interesting)
I wish I could find what I originally read. It stated that it simply issued a request for the gc to collect. Under a high load (tight loop, in this case), chances are, the gc will not collect. Accordingly, I have no problem finding many posts by "java gurus" which seem to be under the same impression I am (that clearly doesn't make it true though). Also, even here, others have piped in and offered that gc is run in a low priority thread whereby, the "hint" is actually a mechanism which attempts to wake up the gc, assuming it's not already running. Thusly, while I do agree that calling System.gc() on a one to one basis is not fair (clearly not an apples to apples comparison), I'm still not convinced that simply calling System.gc(), and it returning, means that all memory has been collected.
Regardless, I do believe I have a legitimate point and that these benchmarks are fundimentally flawed.
Re:Write a JVM in Java??? (Score:2, Interesting)
bootstrapping (Score:3, Interesting)
When you understand bootstrapping, you'll understand how one would create a JVM written in Java. (IBM did just that.) It's not a question of whether it is possible, but what the pros and cons would be.