[ACCEPTED]-Java Runtime Performance Vs Native C / C++ Code?-jvm

Java isn't an interpreted language, and 101 hasn't been for several versions. The Java 100 bytecode is JIT'ed on the fly. (Technically 99 it still interprets some of the code, but 98 anything that matters performance-wise gets 97 JIT'ed)

As for performance, what on Earth 96 gives you the crazy idea that "there is 95 a baseline for overhead"? There isn't. There 94 never was and never will be. Not betwee 93 C++ and Java, and not between Python and 92 Javascript, or any other two languages. There 91 are things that your specific version of 90 the JVM will do faster than your specific 89 C++ compiler, and things that your specific 88 C++ compiler will do better than your specific 87 JVM.

So the "overhead" of your choice of 86 language depends entirely on 1) what you 85 want your code to do, and 2) how you write 84 your code.

If you take a Java program and 83 translate it to C++, the result will almost 82 certainly run slower.

If you take a C++ program 81 and translate it to Java, that too will 80 also run slower.

Not because one language 79 is "faster" than the other, but because 78 the original program was written for one 77 language, and was tailored to work well 76 in that language. And any attempt to translate 75 it to another language will lose this advantage. You 74 end up with a C++-style Java program, which 73 won't run efficiently on the JVM, or a Java-style 72 C++ program, which will run terribly as well.

Neither 71 language specification contains a clause 70 that "and the result must be at least x% slower 69 than language y". Both your C++ compiler 68 and the JVM do their very best to make things 67 go fast.

And then performance characteristics 66 you're seeing today may change tomorrow. Languages 65 don't have a speed.

But to answer your specific 64 questions:

There must be some baseline for 63 overhead when using an interpreter. Is there 62 some general rule of thumb to remember? 10% 15%? I 61 have read the occasional blog stating that 60 Java code is nearly as fast as native code, but 59 I that may have been biased.

As said above, it 58 depends. For many common tasks, you typically 57 won't see more than a few percents difference 56 either way. For some use cases, you'll see 55 a larger difference (going either way. Both 54 languages have advantages when it comes 53 to performance. There is some overhead associated 52 with the JVM, but there are also huge optimization 51 opportunities and not least the garbage 50 collector)

Does the JVM garbage collector 49 add significant overhead to runtime performance? I 48 know Cocoa applications have begun to use 47 a garbage collection model, and i agree 46 that it makes programming a lot simpler, but 45 at what cost?

Basically none. On average, a 44 garbage collector is far faster than manual memory 43 management, for many reasons:

