Slashdot Mirror
Java Faster Than C++?
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.""
The Java is Faster than C++ and C++ Sucks Unbiased Benchmark
Correct link
No, it isn't. It's much slower.
I wrote a program that simply counts to 10000 and then quits. Time from double-clicking the icon until when the program exits:How hard is that?
I just happened across Sun's FAQ about the -client and -server settings .
He claims you should use the server JVM instead, stating that it is faster but slower to startup and consumes more memory.
Java's strength is mostly it's cross platform compatibility. I have never really liked C++ very much. It seems complicated to write cross-platform code with C++. (Header troubles, and all OSes seems to have it's own implementation. Ie. try to compile Linux code on FreeBSD, and opposite) As a conservative coder I therefore prefer C, which is as fast as you (the coder) make it.
True, which is why the eclipse project (www.eclipse.org) created and maintains SWT. A portable native widget tookit. See http://www.eclipse.org/articles/Article-SWT-Design -1/SWT-Design-1.html for more info.
Don't forget strip -s
Oh... and as of Java1.5, Swing apps can now be skinned to look however you'd like them to.
File under 'M' for 'Manic ranting'
unreal uses a java like scripting language, but its for gameplay code, not the actual rendering, however, i think that's as close as it comes right now. (the java like stuff is something like 20x as slow as the c++ code, cause of the overhead etc)
P.S. a lot of gameplay code is also in c++ and compiled into dll's (i believe), but mods dont have access to the headers to compile c++ code into the game readily.
Java isn't "emulation". Modern JVMs use a JIT (just-in-time compiler) to translate bytecode instructions into pure binary assembled object code just before it is reached in the program (hence "just in time"). This is cached, so the next time that particular code is executed, it will run at full assembler speed.
Something I've often wondered is whether this caching could be persistent, i.e. be kept between runs of the JVM. Eventually, the entire program would be translated to pure assembler with the cost of translation largely amortised across many sessions. You still keep the safety, cross platform compatibility and ease-of-programming of a bytecode language (i.e. Java, C#) but you get the bonus of the cached object code being just as fast, even during startup and shutdown.
One of the best things about OS X is Aqua-ized Java apps.
o nc eptual/Java141Development/UI_Toolkits/chapter_5_se ction_2.html
http://developer.apple.com/documentation/Java/C
-- Have you ever imagined a world with no hypothetical situations?
This means nothing.
That is the most typical benchmark of somebody who doesn't know anything about compiler optimization.
This is almost truly a mark on the compiler making an optimization in one case where the Java compiler doesn't. Assigning to an unused variable is a useless operation. A decent compiler removes the assignment, then notices an empty loop, then removes the loop.
Not to mention, your double-click takes into account the entire VM initialization, which greatly, greatly outweighs the test itself, rendering the test useless on that account as well.
So you end up benchmarking the entire VM initialization with a NOP. Gee, wonder which one's going to win?
This is why benchmarks are hard. This is why the SpecINT benchmarks are notoriously bad as they (at least were) easy to optimize against.
By the sounds of it you have no idea what a good GUI is. Skins and themes do not a pretty UI make.
*sigh* have you people never heard of runtime optimisations? There are some things you can optimise at runtime (like runtime constants) which are *impossible* to optimise at compile time.
This whole "x is written in y, so x can't be faster than y" rubbish is just that - rubbish.
Ummm, wrong. The majority of java class libraries, and (significant parts, if not all) of the compiler are written in Java. There is, of course, some C++ for doing really low level stuff, but not the amount that you're implying.
Xenon, where's my money? -Borno
1) javac (Sun's Java compiler) is written in Java. You can even access it programmatically at runtime if you really want to.
2) While it's not an id game, IL2 Sturmovik is a critically-acclaimed fight simulator that was written almost entirely in Java.
Out of the box Swing is amazingly ugly. The people choosing default colors at Sun could well be substituted by a randomizer without a difference in results. I mean, who was the genius who thought purple bars in a menu were cute?
Now, when you need to change that quickly and without much overload, there are ways. A little known global HashTable called UIDefaults lets you change just about everything on the visual interface without having to write your own LookAndFeel (which you obviously can do too, for very large projects). You can have your scrollbars, menus, etc in any colour, size and shape, using any font. You can easily change all default colours without having to set every control. After a while the ugliness ceases to be a problem.
Seeing things like this:is hurting my eyes.
This page has more information about this horrible malfeature.
________
Entranced by anime since late summer 2001 and loving it ^_^
The article says he used GCC to compile the C++ versions, but GCC produces code that isn't nearly as good as the Intel compiler for example. (Here, but no good if you don't subscribe)
A lot of the test results are close, and I think a different compiler would change the outcome.
Also check out SkinLF from L2FProd - it's a library that makes it very easy to use GTK themes, KDE themes or even both together to make a very nice native-looking interface. I use it with ConsultComm and have had very nice results.
I agree with you. This does not match my experience at all. The Java programs I have used (especially anything with a GUI) have been bloated and much slower than programs in C++ that do 10 times as much. I would be curious to see if these benchmarks included things like opening windows, pulling down menus etc.
Magnus.
Because c# is faster than Java, and Java is faster than c++, then by transitivity, C# is faster than c++. To back up my claim that c# is indeed faster, I cite as my source a researcher at cornell: http://www.cs.cornell.edu/vogels/weblog/2002/11/24 .html
I think you have some fatal flaws in your C code. Your string buffer isn't long enough to hold what you are doing. And they aren't doing the same thing. The first code is going to count to 10240. The second code is going to display ascii characters from null through to character 255 and then do some very bad things.
Bad code, BAD!
IMarv
Trusting software vendors is no smarter than trus
g++'s goal is modularity for ease of porting in cross-platform cross-compiling. aggressive optimization is not one of its strengths. the point of such benchmarks is really not a language comparison, but a comparison between the code generated by the most optimized compilers for that language on a specific platform. Using g++ for this simply causes the study to lose credibility
We use Xith3D (primary written by our main client developer), a Java3D workalike. Xith3D was spun off in response to Sun's news that Java3D would no longer be supported. Sun's decision may have been reversed; I'm not entirely sure.
Anyway, we have slick looking 3D that performs just fine; comparably to other engines. It's on top of an API (Xith3D/Java3D) that sits on top of opengl.
There have been several good 3D java games displayed at the GDCs, stuff from FullSail and GetAmped.
By the way, the project is currently going through a lull as I work on another side project (an online yard sale) and the primary client developer has had to leave the team to spend more time with his family. Send us a note at jobs@magicosm.net if you want to help out as a developer, 3D artist, system administrator, or (especially) investor!
I know you're joking to make a point, but you do realize that 1 isn't prime, right? That's not just a matter of arbitrary definitions; a lot of theorems that apply to primes don't apply to 1.
You might think that the two are the same, but the two settings actually make a visible impact if you're running on a multi-processor system. Most notably, the garbage collector and locking primitives are implemented differently.
The Raven
Sure, there's java port of Quake 2, there's Alien Flux, Tribal Trouble. But, as others already mentioned Java is mostly used for programming game logic. It's performance is constantly improving and only recently it gained enough speed to be seriously considered for writing entire game engines.
You would do it if you need a scrap object only sometimes (and didn't want to pay the overhead penalty of instantiating it every time the proc got called). Here's an example:
void foo() {
}
G-Force music visualization
g++ isn't great at optimizing. For code I write it's somewhere between 0 and 50% slower than MSVC. It depends a lot on the type of code of course. For pure numerical work I think the Intel compiler usually scores highly so I'm surprised you're not seeing much difference.
Doesn't it make you feel good to know that our freedoms are protected by politicans, lawyers and journalists.
The cout is done twice, and the new and delete are each done only once. They are not the reason for the poor performance.
The problem is that g++ probably does not optimise it all inline, whereas the particular java VM he has chosen to use probably does.
Although defining the Toggle variables with auto storage class may give g++ the hint it needs to realise this.
Additionally, the activate method is declared to be virtual, this shouldn't be a problem, except that it may further hide the optimisation opportunity from g++. Note that the description of the test does not stipulate that it is testing virtual methods.
In the bulk of his results, C++ on an i686 beat out the CLIENT JVM every time except in two tests. Object creation and word count. In the object creation test the code is biased towards Java. He's creating the objects AND DELETING THEM in C++, but Java's garbage collection probably isn't doing the deletion at all.
The other test is the word count. This one is interesting because he sets the streambuffer to 4k in both Java and C++. But in the C++ version the stream won't preload to fill the buffer. So the amount being cached is UNKNOWN. I can't speak for the Java version but I bet it preloads the entire file.
That leaves the Server JVM switch. In which case I think you're seeing alot more code inlining then the standard C++ compiler generates.
Either way, this is hardly a definitive test.
The results might shock you.
The Raven
Ah. I see. I'm used to using strings or ints as keys in std::map functions.
::hash_map, but the ::map lookup calls a function in this case. using k->second would dereference an ESI pointer to memory, which is faster than an inline call to a member function. not sure if hash_map does the same. yes?
Most C++ programmers would do that. Then again, most C++ programmers would also bother to deallocate the arrays returned by strdup(), too, so I guess this guy isn't a C++ programmer.
I don't normally use hash_map because it's not in the g++ 3.1 distro (my company mandates this version).
IME, most people don't use hash_map, since it's not standard. My understanding is that it will be standard in the next revision of the C++ standard, so maybe it will gain more popularity then.
Is there another source for free STL implementations out there besides the archaic SGI STL?
Ever used STLPort? It's supposed to be pretty decent, considering that it's free.
not sure about
You're right. It probably would improve performance to some measurable extent. The previous post stating otherwise is probably wrong.
Windows nowadays *is* very stable. I've been working as a systems administrator over Windows NT, 2000, XP, and 2003 Systems for about 2 years now (obviously I haven't spent that much time on 2003...) and you know what? Except for one really screwy problem that later turned out to be memory-related, I have never had stability problems with those flavours of MS Windows.
Ok that's not entirely true. I've seen Windows stability problems. They were the result of user stupidity like truckloads of spyware and hard disks with no space left.
And as far as "idiotic debug statements" go, GCC holds the frikkin crown for those. When java compiler or runtime crashes, it tells you more about what went wrong than C++ does...perhaps the reason you see amateurish java programs is that the amateurs and programming students are switching from C++ (a language no one should use unless they're supremely gifted as a programmer) to Java (a language that saves them from their own stupidity).
------- "From bored to fanboy in 3.8 asian girls" ----------
java is JIT compiled not interpreted
It's not the benchmark's that count. It's the programs I need to run. Every program I've tried that's written in Java takes longer to start up than one written in C/C++. Althought that may change with .Net :-)
Java has gotten better though. The programs are usable now days. (Just have that start up time as the virtual machine loads.) Use to be the programs loaded slow and ran slow.
Coder's Stone: The programming language quick ref for iPad
I could not run the test for 10M, but ran it for up to 1M. 541 milliseconds in one case, 280 in the other. Here's the code I used (I had to modify the timing cause I'm running XP):The only difference in the class Strcat besides the class name is the instantiation of StringBuffer.
NB: I'm not accusing the author of bias against Java, nor am I ignorant of the fact a bunch of
Information: "I want to be anthropomorphized"
Intel gives their c++ compiler away free for non-commercial hobbyist use on linux.
The windows version has a free trial that runs for 30 days.
Try it. See if it makes a difference. If it doesn't, torch it. If you find it makes your critical code run 2x faster, then... have a look at what a computer that runs 2x faster will cost you, and then decide what to do.
Because -O3, despite what many people say, doesn't very often generate faster code. In many cases the extra inlining can create slower code.
For example:
methcall.cpp -O2 1.8s -O3 1.8s
fib.cpp -O2 3.7s -O3 3.7s
matrix.cpp -O2 1.8s -O3 1.8s (interestingly, adding -march=athlon-xp for my machine reduces time to 1.5s)
Or he could download Microsoft's optimizing C++ compiler for free.
erm ... I only checked the fibonacci routine, but it's actually quite funny - he's branching recursive calls, a clear case when a smart-enough runtime optimization would work better. I mean, any reasonably smart optimizer would eventually figure out that there are too many calls to the same function with the same argument to just stand by and watch. I'd say that given this difference c++ did quite alright in that one.
This is known as the "halting problem". No, the compiler cannot guarantee the ability to transform a recursive solution to a non-recursive one. The case of the fibonacci algorithm is a particularly difficult one to transform properly if the compiler hasn't special cased it.
That said -- Ack and Fib are call overhead limited. They examples of poor quality code whose performance is not inner loop based.
Hash will be C-string (specifically strcmp and sprintf) limited in performance. The performance is therefore very data dependent (since Java uses length delimited strings.) Using a fast string class such as "The Better String Library" (http://bstring.sf.net) would have yielded C++ far better performance. A similar comment applies to the strcat test.
The Heapsort is a particularly bad implementation. In good implementations, the Intel compiler really takes gcc to town. See: http://www.azillionmonkeys.com/qed/sort.html
Integer Matrix multiplying is an extremely rare application. So I wouldn't put too much stock in the results here -- though, I would be surprised if there was much differentiation between either Java of C++ on this test.
The method calling, I think, will be very much limited by the compiler's ability to inline past method calls. I think Intel C/C++ differentiates itself on such things.
The Nestedloop and random tests are interesting -- I don't see how Java is supposed to beat C++ on it, but its possible to be equal.
I don't know enough about the Java object system and barely enough about C++ object system to comment on sieve or objinst.
It seems to me that sumcol and wc are going to be IO limited.
I don't think this test is exactly fair, as the code is not representative for tasks where performance really matters.
Oh, wait, you can't do that because nobody can write Halting.
I guess that means there are some algorithms for which you can't write a faster C++ version. Next time, try less rhetoric and more facts. "There exist lots of algorithms for which I can code a C++ implementation that's faster than a Java implementation" is good. The instant you make a unilateral statement like the one you just made, though, it shows that you don't know as much about computer science as you think you know.
Fact: there exist cases where Java is faster due to its ability to optimize on the fly. And if you know C++ as well as you think you do, this shouldn't surprise you. C++ beats C so handily for many tasks because C++ is able to do much better compile-time optimization largely on account of the C++ compiler having access to much more type information than a C compiler. When Java beats C++, it's on account of Java having access to much more information about runtime paths than a C++ compiler. ("Much more" may be an understatement; C++ doesn't even try!)
In other words, the JVM (sometimes) beats C++ for the exact same reason that C++ almost always spanks C; the faster implementation has access to more information and uses that information to make more efficient use of cycles.
I don't think these situations will appear all that often, and I am deeply skeptical of this guy's "in the general case, Java is faster" conclusion. But my skepticism isn't leading me to make rash statements which cannot be backed up.
Almost no C++ implementation calls the OS (kernel) for every memory request, precisely because that's too slow.
More to the point, C++ doesn't *have* to use dynamic allocation so often, but in badly written code it may well do so, and that will hurt performance. In C++ you can drop objects on the stack, in Java you can't. Heap/GC allocation can be pretty quick, but not quite as quick as stack allocation.
Check out this recent IBM Developerworks article which looks at how modern JVMs handle allocation and garbage collection.
Some very surprising tidbits there. For instance:
"Performance advice often has a short shelf life; while it was once true that allocation was expensive, it is now no longer the case. In fact, it is downright cheap, and with a few very compute-intensive exceptions, performance considerations are generally no longer a good reason to avoid allocation. Sun estimates allocation costs at approximately ten machine instructions. That's pretty much free -- certainly no reason to complicate the structure of your program or incur additional maintenance risks for the sake of eliminating a few object creations."
Read the article for an excellent nuts-and-bolts analysis of many current performance considerations. From the posts in this thread, it's pretty clear a lot of people haven't looked into what's actually done in a server JVM these days.
>When it comes to speed, compiled languages will always run faster than interpreted ones, especially in real-world applications.
It's a bit simplistic to call Java an "interpreted" language. A Java source file is compiled into bytecode. Modern JVMs then take this bytecode and use a Just In Time compiler to compile it into machine code just before it runs. Naturally this is a bit of overhead up front, but once the class is JITed, it will perform on the order of natively compiled code written in another language.
I agree with you - the only business apps I've seen that really NEEDED C++ were some very tight-loop mathematically intensive things where the 2x-4x performance difference imposed by lots of array bounds-checking became a limiter to performance optimization with the Java VM implementation - and that was easily solved by a small chunk of JNI code implementing the iteration over the arrays.
I believe you can declare a java method or class as "final". This optional behaviour is like C++'s default behaviour.
BTW. I looked at the "shootout" article when it first reared its ugly head. I recall the Python code looking like it had been written by someone who had read 3 chapters of "Teach Yourself * in 21 Days". Utter crap.
You can never equivocate too much.
This paper describes the performance issues we encountered when developing FreeTTS. I think it is a pretty good representation of the issues involved in developing a high-performance Java application along with a comparision between a Java and a native-C version of the same application. This paper describes how we ported a native-C synthesizer (Flite) to Java (FreeTTS) and how were able to get better performance from our engine.
This is not a toy application but a real application that performs well in a domain where performance really matters.
Converting objc -> c is trivial -- There are a number of objc -> c converters.
:)
Actually I think that might be how most of the compilers actually work
So if you like Objective-C and would rather code in it... you can!
You've got it wrong. This is correct:
const double sqrt5 = sqrt(5.);
const double gold = (1.0 + sqrt5)/2.0;
const double goldi = (1.0 - sqrt5)/2.0;
int fibonacci(int n)
{
return floor((pow(gold, n)-pow(goldi,n))/sqrt5);
}
For n > 5, you don't need the goldi part.
Suppose that during a particular run, there is a particular variable x that, whenever we look at it, always has the value 42. Now we want to compile a method that uses that value. A JIT can optimistically assume that value will always be 42. Now it can go to town on optimizations involving that variable. Got an "if(x > 10)" statement? You can omit the compare and branch. Got a division with x as the denominator? You can omit the divide-by-zero check, and turn the divide into a cheaper multiply-by-reciprocal. And so on, and so on. Then, you register your assumptions with a runtime service that is capable of re-compiling the method of your assumptions turn out to be incorrect. If you ever see that variable with a value other than 42, you recompile it (and do some fancy footwork to deal with threads that might already be running the obsolete version).
What you end up with is a method implementation that a static compiler just could not produce. Perhaps, if it were very smart, it could use profile-directed feedback to create a specialized version of the method for each of a number of "likely" values of x. However, unless you want to try to cover all 4 billion possible integer values, you must include a backup version for when you turn out to be wrong. Plus, you'll always have the overhead of choosing which of the specialized versions to call in the first place. This is all overhead the dynamic version doesn't have.
So it is definitely not impossible for a dynamic compiler to outperform a static one. It is just very rare, given the current state of the art of compilers.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
Are you trolling or what?
This is known as the "halting problem". No, the compiler cannot guarantee the ability to transform a recursive solution to a non-recursive one. The case of the fibonacci algorithm is a particularly difficult one to transform properly if the compiler hasn't special cased it.
No it's not. In fact, it's not even close to the definition of the "halting problem". The Halting Problem is "Given input X, and program Y, will Y ever finish it's calculation, and halt on when given X as an input". It's a 'problem' for which no computer program can be written to solve.
It has nothing to do with whether or not a compiler can convert a recursive algorithm into a non-recursive one.
That it's possible to convert looping programs into recursive programs is trivially true, because recursive functions alone are Turing complete. Similarly, because any recursive program can run on a Turing machine, which has no concept of a 'stack' needed for recursive calls can run any recursive program by emulating the stack on it's tapes.
If you want a real world example, just compile any recursive code in any language to MIPS or some other RISC instruction set without push/pop and call functions like those found on X86 chips. You don't "call" functions directly, you just move around in memory and jump all over the place, just the same as you would in looping code.
autopr0n is like, down and stuff.
At last count, Kuro5hin was closed to new users. Therefore, K5 is not a general purpose discussion site. New users have mostly gone to K6 instead.
Gcc is designed for compatibility with a wide range of architectures, and is not optimized for a single one. He also (apparantly) used stock glibc from Red Hat. And only one "test", the method call test, showed java to be a real winner. And even then, it's server-side Java, which is meaning less when you talk about it as a day-to-day dev language (ie; creating standalone client-side apps).
Intel's (heavily optimized) C++ compiler should be a damn sight faster, and so should VC++.
This is a slight misrepresentation. gcc actually does quite respectably on x86 platforms -- its easily as good as MSVC++, and its clear that the gcc people have put a lot of work into this compiler. Of course, the Intel C++ compiler is truly awesome and leaves pretty much every other x86 compiler in the dust, but this is really a case of Intel just putting a truly amazing effort into their compiler rather than anyone else comming up short.
The real issue with these tests is that pretty much none of them have real computational inner loops. They all measure unlikely program overhead that could easily be removed with any reasonable rerendering of the code.
One of the most important reasons software has advanced is exactly BEACUSE of information abstraction - API's, object-oriented computing.
In my experience, it's not a bad thing to be beholden to an API author. The author(s) likely know the system better than you. It's one of the things that helped humanity advance in general - specialization. It shouldn't be taken to the extreme, of course, SOMEONE has to know how the stuff works, but not most programmers.
Assembly language is good to know, but many (most?) coders will not ever have a need to touch it, unless they are doing embedded design or compiler development. There are much more useful things to learn for those of us that write software. For example, I am absolutely shocked at the number of students who graduated with me that had taken a SPARC assembly class (required), but knew zero about relational databases. (Although to be fair to my alma mater, Penn State, I believe that situation has since been rectified.)
By the way, I know assembly. MC68k as an undergraduate, a year of MIPS architecture as a graduate.
For example, sin() calls in MSVC lead to single FSIN assembly instruction. But INTELs FSIN instruction is known to be quite inaccurate/incorrect with certain range of angles so G++ inserts code before and after FSIN which corrects the result to be more accurate. (this feature can be disabled with --ffast-math switch).
Yes, the GCC compiler. However a JVM is an interpreter.