Java, C/C++, and performance

Miscellaneous Topics
#1

Every once in a while, I am involved in a discussion of Java’s performance, as compared to C or C++. Personal experiences vary widely, as do industry statements and research reports. While reports come up in fairly regular intervals that indicate a closing of the performance gap between Java and C++, and while some benchmarks seem to indicate a performance penalty of <1.5, personal experiences report a performance penalty more in the range of 10 to 50.

I don’t use C++, and I was curious if any of you can shed some light on this matter. GUI issues apart (Swing IS slow), what do you think? I know that benchmarking is an arcane science of its own, but what is your gut feeling?

#2

Round and round in circles we go, what the answer is, nobody (really) knows!

The really nice thing about java is that you can create a proof of performance/concept in such a short time frame that you can easily check whether there will be a problem within your initial investigations, and of course the language features and stability make it far more desirable to use than C++.

That said, in my experience, having working extensively in both C++ and Java, I’ve not really experience any significant slow down using Java. At the micro/trivial level I’ve written and run some bench marks which show C++ to be considerably quicker. However, at the abstract/real problem level I find my algorithm design in Java is far better since I’m not worrying about the langauge details as much, and hence my solutions tend towards better performance and scalability.

Personal opinions, obviously.

Kev

#3

What type of code leads you to that conclusion? I haven’t seen a difference of that magnitude since checking someones code to find that they were comparing buffered I/O on C++ to unbuffered I/O in Java.
The other case where such large differences can arise is where the total execution time of the application is very much less than 1 second (in which case who cares anyway). If this operation is done many times, then one approach is to move the activity into a persistent process and thus pay the startup penalty only once.

#4

I generally find that if I can more or less get double the raw performance of the current client 5.0 VM if I use C++ to do the job, on things like ogg decode and so on. The server gets much much closer, sometimes faster at certain things. However there’s three bugbears:

  1. Startup time using the Hotspot VMs, especially the server VM, mean that anything that’s otherwise only meant to take a moment in C++ tends to take 10x as long in Java. Boo!

  2. There’s more to performance than just speed: we might want to measure it by memory consumption, and there Java will tend to score poorly.

  3. Most of us in here write the kind of code that C is ideal for - raw single threaded game logic and lots of API calls to graphics APIs. This is exactly what Java is worst at, of its many applications. Java has lots of cleverness for multithreaded and I/O applications and nifty memory allocation strategies and dynamic code execution but if you’re not actually doing any of that you’re left with a system that’s irritatingly hobbled in a few important areas for games development.

This is not to say it’s not great; it’s just less than it could be.

Cas :slight_smile:

#5

Thanks for your insights. The figure of 10- to 50-fold lower performance is not mine - these are numbers people came up with in conversations. Not using C++ (although I have some C++ experience from several years ago), I was in no good position to argue. Still, I have been very happy with Java throughout the last 7 years, and I would not want to change to C++ for performance reasons if not absolutely necessary and absolutely justified by hard evidence.

You are right that the high productivity of Java makes up for the lack of performance (if there is any) for most applications.

#6

Just hearsay then. Some people haven’t bothered to recheck their data for many years — they are comfortable with their prejudices. Some even continue to quote old information quite deliberately with malicious intent.

#7

Right, things can get very emotional in these advocacy debates. Still, this was from people I usually would not expect to blatantly make things up. I think part of the problem is that it is very difficult to set up a correct benchmark, especially between two different languages / architectures.

#8

Performance between Java and Macro assembly is 51/50 - 17/21. C++ was in all tests slower than equal macroassembly. Not surprising if we would consider that algorithms were simple and possible compiler optimalization of C++ was possible to do in Macro ASM as well after education from dissasembly. ~_^ (Note I didn’t included starting times or ASM would win too easily)
Best answer is it depends on programmer and computer on what it would be runned. Java programs are consistent enough to speed up, and very likely don’t crash, if they are used after several years on a more recent CPU. (Slow incorporation of new things and late deprecations might be sometimes advantageous.)
Because majority of future computers would be multicore, all programs should support multiple threads. And don’t forget that Mickerosoft might actually improve windoze into something that would somewhat suport preemptive multithreading. (It’s still event based system that would have problems with future CPU.)

If you would like to talk with C++ persons, you might cite this:

T"he reasons for 68 kb code for a simple string on the screen isn’t just a problem with STL, but a, how to talk about it, behaviour that is hard to accept by an assembly programmer. (To put it simply, you not only get your chicken, you get also your aunt, your elephant, and your ship. They are nicely lined just behind your back so you will not see them. It also add a nice box with message on top of that.)"

(The message is something about .net. It’s poetical for purely C++ program.)

It would be also nice to see some examples.

#9