• on a managed heap, dynamic allocations can be done much faster
• shared ownership can be handled with negligible amortized cost, where in a native language you'd have to use reference counting which is awfully expensive
• in some cases, object destruction is vastly simplified as well (Most Java objects can be reclaimed just by GC'ing the memory block. In C++ destructors must always be executed, and nearly every object has one)

The main problem 42 with a GC is that while on average a garbage 41 collector performs better, you lose some 40 control over when to take the performance cost. Manual 39 memory management ensures your thread won't 38 ever be halted while waiting for memory 37 to be cleaned up. A garbage collector can, at 36 almost any time, decide to pause the process 35 and clean up memory. In almost all cases, this 34 is fast enough to be no problem, but for 33 vital real-time stuff, it is a problem.

(An 32 additional problem is that you lose a bit 31 of expressiveness. In C++, RAII is used 30 to manage all sorts of resources. In Java, you 29 can't use RAII. Instead the GC handles memory 28 for you, and for all other resources, you're 27 screwed, and have to do it yourself with 26 lots of try/finally blocks. There is no 25 reason why RAII couldn't be implemented 24 in a GC'ed language, but it's not available 23 in either Java or C#)

What is the overhead 22 of making system calls from Java? For example 21 creating a Socket object as opposed to the 20 C socket API.

Roughly the same. Why would 19 it be different? Of course, Java has to 18 invoke the relevant OS services and APIs, so 17 there is a tiny bit of overhead, but it 16 is really nothing you're likely to notice.

Finally, I 15 recall reading somewhere that the JVM implementation 14 is single threaded. If this is true (which 13 i am skeptical about), does that mean that 12 Java threads really aren't true threads? Does 11 a java thread, in general, correspond to 10 an underlying kernel-provided thread? Does 9 a Java application benefit in the same way 8 a native application would from multiple 7 cores / multiple cpu's?

Java can use multiple 6 threads, yes. The JVM itself might be singlethreaded 5 (in the sense that all the JVM services 4 run on the same thread), I don't know about 3 that. But your Java application can use as many threads 2 as it likes, and they are mapped to OS threads 1 and will use multiple cores.

Both java and c# (and objective-c) are not 21 nearly as fast as native code can be. But 20 that only matters if you have a problem 19 where you are not engineering-time limited. Because 18 you'll have the time to devise a better 17 algorithm with a high level language.

So 16 basically, if you're developing a device 15 where you're going to build a million a 14 year of, or that is battery powered, you 13 don't use java or c# to build its core functionality. You 12 might add a lisp interpreter to make customisation 11 easy, though. Microsoft is not going to 10 use c# for say the core of SQL server, where 9 performance really matters. Visual Studio 8 on the other hand, where MS can expect users 7 to have high-end hardware, can be used as 6 a showcase for slow but high productivity 5 technology.

Please note that I currently 4 do most of my programming in Pharo Smalltalk, which 3 is a lot slower than java, c# or objective-c, and 2 is not even one of the fastest Smalltalks. Productivity 1 trumps performance.

http://www.w3sys.com/pages.meta/benchmarks.html

http://www.freewebs.com/godaves/javabench_revisited/

http://en.wikipedia.org/wiki/Comparison_of_Java_and_C%2B%2B#Performance

http://blog.dhananjaynene.com/2008/07/performance-comparison-c-java-python-ruby-jython-jruby-groovy/

http://www.irrlicht3d.org/pivot/entry.php?id=446

And so on. The fact is - it doesn't matter. Bottlenecks and 2 slow software are created by the developers, not 1 by the language (at least nowadays).

Actually, a VM can do a lot of optimizations 6 at runtime, based on information that's 5 only available at runtime, that a C/C++ compiler 4 cannot do. So, in most circumstances, the 3 JVM will be at least as fast as a native 2 program.

Brian Goetz answers most, if not 1 all of your questions in his talk Towards a universal VM.

To address each of your points:

• The overhead of interpreting code is much higher than 10-15% (I'd guess at along 3x-5x or higher). In order to get down to 10-15% you have to use some form of machine-code compilation step (i.e. JIT). (Try running a JVM with JIT switched off, and you'll see the performance drop like a rock.)
• Garbage collection does have a performance impact, but I'd say that everyone agrees that it is worth it. If you can afford the byte-code compilation/interpretation overhead, you can afford the gc overhead as well.
• Socket programming is much easier in Java than in C/C++, if that's what you're asking. And performancewise, the socket I/O overhead dominates over the Java execution overhead.
• Most modern JVMs have true threads, i.e. each Java thread is executed by a kernel thread, allowing Java threads to utilize modern multi-core CPUs.

0

A lot of people underestimate the performance 23 of java. I was once curious about this as 22 well and wrote a simple program in java 21 and then an equivalent in c (not much more 20 than doing some operation with a for loop 19 and a massive array). I don't recall exact 18 figures, but I do know that java beat out 17 c when the c program was not compiled with 16 any optimization flags (under gcc). As expected, c 15 pulled ahead when I finally compiled it 14 with aggressive optimization. To be honest, it 13 wasn't a scientific experiment by any means, but 12 it did give me a baseline of knowing just 11 where java stood.

Of course, java probably 10 falls further behind when you start doing 9 things that require system calls. Though, I 8 have seen 100MB/s read performance with 7 disks and network with java programs running 6 on modest hardware. Not sure what that says 5 exactly, but it does indicate to me that 4 it's good enough for pretty much anything 3 I'll need it for.

As for threads, if your 2 java program creates 2 threads, then you 1 have 2 real threads.

There isn't an easy answer to this. Writing 38 C style C++ is possible (even a good idea) but 37 once you try to do inheritance in C, things 36 get ugly. So ignore C and go with Java -vs- C++ since 35 they are closer to one another.

To get a 34 real sense of it you would need to write 33 two relatively large applications in similar 32 manner in both languages. If you do that 31 then do you use the STL and the Java collection 30 classes or do you write your own and port 29 them between languages? If you use the 28 native one then it depends on which implementation 27 is faster where as if you use your own you 26 are not testing the real speed of the application.

I'd 25 say you would need to write the application 24 as similar as possible but use the language 23 specific libraries/idioms where it makes 22 sense. C++ and Java code, while being similar, have 21 different ways of doing things - something 20 that is easy in Java may be terribly hard 19 in C++ and vice versa.

A modern GC implementation 18 doesn't add that much overhead, and you 17 can switch to a GC in C++ to do the comparison if 16 you like :-)

There are some things that the 15 Java runtime can do that is not generally 14 done in C++ compilers, such as the ability 13 to inline virtual methods.

For system type 12 things Java typically resorts to making 11 calls into C so there is overhead there 10 (though JNI is faster than it used to be).

Threading 9 depends on the implementation. Sun used 8 to use "green threads; for Solaris, but 7 that is long gone. As far as I know most 6 (all?) modern VMs use native Threads.

In 5 short I don't think there is a good metric 4 on the % overhead for Java -vs- C++, and 3 any that you find are likely to be micro 2 benchmarks that do not represent the real 1 world (unfortunately).

Important thing to note down is

Java byte 2 code JIT compiled to much more optimized code specific to particular hardware

vs

C code compiled and 1 optimized to general hardware so it cannot take advantage of features provided by specific hardware

As your objective is very modest "I am hoping to get a sense of the performance hit..." you should 10 be able to fulfill most of it by examining 9 the programs and measurements shown in the Computer Language Benchmarks Game.

As 8 you know both Java and C++

• you can look 7 at the program source code and decide for 6 yourself which of the Java programs are reasonable to 5 compare with which of the C and C++ programs

• you can 4 look at the dozen different tasks and decide for yourself which of 3 them exercise your idea of "the most basic features of each language"

• you can look 2 at the different approaches to multicore, or programs forced onto one core

• you can check how much JVM startup 1 might or might not effect those measurements

But you do have to think about whether measurements of tiny programs can plausibly indicate the likely performance of your application.

Nowadays multithreaded and distributed patterns 16 eliminate the need for native speed , java 15 can reach c++ speed and in some cases can 14 be faster but in general we can say that 13 c++ is faster than java by a small margin 12 lets say 10-20% , this can be ignored by 11 adding another service after the load balancer 10 so what 4 c++ services can do 5 java services 9 can do in same speed , what 3 c++ threads 8 can do 4 java threads can do in same speed. another 7 important factor is the code itself , a 6 good java code can be faster than a bad 5 c++ code , java has larger community and 4 stronger support and more stable libraries 3 and tools so for server side java is better 2 choice and can save time and lead to more 1 stable and performant code