aspose file tools*
The moose likes Performance and the fly likes C++ v. Java Performance Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Performance
Bookmark "C++ v. Java Performance" Watch "C++ v. Java Performance" New topic
Author

C++ v. Java Performance

Siegfried Heintze
Ranch Hand

Joined: Aug 11, 2000
Posts: 388
Where are some good references on the performance of Java compared with C++? Are there any benchmarks out there?
At the Denver or Boulder JUG there were some curious but brief comments (I think from Paul Wheaton) about how Java could (someday) be faster than C++ because C++ usually compiles for 386 only.
Well with more open source products like Linux, I can recompile for 586.
It boggles my mind that I could ever get superior performance from Java where I have to relinquish control over the heap (i.e., I cannot write my own specialized versions of new and delete and I cannot control when delete is called).
Consider the niave approach to allocating a string in C++ with the statements
void f(int i){
std::string* p = new std::string("abcdefghijklmnop", i/*how many characters to allocate*/);
...
}
(1) Allocate p on the stack (4 bytes).
(2) Call the compiler vendor's implementation of new to allocate an instance of std::string. (Another 4 bytes for the actual string struct, another 4 bytes for a backward pointer used internally by the heap, another 4 bytes to hold the size of the chunk of memory: total = 12 bytes).
(3) Call the compiler vendor's implementation of new again to allocate a null terminated character array of 4 bytes (plus another 8 bytes overhead). However, I don't think the std::string really uses null terminated character arrays internally so instead of 4 bytes for the actuall data it is 4 bytes for the length and 3 bytes for the actual characters.
This gives a total of two calls to the compiler vendor's implementation of new/delete and 15 + 12 = 27 bytes on the heap to allocate a silly little string "abc". (This is assuming, that the the vendor's implementation of new/delete allocates the exact amount of memory we ask for and this is not likely. It is more likely that they will round up to the nearest multiple of of 8 or 16 bytes). As I understand Java, at best I have an identical scenerio. More likely, however, Java may have even more overhead because it is supposed to perform garbage collection and defragmentation with a background thread which requires additional data structures and more context switching between threads and synchronization with semaphores etc...
But let's give our Java implementation the benefit of the doubt and assume it is no worse than our niave approach with C++.
Incidently, for the last decade I've been timing various combinations of Wintel compilers and processors. Typically it takes 30 to 100 times longer to allocate a chunk of memory with new/delete than it does to allocate a fixed length array on stack. For example, under MSVC6 it requires about 12-15 nanoseconds to allocate an array on the stack and 1300 nanoseconds to allocate that same array using new/delete (about 100 times longer).
Now lets rewrite that code using techniques available to the C++ programmer. In non-standard g++ I can simply write
char* f(int i) { char p[i+1]; strncpy(p,"abcdefghijk", 3); }
This is fast and small. No calls to delete, 12-15 nanaseconds to allocate the array and I'm not sure how long strncpy copy takes, but to be consistent we should ignore it because we ignored it above. No heap fragmentation and deallocation is free when we collapse the stack frame. We use a total of 4 bytes of memory!
OK, so you don't like g++. Well then use alloca (which is still non-standard but it is supported by nearly all the C++ compiler vendors.) Depending on how clever the compiler vendor is alloca could take as long as additional 25 nanoseconds. We could eliminate this with inline assembly if it is a problem.
If you don't like these options we can write overloaded and tailored implementations of new/delete that only allcocate exactly the amount of memory we need without us storing the length of the string and malloc redundantly storing the length of the chunk. Moreover, if we are clever C++ programmers, we can allocate a string class that only requires a single call to our customized new/delete instead the traditional two step slow approach of allocating the string, and then allocating the char* member pointer within the string).
None of these optimizations available in Java. (Please correct me if I am wrong). How can you tell me that Java is ever going to be as temporally efficient (assuming that I am taking the time and care to optimize my C++ code) or as spatially efficient?
Siegfried
Matt DeLacey
Ranch Hand