What i was told from a reliable source is that tweaked C++ code is faster than Java code and tweaked assembler code is faster than C++ code, but the advantages are so small it often doesn’t pay for the time spent tweaking it. There are a couple of cases where you are required to program in assember (like parts of the Linux kernel or graphics drivers, doom3 also had some code in assembler) but nothing i recall would be absolutly necessary for doing games in Java since the most the heavy stuff is taken care by the opengl binding.

#10

a good algorithm is much much better than a crap algorithm in whatever “faster” programming language !!!
So in java you can more easily keep track of what you’re doing, so you don’t tend to making so much crap stuff, so you get maybe even faster !!

#11

The above mentioned people are not interested in better algorithms, they are more interested.

  1. Language iching.
  2. Laying shit on language they don’t know, and will not use lastest version to do some testing.
  3. Talking shit.
#12

Yeaaaaaah. Java benchmarks are bigger than everyone else and balls and crap.

Given the quality of the last posts, could a moderator move this thread to the childrens forum.

#13

We don’t have children forum. They are more productive and they could be smarter by a larger margin.

#14

There’s a microbenchmark in the July 2005 issue of C/C++ Users Journal. C++, C# and Java are being compared in 18 tests.

There are four Java runtimes present: Sun server, Sun client, IBM and Excelsior. Among them the clear winner is - IBM. In all tests it’s as fast as the C++ compilers.

Unfortunately the IBM Java runtime seems to be available only for IBM computers. At least that’s the impression I got after visiting their homepage. Is this so?

Does anyone have experience with IBM Java? There’s just one version. Is it sluggish on clients?

#15

Some collegues and I wrote an adminstration tool for room assigments (mainly GUI and DB stuff), which had to run with a IBM JVM, some years ago.

At that time, IBM JREs and JDKs properly work on any hardware we testest it (none of them was IBM). The only drawback was that SUN already had released their JDK at version 1.4 and using IBM we had to stuck with 1.3… On the other hand the swing implemtation was incredibly fast for that time and some minor diffrences, like both, the space and return key were default accepters for JButtons, let the users feel more familiar since it was more close to the default behavior of other (windows) apps.
Unfortunately I cannot say anything about the latest IBM JREs/JDKs, but arent’t there any newer ones that version 1.4.x ?

Btw. what is your general impression about the benchmark, is it serious ?
I’m getting very curious, since the overview tells that the author is dealing with 3D hardware, software-performance evaluation, and benchmark/tool development - guess I have to buy that issue…

Best regards
-Michael

#16

Yes it’s serious but you have to draw your own conclusions because no evaluation was offered.

I’m generally quite sceptical to micro-benchmarking and don’t pay too much attention but what struck me this time was the excellent performance throughout by the IBM runtime. It was a little disappointing that it seems to be available for IBM computers only.

The main reason I bought the magazine was for the article about bridging C++ and Java. To combine the strengths of both languages is probably a better strategy than to hope for one to “beat” the other in all categories.

#17

Assembly exceles at tiny problems of minimal complexity.

C excels at ertain kidsn fo medium scale problems.

Java exceles at comples problems.

Any code that you could comfortably write in assembly is almost certainyl to small and trivial a case to give any meaningful Java
results.

Its that simple.

P.S. Java beats the crap out of any C but MSVC on WIn32 for allcoation/deallocation. Any algorithym whioch does heavy constant allocation/deallocation ash erpformed better in Java then C for a long time. For some reason I don’t fully understanbd, I’ve seen three C v. Java FFT shoot outs and in each case the final maximally tuned Java beat the pants of the maximally tuned C.

You know what IQ tests measure, right? The abiltyi to take an IQ test. SImilarly microbenchmarks measure a systems ability to run the microbenchmark and thats about it. They can be useful in Java ocne you have ALREADY profiled a real app and found a bottleneck in helping probe the system to understand exactly what is causing that biottleneck, but thats about it. Out of context they mean almost nothing.

Not surprising if we would consider that algorithms were simple and possible compiler optimalization of C++ was possible to do in Macro ASM as well after education from dissasembly. ~_^ (Note I didn’t included starting times or ASM would win too easily)
Best answer is it depends on programmer and computer on what it would be runned. Java programs are consistent enough to speed up, and very likely don’t crash, if they are used after several years on a more recent CPU. (Slow incorporation of new things and late deprecations might be sometimes advantageous.)
Because majority of future computers would be multicore, all programs should support multiple threads. And don’t forget that Mickerosoft might actually improve windoze into something that would somewhat suport preemptive multithreading. (It’s still event based system that would have problems with future CPU.)

If you would like to talk with C++ persons, you might cite this:

T"he reasons for 68 kb code for a simple string on the screen isn’t just a problem with STL, but a, how to talk about it, behaviour that is hard to accept by an assembly programmer. (To put it simply, you not only get your chicken, you get also your aunt, your elephant, and your ship. They are nicely lined just behind your back so you will not see them. It also add a nice box with message on top of that.)"

(The message is something about .net. It’s poetical for purely C++ program.)

It would be also nice to see some examples.