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
how does it corner?
Fact: C++ is dying....
Oh hell, I don't have the heart. Nevermind.
Quantum materiae materietur marmota monax si marmota monax materiam possit materiari?
Here's some kindling...
vi is better than emacs
bsd is better than linux
gnome is better than kde
.
.
.
anything else?
oh yeah...
my dad can beat up your dad.
And you smell funny.
Rhymes that keep their secrets will unfold behind the clouds.There upon the rainbow is the answer to a neverending story
i tried to get first post with my C++ autoposting application...but its too damn slow.
I just happened across Sun's FAQ about the -client and -server settings .
...on x86? Please! Wake me up when someone who knows enough about C++ to pick a decent x86 compiler runs some benchmarks.
Doesn't it make you feel good to know that our freedoms are protected by politicans, lawyers and journalists.
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.
Java and C++ are language. Languages aren't "faster" or "slower", but compilers for them might be. I find it somewhat underhanded to put the languages in the header when it's really comparing compilers.
Not to mention, inter-language compiler benchmark[et]ing is notoriously difficult to get 'right'. The programs tested are often stupid (doesn't do anything meaningful), or constructed by a person with more skill/bias for one language than the other.
"My arse" is a good name for this post since that's obviously where your head is stuck - much like the rest of the /. morons with their anti-java-no-matter-what stance.
I used to be a C hacker and a laughed at Java when it came out because of it's poor performance. Times have changed, but the language bigots haven't.
It's been ages since I've programmed in C++, but it's good to know see these favorable comparisons. I think about the Struts/Hibernate/Oracle applications I write today and shudder when I imagine what how difficult it would be to have to develop web applications in C++. C++ will be around forever and certainly has its place, but long live Java.
I think you're missing the point. I bet 19 seconds of that execution time was the start-up and shutdown of the virtual machine. As the program gets bigger and bigger, this becomes less and less significant.
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'
There seem to be some unanswered questions here..
- How equivalent were the benchmarks? Where they programmed in an optimum way for their respective compilers and libraries? I'm sure the java ones were.. what about the C++ ones? The author states he doesn't understand G++ very well.
G++ is also known to not produce the best results.
"I rant it with -O2"
My guess is many of the tests were not implemented properly in c++.
The main clue would be this... I can understand java having better than expected performance.. but there is no way I can accept that java is that much FASTER than properly done C++... it doesn't make any sense.
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.
An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
I’m sorry but someone who says "I've never been very good at decoding GCC's error messages" is not competent enough to perform performance comparison. This performance test is a shame and shouldn’t be taken seriously.
-----
One is born into aristocracy, but mediocrity can only be achieved through hard work.
You were running Swing with the Windows L&F.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
That's Great! I can't figure out GCC's error messages, but I offer definitive proof that Java is faster than C++. Nice.
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.
You're measuring startup time, not execution speed.
Duh.
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.
Need a Python, C++, Unix, Linux develop
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?
Comparing one C++ compiler (gcc) against the Java JVM on one operating system is not much of a test. I love Java, but this is almost something like microsoft would do. Test one specific OS, compiler, and configuration, and then make a blind, far-reaching statement. A fair test would include several platforms and compilers.
I don't want to start a holy war here, but what is the deal with you Java fanatics? I've been sitting here at my freelance gig in front of a Java program (running on a PIII 800 w/512 Megs of RAM) for about 20 minutes now while it attempts to copy a 17 Meg file from one folder on the hard drive to another folder. 20 minutes. At home, running an equivalent Visual Basic program on my Pentium Pro 200 with NT 4, which by all standards should be a lot slower than this Java program, the same operation would take about 2 minutes. If that. In addition, while it is running, Netscape will not work. And everything else has ground to a halt. Even jEdit Lite is straining to keep up as I type this.
I won't bore you with the laundry list of other problems that I've encountered while working on various Java programs, but suffice it to say there have been many, not the least of which is I've never seen a Java program that has run faster than its VB counterpart, despite Java's faster runtime system. My 486/66 with 8 megs of ram runs VB programs faster than this 800 mhz machine runs Java at times. From a productivity standpoint, I don't get how people can claim that Java is a "superior" language.
Java addicts, flame me if you'd like, but I'd rather hear some intelligent reasons why anyone would choose to use a Java over other faster, cheaper, more stable systems.
From methcall.cpp:
int
main(int argc, char *argv[]) {
int n = ((argc == 2) ? atoi(argv[1]) : 1);
bool val = true;
>> Toggle *toggle = new Toggle(val);
for (int i=0; i<n; i++) {
val = toggle->activate().value();
}
cout << ((val) ? "true" : "false") << endl;
delete toggle;
val = true;
NthToggle *ntoggle = new NthToggle(val, 3);
for (int i=0; i<n; i++) {
val = ntoggle->activate().value();
}
cout << ((val) ? "true" : "false") << endl;
>> delete ntoggle;
return 0;
}
Why allocate and deallocate an object within the scope of a function? Well, in C++, there's no reason, so this is bad code. You can just declare it as a non-pointer and it lives in stack space. But guess what? You can't do that in Java: all objects are allocated on the heap.
That, and using cout instead of printf, are probably why this is slower than the "equivalent" Java.
-_-_-
There are 0x40000000 types of people: those who understand 32-bit IEEE 754 floating point, and those who don't.
*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.
Please point me to a source which verifies your claim.
The Internet is full. Go Away!!!
First, it's been known for awhile that Java is a poor performer when writing to the console, for whatever reason. Second, your Java timing probably include the time to startup the VM (not that this is wrong).
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
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.
The Raven
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
This would be much more meaninful if you had used fputs() instead of write() in the C version.
As for "several orders of magnitude," I call bullshit. There's no way in hell the standard C++ IO functions are hundreds of times slower unless they're extremely badly written. Which leads me to another reason why this example sucks: there can be different implementations of the standard libraries.
In conclusion, this "comparison" is a stinky pile of shit, and should be ignored. And it's not even on topic, since it doesn't have a Java version.
Why did he use the strdup function when he already has the char array from the previous sprintf?? That step incurs a huge and unnecessary penalty w/an allocation, just pass the pointer!
Also, in the second 'for' loop in hash2, he does extra work beacuse he already looked up (*k).second.
shouldv'e done hash2[k->first] = k->second;
Tell me I'm not crazy.
https://www.accountkiller.com/removal-requested
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.
I'd be interested in comparing the speed of the native code generated by gjc to the that of JVM.
-josh
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:
All you programmers that say you can do anything in Java/C#/etc are terrible.
Actually you can do most anything in those languages. Although for performance, and desgin reasons you may wish to use something else depending on the application.
You have no respect for code. Learn assembly and then we'll talk.
I know assembly, and fun as it is, it isn't well suited for high level projects where code reuse and mantainability are important. By the way, I have no respect for someone who knows assembly and thinks it is difficult. It isn't. And it certainly isn't graceful or elegant, but I love it all the same.
"It's always been written in Java."
;P
Except for the first Java compiler.
https://www.accountkiller.com/removal-requested
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.
I believe that Sun's javac bootstraps itself just like gcc does. That would be your java compiler written in Java.
_Jikes_, OTOH, is written in C++. But that's not really the official Java compiler by a long shot.
Your second requirement is absolutely bizarre. Does this mean you're not taking languages like Lisp, Prolog, Python, and Perl seriously, too? Those are all very nice languages for doing stuff in, but I'm pretty sure id never wrote a 3D engine in them. In fact, I was under the impression that id has never written a 3D engine in C++, either. Should we not take C++ seriously?
IMHO: The measure of a language is not how easy it is to write an arbitrary application in it. It's how easy it is to write something for which the language was designed to do.
-Erwos
Plausible conjecture should not be misrepresented as proof positive.
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.
Here is my experience with C++ vs. Java: At my company, we had a specialized image viewing program. The original program was written in C++ years ago, and performance sucked even on modern machines. It probably had a dozen man-years of time in it. We decided to re-write it in java.
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.
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.
An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
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
A few examples
1) Java has bounds checking for arrays, C++ doesn't. This is specified in the language. This affects performance.
2) Java has garbage collection, C++ doesn't. This is specified in the language. This affects performance.
Also, the specification of Java says that it should be compiled to byte code and executed in a JVM.
So the "language" certainly affects performance.
The Internet is full. Go Away!!!
I can say after using SWT in the Pocket PC platform that it sucks. The widgets are primitive, lack any real model implementation, they brake compatibility between minor versions, the most advanced things are done in the Eclipse UI packages not in the widget toolkit and the code you end up writting is ugly.
Elaboration:
No model: with swt you get the widget as a UI object with a field of type Object that you may or may not use as a reference to the object dislpayed. You ahve to write the code that updates th view when the underlying object changes and hende there is not real MVC pattern there. You can do it yourself. Imagine the huge pile of repeated effort in many projects around the world.
Primitive widgets: the table widget is just a string grid. No masked text input, and it goes on and on.
Ugly code: they use public fields for setting state to widgets not constructors or factory methods or even setters. They have integer constants for decribing widgets and you have to use those and see them. Creating a label requires using new Label(SWT.LABEL) and creating a horizontal Line is new Label(SWT.LABEL | SWT.HORIZONTAL). So much for hiding complexity.
There are 4 type of layout managers, the initialization is verbose and in fact only 1 are relevant, GridLayout, the other 3 are special cases of the former.
The more advanced widgets are not in SWT, only in the Eclipse centered custom libraried. The SWT mantainers say those classes are for use in the eclipse UI and they don't mean thme to be general purpose, use thej if they fit, but don't ask for improvements.
The only way SWT is justified is when you have very low resources (a pocket pc) or need to compile with gjc. Otherwise, Swing is way better even when it is far from pefect.
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
From comments Doug Bagley made about the "Shootout" (where the benchmarks came from), no, I don't think it is an accurate comparison, or at least a conclusive comparison between C++ and Java. His comments from his conclusion:
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.
Why did he use only -O2?
-O3 adds function inlining and register renaming.
Also, some of the code doesn't look too much of a test of the language, but more of a test of the libraries. Both versions of hash rely on the library implementations, and it looks like hash.cpp does an extra strdup that the java version doesn't. I don't know either of the hash libraries well enough, but I don't see why this significant slowdown would be necessary in the gcc version.
HIV Crosses Species Barrier... into Muppets
One X-factor is JVM warm up. When benchmarking Java you should run the test multiple times in the same VM. This gives you a better real-world feel of what a Java app will do during continuous use, at least from a server perspective.
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.
======
In X-Windows the client serves YOU!
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 "comparison" is so limited in scope and meaning, that this writeup should be considered a troll.
Hell, read his lead-in:
Ie; I set out to prove Java is teh awesome and c++ is teh suck!
If anything it proves something I've known intuitively for a long time. gcc does not produce x86 code that's as fast as it could be. That's a trade-off for it being able to compile for every friggin cpu under the sun.
I can't wait till RMS takes personal offense and goes on the attack.
I don't need no instructions to know how to rock!!!!
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!
Okay, so how could I make a blanket statement like that? In this case, the author of the paper merely used a compiler switch in gcc (-o2). That doesn't mean his c++ was highly optimized. It just means he told the compiler to do its best. If you really wanted to highly optimize c++, you would study the compiler and how it works, and you would profile the actual assembly that the compiler generates to make sure that it didn't do anything unexpected. Given *any* algorithm, I can come up with a c++ implementation that is faster than a Java implementation. Period.
The java compiler actually compiles to a virtual opcode format, which is then interpreted by the java virtual machine at runtime. Imagine if you needed to talk to someone on the phone, but instead of talking to them, you had to talk through an intermediary. Is there any possible way that it could be faster than talking to the person directly?
Now, I'll be the first to point out that a badly implemented c++ algorithm could be much slower than a well implemented Java algorithm, but I'll take the pepsi challenge with well written code any time, and win.
Relying on benchmarks and code somebody else wrote doesn't prove anything. Did he get down and dirty with the compiler and look at the generated assembly code? No, he did not.
Move along, there's nothing to see here.
WWJD? JWRTFA!
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.
But until it is bundled by default with the JVM and JDKs, it will still be hassle to get SWT working for normal users. If Sun replaced the swing toolkit with SwingWT and linked it to SWT, I would think there would be a great improvement in performance of most Java GUI apps (and most of them really do suck - the only good one I have seen is MoneyDance).
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.
Depending on the application. I will gladly trade the write-once-run-almost-anywhere advantage for a little heavier application, within reason. (Sun's "soundtool" java app is a sadistic waste of reason) Not having to support multiple platforms, compilers, Licenses, IDEs, utility applications, etc, etc is a big plus too. Java's inbred sluggishness is not cause to ignore the advantages it offeres in other areas. I also like the idea of having some competition in the commercial development arena again.
boycott slashdot February 10th - 17th check out: altSlashdot.org
For years it was "Java is too slow" Now it's too ugly??
Sheesh.
I'm sure one of Swing (with it's several different look and feels and skinnable interface) or SWT or AWT will fit the bill.
If you are going to do that just make it run through and compile the entire thing in one shot rather than doing it a small bit a time. Then the end user won't have to experience the "just in time" part of the compile. 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.
Pocket PC Games
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.
If one program uses profiling information to run faster than another, it runs faster nonetheless. I agree with other posters that this is comparing compilation & runtime environments rather than languages, but when I care about how fast a program runs I care about how fast it runs, not how fast it would run in some hypothetical nonexistent environment. C++ would probably be faster if it had some kind of JIT environment to run in, but it doesn't, and as a developer trying to write fast software, that's what I care about.
That said, I doubt the performance differences are enough to affect my decision about what language to use, unless I am writing some application that does enough computation that a person has to wait on the program, rather than the other way 'round.
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."My life's work has been to prompt others... and be forgotten." --Cyrano de Bergerac
I'm inclined to agree with you, except that the benchmarks were qualified as talking about being relevant to enterprise applications. In such a situation, run-time optimizations are critical.
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.
-Michael
No, it doesn't. Check out WordPerfect Java, Novell ConsoleOne, or any other large Java project for a real world counter example. Java applications are slow to load for any meaningfull piece of client side software. Java works wonderfully for middleware applications but is simply the wrong tool for client side software. When I can reboot the computer and load MCC faster than I can start ConsolOne there is something seriously amiss (and no jokes about having to reboot, I have windows PC's with 200 day uptimes limited only by patching sessions, which is true for any properly maintained OS).
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
> By the sounds of it you have no idea what a good GUI is. Skins and themes do not a pretty UI make.
Since Swing has all the GUI elements of every other toolkit, what would make a pretty UI if not skins/themes? A bad design can be done in any toolkit if the designer doesn't have a good sense of layout, etc.
Presumably the java compiler inlined the function call. Do the math-- 4e9 function calls in 2.5 seconds. That's 1.6e9 function calls per second. On a 3.0 GhZ machine that's two cycles per call, so they're probably all inlined.
In response to what many of you have and will write:
.class to native code you really have native code directly executing.
-- there is not necessarily any "extra layer" created by the JVM. the whole idea is that the JVM is actually a run-time compiler, and when it's done compiling the
-- the JVM runtime compiler can perform optimizations that are not available to a C++ compiler. for example, if the JVM realizes that there is only one instance loaded of an abstract/virtual class it can compile all the code that accesses it statically against that single code, as if there were no inheritence at all, saving a pointer reference. a C++ compiler can never do that because it does not know what you will link against.
-- Many of you are simply going to find ways to criticize Java because you are religious. You used to criticize performance, and if that is taken away from you, you will say it was never really important and criticize something else. You need to think whether or not you are being objective and rational, or simply theocratic.
-- Yes you could likely optimize the C++ code better. Some suggested replacing the inefficient cout's with printf's but that is really eliminating the ++ part of the C++ language. If you can't take advantage of C++'s OO features then there isn't any point in comparing the language with Java--without those higher level features you are programming in the 70's. Guess what, assembler is even faster. So it is fair to compare C++'s high level features with Java.
-- Repeat: Some of you are simply religious.
Well, you'd better tell your mom to switch perfumes.
Well.. maybe. Or Maybe not. But Definitely not sort of.
The -server mode of java causes the JVM to recompile code for the most used code path. I have not looked at the exact code for each of the tests, but in many cases this can result in the JVM optimizing out the code completely. You have to be extremely careful when doing benchmarking of languages like java because the JVM is able to dynamically recompile the code to remove the actual work, if the results of that work are never used.
~Giliath
I have two decades worth of programming experience, using most of the languages out there.
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.
Why is it "unfair" that Java is actually able to profile what is being run, vs. a static compiler having to guess? That is a very real advanatage of Java and should not be "leveled out" of the test. The benefit given by that technique is exactly what I would like to see.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
When C/C++ uses profiling it will only ever produce one "best case" compilation for a given function.
With any JIT system you have the opertunity to use the profiling information from a given "window" of the execution so there is the possibility of having more than one compilation for a function.
Now, I do not know how sophisticated JAVA JIT compilers have become but this is one area where JIT will have an upper hand over a static compiler.
OTOH, these tests do not look like there is enough significant variation in the execution path for profiling to make a large difference.
anything else?
Yeah, Kuro5hin is better than Slashdot.
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.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
No, I'm not being ironic.
I'm tired of some programmers expecting to be worshipped because they know assembly.
Assembly isn't all that.
For some uses, it is the right tool. For 99.9%+ it most definitely isn't.
The Internet is full. Go Away!!!
For example, Java with its JIT can easily match a C compiler on bit-banging and number crunching small data sets when there's no memory allocation going on. However, that isn't what most people are waiting for when they run typical interactive applications.
If a system is not I/O bound, most applications tend to be doing a lot of string manipulation or similar operations on small objects. When Java operates on strings, it tends to create, discard and garbage-collect a large number of short-lived string objects because Java's strings are immutable. This consumes quite a bit of CPU and memory.
Some C++ applications are written the same way. Many KDE applications are rather sluggish, probably because they are taking advantage of a lot of automatic management of a lot of QT objects. STL-based C++ apps can also be sluggish if you use high-level containers like tree maps without a keen awareness about what kinds of extra copying and thrashing can happen under the hood when you use them. Even in C, if you use high-level libraries, you can get sluggish performance, as some of the more bloated Gnome apps demonstrate.
However, C++ programs, even STL-based ones, may also be written in a different style that takes advantage of mutable strings and handles object allocation manually. This tends to reuse data structures in place, eliminating memory management overhead, and it has the very important effect of keeping caches and page tables much more localized. This is more bug-prone than the alternative, but can provide a substantial performance improvement that Java can't hope to touch on a similar dataset. The drawback is that the app is much more likely to crash unless it was written by a top-notch developer; in fact, this kind of programming is the cause of many of the security problems plaguing the various OSes over the years.
(People often point out that nobody writes kernels in Java. That's because they tend to be written using the manual memory management style with as many static data structures as possible to squeeze out more performance. People don't use popular high-level C++ libraries to write kernels for the same reasons.)
Bottom line, the answer to which language is faster will always be "it depends". It depends on what the program is doing, and it depends on how the program was written. A couple of datapoints from a language shootout don't help to resolve the issues.
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.
You really need to look into Qt. It's much easier to use than Swing.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
-
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.You are once again spouting the tired old line that Sun is the master of Java. Not at all true, Java's fate is controlled by a whole host of companies - including IBM. Take a look at the reality of Java platform evolution at the Java Community Process web site.
It's a standards body just like any other, just more open.
P.S. - Aside from that gripe being wrong, I agree with the other poster that you should look into Objective-C to address other issues. Look for "GnuSTEP" for cross-platform objective C GUI work. It's just nicer to use on a Mac as they have very good tools (though in fairness I have never looked at what GnuSTEP tools might be around, I just can't imagine them being quite as good as the tools Apple has sunk so much effort into!).
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I had similar experiences writing a Swing app around six years ago (just around the release of 1.2). At first the Swing app was a little slow, but after a number of rounds of profiling and tuning it was really, really fast - with an MDI interfance and a lot of heavily customized controls on very busy forms. The app worked great even on slower computers, and was well received by the client.
There is no reason Java has to be slow. It's just prone to having a lot of layers stuck on things when they might not need to be. As you say, for a lot of work people are doing J2EE stuff may well be overkill (though even that can work with simialr efforts to tune).
Basically, with any VM app tuning is key. As C# people are only just now starting to realize... a shame the tools there are a lot more primitive that what Java has to offer.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
is not just using the right compiler and right options, but the bechmark codes they use. Just look at this bench mark, are they really C++ codes? Are they the type of the codes that pushes the programmer to use the most advanced techniques? I for one, use C++ because of Boost, because of Blitz++, because of not having a garbage collection mechanism. Why these benchmarks never use a code to calculate some really challenging processing like a series of operations on large matrixes of complex numbers? Why they don't try benchmark where you have to allocate and free a large number of nodes in a large scale graph traversal and coloring program? Why they don't try to see how ESPRESSO performs in C++ and Java? How about large scale FFTs? Raytracing? Finite elements? JPEG compression and decompression? You can get any results you wish in comparision of any two languages and implementations as long as you don't write even a single routine of real-world code.
What concerns me most is the amount of memory it requires. In theory, once the requisite stuff is loaded into memory, Java byte code can be processed at nearly the same rate that C++ code is. Depending on the bytecode and assembly that are generated in each case, Java or C++ could end up being faster. I think it's obvious that Java incurs some overhead in translating the bytecode, which ought to slow it down *some*, but that amount can be minimized.
On the other hand, Java takes a great deal of memory. If C++ had a dedicated server sitting in memory, ready to execute commands for it, it probably would speed up execution, but that wouldn't mean C++ were faster.
After accepting the memory hit for Java, the performance on things like apps servers seems to be pretty decent. I have yet to use a java client application, however, where I didn't feel that it was sluggish (even after loading). There are only two explanations: all java code is written poorly, or Java inherently causes a performance hit.
As we abstract languages more and more, we see performance hits for increased functionality and ease of developing. We also see that, because of the easier development, it is easier to improve scalability and use more efficient algorithms. It is rare that a program cannot be sped up by hand-optimizing the assembly, but it is also rare that anyone has time to design the much more critical optimized algorithms at such a low level. Therefore, I predict that eventually Java (or something like it) will be embraced as programmer time matters more than speed of execution.
The one thing that disturbs me about Java is that, while in C++, it is easy to change the assembly while maintaining the C/C++ code, in Java, you are tied to platform-independent code, which prevents you from doing platform specific optimizations. You have to depend on the native java implementations and/or widget toolkits for those kind of things. And so far, although the situation is improving, I've been pretty unhappy with the speed and my ability to improve it.
-Dan
C++ is as cross platform as the libraries you use. The game code i'm writing so far (it's a simple game, doesn't have any assmebly or optimisation... just a keen like side scroller) compiles under both windows and linux. Using the same make file. How? I use SDL for everything. I've had equally pleasent experiences with Qt. Portability in C and C++ is all based on the libraries.
Of course being able to compile on multiple platforms and being cross platform aren't the same thing but I still think that it is in the benefit of people producing software for Linux specifically, to write code that will port to Windows without to much avail (who the hell uses \?)
The Neo-Bohemian Techno-Socialist
i did read the article, but i kinda think i'd need to see more than one source as well as hear comments about any flaws in the tests before accepting this as the new order.
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.
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.
The society for a thought-free internet welcomes you.
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" ----------
I just wrote two programs to count to 1 billion. The one written in C took 2.4 seconds, the one written in assembly took 0.85 seconds. Wow, assembly is so much faster. My in-depth analysis of these two languages has shown once and for all that all us high-level language suckers need to get back to coding in assembly and quit this HLL foolishness.
"No one likes working in a hamster wheel, and your shop smells of cedar shavings from here." - TaleSpinner
LEA was "Load Effective Address" for the 8086, and it was a fast (and obscure, sidey-affecty) way to speed up a certain set of multiplication (and combo multiplication/addition) operations, which I now forget. Where's Abrash when you need 'im?
Almost exactly the same?
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"
Whew, there's seems to be a lot of denial running through this thread. "An interpreted language just can't possibly be as fast or faster as a compiled language! So I just don't care what the empirical results say, no matter how badly or well done they are, it just can't possibly be!"
I think some of you are overlooking the fact that a VM running byte code is capable of doing optimizations that a compiled language just can't possibly do. A compiled language can only be optimized at compile time. Those optimizations may be very sophisticated, but they can never be any better than an educated guess about what's going to happen at runtime.
But a VM is capable of determining exactly what is happening at runtime; it doesn't have to guess. And thus it is able to optimize those sections of code that really are, in true fact, impacting performance most severely. In can do this by compiling those sections to machine code, thus exploiting precisely the advantage that a compiled language is alleged to have by its very nature. And other kinds of optimizations, the kind that a compiler traditionally does, can be performed on those sections as well.
Of course there are scenarios where runtime optimization doesn't win much, for example in a program that is run once on a small amount of data and then stopped, so that the profiler doesn't get much useful info to work with. This is why Java is more likely to have benefits like this in long-running server processes.
And of course a conscientious C++ programmer will run a profiler on his program on a lot of sample data, and go about optimizing the slowest parts. A conscientious Java programmer should do that too. But an interpreted language has the advantage that the VM can do a lot of that work for you, and always does it at runtime, which is when it really counts.
Always keep a sapphire in your mind
A langauge in and of itself does not determine the speed. It's how that language is implemented/compiled. There's no reason why Java SHOULD be slower as long as it is compiled to the machine's architecture, and not to byte code. ... but then that destroys the purpose of Java.
"he drew his sword Ringil that glittered like ice... and he wounded Morgoth with seven wounds..."
Why does the example use a recursive fibonnaci sequence algorithm? It's so slow, and the runtime is dominated by the function call time.
./fib_recurse 40
./fib_for_loop 40
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.
>A VM otoh does get this capability for free. ;)
TANSTAAFL
> Java enforces garbage collection, and thus optionally gets the particular performance gain
Err... whether garbage collection gains or looses you performance depends very much on your application. I am not convinced that any garbage collector can even be theoretically faster than automatic variables.
>As was pointed out, one of the strenghts of C/C++ are pass-by-value....
After programming in C++ for 14 years, I don't think I've heard that one before
>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
const &? Ever heard of const references before? I don't feel qualified to judge your Java programming, but it's evident you're not particularly familiar with C++.
I'd be interested to know how you have more control over the design of 3rd party libraries in Java than in C++.
no taxation without representation!
Here is an excerpt from the article for this story: Lea used G++ (GCC) 3.3.1 20030930 (with glibc 2.3.2-98) for the C++, with the -O2 flag (for both i386 and i686). He compiled the Java code normally with the Sun Java 1.4.2_01 compiler, and ran it with the Sun 1.4.2_01 JVM. He ran the tests on Red Hat Linux 9 / Fedora Test1 with the 2.4.20-20.9 kernel on a T30 laptop. The laptop "has a Pentium 4 mobile chip, 512MB of memory, a sort of slow disk," he notes.
What this shows is that GCC's implementation of C++ is slower than an interpreted language like Java. This does not show that C++ is slower than Java.
----
Notes on Stuff
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
Actually, you're wrong, at least in part. Due to lack of specificity, I'd say that invalidates your argument.
It's all about *where* and *how* Java is used.
As someone who has done application development with both Java and C++ (as well as C, and others), here is how it works (assuming equivalent levels of code quality regardless of language):
For a non-GUI application, Java can be made to run nearly as fast as C++, with a slight startup penalty, and while utilizing decidedly more RAM.
For a GUI applicaton, Java will run considerably slower than a C++ application, and use significantly more RAM.
What does this mean?
Java works great for back-end applications, for web applications, etc. Especially if you take into consideration it's startup penalty (time needed to start the JVM) and run your java program persistently, Java can definitely be fast enough for this.
As for GUI applications, Java is only an ideal choice if you absolutely need something that is fully cross-platform (without using multiple binaries for each), for small applications, or for situations where you can gaurantee that the client machine will have a LOT of RAM, and a fairly modern CPU.
Now, use which ever langauge makes the most sense for what you're doing, and let's get back to coding, okay?
Topher
I just went through and tested the hash2 benchmark and found that I was correct. The C++ version slaughters the Java version (even in "server" mode). This is completely different than what this dude's page shows.
Here is the "correct" code for hash2.cpp:
#include <stdio.h>
#include <iostream>
#include <ext/hash_map>
using namespace std;
using namespace __gnu_cxx;
struct eqstr {
bool operator()(const char* s1, const char* s2) const {
return strcmp(s1, s2) == 0;
}
};
struct hashme
{
size_t operator()(const char* s) const
{
size_t i;
for (i = 0; *s; s++)
i = 31 * i + *s;
return i;
}
};
int
main(int argc, char *argv[]) {
int n = ((argc == 2) ? atoi(argv[1]) : 1);
char buf[16];
typedef hash_map<const char*, int, hashme, eqstr> HM;
HM hash1, hash2;
for (int i=0; i<10000; i++) {
sprintf(buf, "foo_%d", i);
hash1[strdup(buf)] = i;
}
for (int i=0; i<n; i++) {
for (HM::iterator k = hash1.begin(); k != hash1.end(); ++k) {
hash2[(*k).first] += k->second;
}
}
cout << hash1["foo_1"] << " " << hash1["foo_9999"] << " "
<< hash2["foo_1"] << " " << hash2["foo_9999"] << endl;
}
The ratio of people to cake is too big
(/me runs screaming from soon-to-be-burning building)
Is there something about flame-conducive subjects that make people want to "pick the scab", so to speak, or is it that sensitive subjects make people want to set stuff on fire? I think the Java vs. C++ holy wqar has even surpassed the EMACS vs vi one. (This is a good thing, I think, because arguing over vi vs. EMACS is a waste of time when it's clear that EMACS is better)
If a job's not worth doing, it's not worth doing right.
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"
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++.
Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
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)
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....
http://bash.org/?338364 #338364 +(1308)- [X] Saying that Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders
Who doesn't like free music?
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.
Why not just use VB? It would have been the easiest and probably faster.
Java works well as a COBOL replacement, a backend application language for boring buisiness apps.
Thats what it should be benchmarked against. Comparing it to C is like comparing apples and oranges.
_
\\/ are accustomed' - First Lensman
sprintf(buf, "%x", i);
It must parse the "%x" and determine what it's trying to do. So it decides, at runtime, you want to translate an integer value into a hexidecimal string. Of course if there's an error at runtime in the string "..." it must generate an error. How 'bout using strtol?
Now let's look at the java version:
Integer.toString(i, 16)
Ok, here we have something that is strongly typed so of course it will be faster. At runtime the java compiler _knows_ what it's dealing with and it knows it must invoke the hexadecimal conversion code.
Note that these statements are within loops.
Just one example, that was the first file I looked at. I don't think they have quite optimized the C++ code IMO. Plus the C++ library is notoriously slow, I would recommend rogue wave or your homegrown C++ classes.
I think the lesson here is it's very easy to write slow C++ code while it's very easy to write fast Java code.
Gimme any C++ code here and I'll profile it/speed it up and get it as fast if not faster than java.
2 years and no mod points. Join reddit. Because openness is good.
It should also be mentioned that the java language requires specific overhead to be included that C++ and C do not. Even if compiled down to sleak assembly, Java is still saddled with doing bounds checking.
The rest of the performance improvements are in the compiler optimizations and libraries which are mostly tangential to the language itself. If the compiler is clever enough to take "for (x=0, i=0; i<100; ++i) x+=5;" and substitute this for "x=500;", then great, but it should not be confused with an endorsement of the language itself.
Furthermore, I had no difficulty modifying the C++ code to outperform or at least meet the results of the server-side JVM using G++. In the cases where Java had any lead whatsoever, the code was so trivial that the JVM could virtually precompute the result. I don't see this as being useful because in the real-world, nothing I write is so trivial that this is possible. If it was, I would have done it myself. I believe this largely explains the discrepency between these "tests" and my actual experience.
-Hope
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.
double gold = (1.0 + sqrt(5)) / 2.0;
int fibonacci(int n)
{
return floor(gold * n);
}
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.
While you make several good points. I do have some counter-points.
A VM otoh does get this capability for free.
Let me qualify this as saying you don't have to do or pay for anything extra to achieve this.
Err... whether garbage collection gains or looses you performance depends very much on your application. I am not convinced that any garbage collector can even be theoretically faster than automatic variables.
By automatic, if you mean stack-resident variables, then I agree (with the caveat of dangerous code design), but if you mean malloc'd variables, then I don't see what the problem is. malloc has to worry about a great number of things, not least of which is memory fragmentation. I happen to have done a non-trivial amount of research on memory allocators; though I am no expert. Memory allocators can be optimized for allocation speed, fragmentation efficiency, concurrency, cache coherence, etc. but not all (obviously). As it happens, a copying garbage collector gives you all of the above EXCEPT when your buffer runs out; and thereby requires a garbage collection. So long as you you have large heap and you're not worried about the latency from garbage collection, then copying collectors are VERY fast. Allocation is literally a mutex lock, a stack-pointer range check, a stack-pointer increment, then a mutex unlock.
Now, because latency is often a real issue, most modern GC's apply additional complexity/logic which slows down the normal case to minimize the worst case; e.g. generational garbage collection which may require read or write boundry op-codes inserted. But code-wise, these varients are identical. Thus you achieve a flexibility not possible in a dynamic-memory-egnostic system such as c/c++.
I'd be interested to know how you have more control over the design of 3rd party libraries in Java than in C++
I didn't really mean design, but environment; Specifically in terms of the dynamic memory allocator. But, just to make the differentiation complete, java allows byte-code load-time modification. This is very common in "aspect oriented programming" such as in the database realm (JBoss/OJB) or object proxying. In Java, by introspection you can prepend/append/search-replace method calls or even individual instructions as need be. Note that this isn't any different than a custom pre-processor for C, but tends to be cleaner and thus doesn't require the [3rd party] coder to adhere to a particular convention.. Moreoever, this works on already shipped binaries, as opposed to requireing preprocessing to occur on the original source code.
-Michael
at least if you already know C.
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:
I'm futzing around with the other hash benchmark, and sure enough, making only a trivial change to the code (eliminating the unnecessary strdup in the second hash lookup), gets me about a 30% improvement in performnace.
This guy is a tool.
Let's try not to let fact interfere with our speculation here, OK?
but that's nto the same thing as saying "Java is faster than C++". The benchmarks in question are bout execution speed, not development speed.
Some of the benchmarks could have been far better implmented with code no more complex than what was arleady used on the c++ side... that's the issue here.
"java is faster for lazy coders" is a fair statement.. but not really what a benchmark tries to asess.
I don't deny that the finer granularity of C++, no make that plain C, no make that raw assembly language, allows you to make certain optimizations that are quite valuable in certain circumstances.
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.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
Sure cout is done twice, but it uses 'endl' where '\n' would do. 'endl' flushes the stream, which pretty much kills cache behavior. When the disk/console is orders of magnitude slower than the CPU, a single 'endl' can indeed kill performance.
As for new/delete, they can also be very slow, depending on the current memory layout, etc. More importantly, they violate the C++ programming paradigm (local objects not allocated on the heap) and hence are indicators that this isn't a very good C++ programmer, and hence he isn't qualified to make a reasonable comparison.
Shoot, the last time I did the Java/C++ flamewar I found that Python was faster than both (reading and sorting strings).
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.
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?
Well, actually, an ideal optimizer would detect that this loop has no observable behaviour, and therefore optimize it away completely. That is, the complete loop would be compiled to zero instructions and executed in zero time. Of course, a perfect Java compiler could do the same, which of course gives the question of how many times faster Java zero time is to C++ zero time :-)
The Tao of math: The numbers you can count are not the real numbers.
And tell him to check for buffer overruns next time (num > max).
On the plus side: after he flunks out, he can go write RPC code at Microsoft.
Or, perhaps, a cell phone bluetooth stack.
[Ducks And Covers]
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.
Eh.... so for your counter example you choose a problem that is unsolvable in any language?
Did you just read about that in your computer science class or something? How does that relate to the question at hand? For any java implementation, of any algorithm, I (or someone else) can write a c++ implementation that is faster. Does this mean that I can solve problems in c++ that are unsolvable? Ummm.... no.
This is a common logical fallacy. Its Latin name is "Non-Sequitur". You'll probably get to that next year when you study logic.
WWJD? JWRTFA!
My understanding is that JVM performance has improved because they are now doing things like selecting the appropriate instruction set for the processor at runtime. This is opposed to natively complied languages which are typically compiled to support the lowest common denominator.
Something that is almost always ignored when comparing programming language is the actual cost of developing something in that language.
Sure, you can almost always produce faster software in a low-level language. But since there are no good tools for doing this, it costs to much. Developing software using a modern, state-of-the-art IDE like IntelliJ IDEA, NetBeans or Eclipse speeds up the actually development process and allows the programmers to focus on the design, rather than trying to understand an obscure low-level API.
And no, Visual Studio does not count as a state-of-the-art IDE...
First of all, g++ actually sucks big time in terms of performance.
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.
In a lot of cases, you are right. But some of us (me included) work on military or other complex systems that getting 10 percent faster output would be great. I find that there is a lot of effort going on to put as much as posible on the smallest amount of hardware. The system may be fast, but the work load is going up, since to make things lighter, you run five apps that use to run on five different machines, on a single unit. One project switched to Java and is now suffering from performance issues. Now the code needs to be redesigned to get the required output.
;-)
Speed will always matter, until we solve those nasty NP problems
Steven Rostedt
-- Nevermind
I notice that much of the overhead is simply in making function calls.
Ackermann.cpp, for example, spends very little time actually calculating anything. Much of it's work includes all the overhead associated with making a function call.
Included in this overhead is management of the frame pointer. By using -fomit-frame-pointer, you avoid pushing the old ebp on the stack and a store of the current esp into ebp.
Ackermann runs about twice as fast with this simple optimization.
I saw this test a few days ago and wanted to check it out. The first thing I realize is that the source code is somewhat different even if Java has almost the same syntax as C++.
I understand that System.out.println(); is not in C++ but why have
instead ofI made the C++ code look like Java and got a 15% save. Problably even more if I had increased the number you call the program with. I looked at some of the other program and they have different code in them as well. So this test is bullshit it only shows that you can make slow programs in any language.
Ok, here is the java version
/usr/bin/j2sdk1.4.2_04/bin/java -server sieve 10000
... ./sieve 10000
./sieve 10000
/Alex
[alex@alkis dev]$ time
Count: 1028
1.94user 0.02system 0:02.08elapsed 94%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1major+2392minor)pagefaults 0swaps
And let's see the g++
[alex@alkis dev]$ g++ -O2 -o sieve sieve.cpp
[alex@alkis dev]$ time
Count: 1028
7.64user 0.02system 0:07.84elapsed 97%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+264minor)pagefaults 0swaps
Should we try intel's c++ compiler?
[alex@alkis dev]$ icc -O2 -o sieve sieve.cpp
[alex@alkis dev]$ time
Count: 1028
0.90user 0.00system 0:00.94elapsed 97%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+284minor)pagefaults 0swaps
Now, can someone compile KDE/Qt with icc and send it to me, please?
Thank you!
If you convert in the simple and mechanical way you mention, you are not going to improve the efficiency of the algorithm at all. You wouldn't be doing anything else but what the computer is doing by it's hardware stack (which would probably be faster via hardware optimizations).
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.
What's important to note is that the differences introduced by the VM and the rest of Java's overhead are small enough now that, for headless applications, poor coding can easily bridge the difference. There's no huge, glaring, a priori reason to use C++ over Java for headless apps, and when you want your server code to be portable crossplatform you'll find a huge, glaring reason to use Java.
Now what this study obviously doesn't deal at all with GUI'd applications, and Sun's Swing in particular does nothing to help Java's reputation as a slow technology. There's a relatively interesting discussion at java.net called Swing Usability that points out some of these shortcomings. What the Swing team doesn't seem to understand is that slower than native means slow to most users.
And just like the comments in this thread point out, as long as you put a compatibility layer between code and execution, you're going to be slower by definition. With Swing, simple to overlook unoptimized coding practices do not easily spell the difference between implementations. Here, Java's speed and performance is visibly slower no matter how quickly the GUI-less logic behind is racing along. (Yes, SWT is a big help, but it's not part of the JDK and likely still won't be seen in, say, Limewire any time soon.)
It's all 0s and 1s. Or it's not.
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.
Actually his statement still holds. No algorithm exists that can decide the halting problem, so he can still say "for all algorithms, a C++ implementation can be written that is faster than a Java implementation."
But don't let me get in the way of you admiring how wise you are.
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.
Get off it. Apparently you don't know as much about logical reasoning as you thought, or even Computer Science since you tried to call the halting problem an algorithm. Not to mention that the word "unilateral" makes no sense in this context; you probably meant "unequivocal" or "unqualified." Shall I find more things to pick on?
(Normally I wouldn't be this pedantic, but you are ripping on someone else based on pedantry and being rewarded with +5.)
Fact: there exist cases where Java is faster due to its ability to optimize on the fly.
The whole point of this critique is that any run-time optimization that Java can perform, a human can perform when they write the algorithm. In the end, all programs are executed by running machine instructions, and any set of instructions that a JVM emits/executes, a human can write manually to achieve exactly the same performance.
Many compilers and interpreters are written in themselves. Read the other comments about bootstrapping. And how do you think the first C compilers were written? In C?
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.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."