2

Lately I've been thinking about the difference about native and bytecode. I did some research and all information I've read was about C++ code compiled into native code vs Java code compiled into bytecode(runs on JVM which takes advantage of multi-core processors). The conclusion was that applications written in Java run faster.

Does C++11 change this? Does applications written in C++11(since adds threads) run faster than Java ones?

Yakk - Adam Nevraumont
  • 262,606
  • 27
  • 330
  • 524
David
  • 93
  • 2
  • 8
  • 5
    Java doesn't just automatically use multiple threads for your code. You still have to make it parallel explicitly, as you do for C++... – Jon Skeet Nov 28 '12 at 18:09
  • 2
    And you can implement a C++ (including C++11) compiler that spits out bytecode if you want. (Clang/LLVM can do exactly that) – Flexo Nov 28 '12 at 18:10
  • Everything runs as native code in the end. Bytecode is just a format of intermediate representation of a program, which every compiler has in some form. (As mentioned LLVM also defines a bytecode.) Java is compiled on the fly. – Potatoswatter Nov 28 '12 at 18:12
  • Jon Skeet, I know that; I considered that applications use multiple threads. – David Nov 28 '12 at 18:20
  • One big difference is that java bytecode is based on a stack machine, while all important real machines are register based machines, thus native code uses registers. – smerlin Nov 28 '12 at 18:32
  • 1
    @smerlin Not that big a difference. Stack machines/postfix notation is like a cheap form of compression. It makes the stored file size smaller and it's very fast to convert to and from. – Potatoswatter Nov 28 '12 at 18:54

3 Answers3

3

The conclusion was that applications written in Java run faster.

That's a big leap to come to. There are so many factors which contribute to the performance of a system that it's very hard to say one approach will always be better or even faster than another.

C++ has always been able to use threads, it just didn't have as much detail on how they could be used. I don't believe C++11 is about performance but standardising things like memory models.

IMHO Given any amount of time and expert developers, a C++ program will always be faster than a Java program. However, given a limited amount of time and developers of mixed ability you are more likely to get something working and performing well in Java. Your mileage will vary. ;)

Making my answer clearer...

Does C++11 change this?

No. I don't agree it is the situation nor does it change it.

Does applications written in C++11(since adds threads) run faster than Java ones

Yes, but not always, Just like earlier versions.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • This is a comment, not an answer. – Potatoswatter Nov 28 '12 at 18:16
  • took conclusion from accepted answer("On average, a garbage collector is far faster than manual memory management"): http://stackoverflow.com/questions/1984856/java-runtime-performance-vs-native-c-c-code – David Nov 28 '12 at 18:17
  • @Potatoswatter Hopefully my answers to the question are clearer. – Peter Lawrey Nov 28 '12 at 18:24
  • 1
    @David I would agree with that. That is just one portion of what a program does. BTW C++ provides alternatives such as data structures on the stack which is faster than GC or manual memory management which also means you need less memory management in C++. – Peter Lawrey Nov 28 '12 at 18:26
  • @David, the answer you linked doesn't assert that Java is faster than C++ (at all). Creating a meaningful benchmark is also either pointless or impossible. – David Titarenco Nov 28 '12 at 18:27
  • @DavidTitarenco, I did that assertion based on answer. – David Nov 28 '12 at 18:37
2

Neither C++ nor Java automatically split your program into multiple threads. The closest you can get to automatic parallelization in modern languages is to use parallel collections. There are libraries to do that in C++ but there is better support for that kind of stuff in more functional languages e.g. Haskell, Scala, Clojure. Another way to get automatic parallelization is to use an actor library and write your entire program with actors. Erlang was the first language with full support for that but the Akka framework for Scala/Java is also very good.

Tesseract
  • 8,049
  • 2
  • 20
  • 37
  • I was thiking to add Scala in the "game". You say that the best approach to take advantage of multi-core processors is to write applications in "more funcitonal languages" ? – David Nov 28 '12 at 18:31
  • Peter Lawrey's answer was clear enough that's why I accepted his answer, but you(SpiderPig) gave me some information I was looking for. Thanks a lot! – David Nov 28 '12 at 18:56
1

I would just say All Your Java Bases Are Belong To C++.. The JVM itself is written in C/C++. C/C++ run at native speeds on the bare-metal of the machine, while bytecodes are interpreted by a C/C++ code(that's running on top of the metal). One byte-code instruction could translate to about 5-10 asm instructions(or more). Hence speed of execution of C/C++ is considered faster than Java's. Ofcourse, if Java's runtime were thrown onto the metal and we had bytecode interpreted at machine speed, then it would be a fair comparison.

That said, see an example in the book called "Programming Pearls" where the author runs an interpreted BASIC program on a Radioshack personal computer, which with sufficient optimizations, runs faster than it does on a super computer. Which means, speed of execution of your program depends on your algorithms and coding/optimization practices.

Aniket Inge
  • 25,375
  • 5
  • 50
  • 78
  • Java usually is JIT compiled to machine code so in most cases there is no significant difference in speed there, at least not on the Oracle JVM. – Tesseract Nov 28 '12 at 18:30
  • even if they're JITed, the JITing itself takes machine cycles. Seeing from pure machine cycles' end.. JITing is a process and that consumes machine cycles. And not all instructions are compiled to machine code. So obviously, there is a runtime speed difference – Aniket Inge Nov 28 '12 at 18:33