Joined: Oct 12, 2000
Posts: 318
You obviously know a great deal more about all of this than I do, but that doesn't prevent me from interjecting my opinion !
I just started working for one of the largest computer businesses in the world. It's a VERY unscientific survey, but honestly, ALL of my colleagues want to go into Java and none of them want to go into C or C++. I should probably say contemporaries instead of colleagues. In addition, just because that is what we WANT doesn't mean that that is what we are going to get. However, having said that, and having read what you have written, I will say this. It doesn't seem plausible NOW. However, IMHO, I believe that it is naive to think that when the vast majority of CS majors want to go into Java development, that you aren't go to see the Java language evolve into something outside the scope of what you can envision today. In the daytime, I am currently doing C/C++ work. In the evenings, I do ALL Java and that's the way it is with all of my contemporaries (all that I know anyway). To me, your demonstration only goes to prove that Java's not there YET, but it says nothing of the future. If you look at the breakdown of C vs. Java programmers 10 years from now, I think we'll all be surprised and therein may lie the answer to your question.

With Respect,
Matt
Jack Shirazi
Author
Ranch Hand

Joined: Oct 26, 2000
Posts: 96
Certainly if you look at any microbenchmark, you will always be able to optimize that benchmark faster in C++ than Java, just as I could make it run faster in Assembly than C++.
Back in the real world, many projects have to interface to third-party products, which are almost always written generically, since the product designer wants to support as wide a range as applications as possible. Here's a fun test to think about. I need to interface to a generic Object management class - Vector kinda stuff. But in my own part of the application, the type handled will always be the same (possibly not known until well into runtime). Sure, I can throw in switches in C++ <em>if</em> I know the possible types at runtime. But I still need the casts, even if I try to minimize them with pointer management. Now in Java, I run in HotSpot. HotSpot runs for a bit, sees the objects are always of the same type, and decides to speculatively optimize away all the casts, so that code is natively compiled as if it is only of the actual type. The natively compiled code for that bottleneck section is actually <em>faster</em> than is possible with the statically compiled C++. Show me a C++ app that adaptively optimizes itself at runtime based on the runtime data, and I'll show you a maintenance nightmare.
Further, lets take your C++ code compiled to the 586. Its released, and I run on Pentium XVWhatever. Well, its optimized for 586, but doesn't take advantage of the new megaquantumpipeline command in the Pentium XVWhatever. But my JVM that came with the Pentium XVWhatever does.
And there is, of course, the alternative kind of inter-language test. How about "build a servlet that interfaces to a relational database and provides a user-calendar with dates switchable between multiple calendar formats". Most project managers will be delighted to swap a 10% decrease in performance for a 10% speedup in development time.
Ultimately, language wars are pointless. If you have the decision, go with what you prefer - from the performance point of view, you'll be able to make it go as fast as you need. If you don't have the choice of language, the discussion is even more pointless.
I have been (peripherally) involved in the language choice of least four major projects over the last 10 years. In every case, the merits of the languages mattered considerably less than the desires of one or two of the major decision makers. The language choice decision matrix in every case had the weightings adjusted until the desired decision was also the technical result. And the chosen language always performed adequately - after performance tuning. The last two wanted Java (like Matt). They got Java. And the first of those two made the decision when Java was still in the 1.0.x stage (major project involving over 50 programmers, three tier, intranet, ...). It is running like a well oiled machine now, supporting 1200 employees.
shailesh sonavadekar
Ranch Hand

Joined: Oct 12, 2000
Posts: 1874
what i feel here that every language is designed with purpose in mind. C++ had the purpose of "Efficiency' in mind , while java had "network programming " as the purpose in mind. thus , the design goals of both the languages are very different. Thus , alot many things in C++ are removed in Java ( Multiple inheritance , STL's , pointer arithmatic etc. ). Java is deifinitley designed for portability , security ( Replated to network ) in mind. For portablity , they have jvm which sits on your native code. thus , it is going to be slow. If Javachips becomes reality , then we can check the perofrmance of java v/s c++ on same platform. Right now , the comparision of two diff. languages with two diff. purposes may not be correct.
what do you say , guys?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: C++ v. Java Performance