在任何情况下，Java 都能比 C++ 更快吗？

Question

Is it possible for a Java application to be faster than a program written in C++? Also, what is release mode in compilation ?

Answer 1

Unlike some people here, I'm going to be reasonable and answer the question that I know the OP intended to ask, even though his statement of it could have been better.

Yes, a typical java implementation can be faster than a typical C++ implementation for real-world things. Even though Java has a few handicaps from being a safe, VM language, it makes up for some of them, too.

For one thing, since Java has a very abstract memory management scheme that does not allow raw pointers or untyped memory blocks to be manipulated, it can use a moving garbage collector. In C++, untyped memory regions, unions, etc. would break this. Therefore, when a GC does not need to be run, allocations in Java can simply be a pointer bump. There is no practical way to do this in C++, since a fully moving GC cannot be implemented in a language that supports the kind of low level manipulations that C++ does.

Furthermore, the VM of a typical implementation of Java is a double-edged sword relative to the statically compiled typical C++ implementation. The VM has some inherent overhead, but also allows some extra optimizations. For example, let's say you have some kind of virtual function like (Please excuse incorrect syntax, as I don't regularly use Java):

abstract class Foo {
    void stuff() {}
}

class Foo1 extends Foo {
    void stuff()  {
        System.out.println("Foo1");
    }
}

class Foo2 extends Foo {
    void stuff()  {
        System.out.println("Foo2");
    }
}

// Somewhere in program initialization:
Foo foo;
if(args[0] == "Foo1")
    foo = new Foo1();
 else foo = new Foo2;
 for(int i = 0; i < 1000000; i++)
     foo.stuff();

In C++, a virtual function call on foo.stuff() would likely have to be performed for all 1,000,000 iterations. In Java, the VM might be able to replace this with a direct call at runtime, after realizing that there is no semantically legal way for foo to be rebound to an object of class Foo2.

Answer 2

Languages don't have a speed. A good Java compiler may generate more efficient code than a bad C++ compiler, and vice versa. So which one is "fastest"?

Execution speed depends on several factors:

• The compiler. Different compilers generate different output code from the same input.
• Your source code. Some operations are cheap in one language, but expensive in others. allocating memory with 'new' is far slower in C++ than in a managed language like C# or Java, for example)
• The system it's running on. (CPU's vary in how fast they can execute different code. What if your Java compiler turns out to generate code that runs really well on a Core 2, but my C++ compiler generates code that runs well on a Phenom? Which is fastest then?

But the language is in principle irrelevant. Each language enforces certain guarantees which, might prevent certain optimizations. But a clever compiler may determine that these guarantees can be safely bypassed in this particular case, making the optimization anyway. (For example, a Java compiler will often try to eliminate the bounds-checking that is required by the language). So it depends on the code you're testing (Java code ported to C++ will probably run better in the Java version, and vice versa), and on how you compile it and where you run it.

So as Martin York says, it's a silly question. It's impossible to answer. Of course Java can be faster than C++ in some situations. For example, if you write really good Java code and really bad C++ code. Or if you use a lousy C++ compiler. Or if any of a million other things just so happen to favor the Java version a bit.

Say after me: Languages don't have a speed .

Which is fastest? English or french? Both are just ways to associate meaning with sounds, or squiggles on paper.

The same applies to programming languages. A programming language is just a way to associate semantics with a sequence of characters in one or more files.

Answer 3

I think there are plenty of questions you can browse through that are similar. Have a look here, for example: C++ Performance vs. Java/C#

Answer 4

是的，它可以：制作一个使用好的算法的 Java 程序，和一个使用坏算法的 C++ 程序，Java 版本可能会更快。

Answer 5

You can see c++ and java language comparison where few cases java is faster. Also I have added a tables for Java and C++ and you ca see some other the cases are faster in java compared to C++.

Lower numbers are better. Eg binary-trees search is better in java (2.89) secs versus 4.47 secs in c++.

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=javaxx&lang2=javaxx

 Java 6 -Xms64m measurements
Program & Logs  Time secs   Memory KB   Size B   N 
binary-trees    2.89    39,436  603  16
chameneos-redux 17.01   17,316  1429     6,000,000
fannkuch    11.08   8,996   555  11
fasta   21.40   9,300   1240     25,000,000
k-nucleotide    15.57   83,308  1052     1,000,000
mandelbrot  3.25    11,136  665  3,000
meteor-contest  0.80    14,196  5177     2,098
n-body  14.84   11,652  1424     20,000,000
nsieve  2.22    15,748  296  9
nsieve-bits 5.04    13,468  523  11
partial-sums    9.14    8,600   474  2,500,000
pidigits    1.92    9,112   938  2,500
recursive   6.82    12,180  427  11
regex-dna   7.60    75,192  921  500,000
reverse-complement  1.13    61,124  592  2,500,000
spectral-norm   24.00   12,268  514  5,500
startup 17.23       112  200
sum-file    4.11    10,084  226  21,000
thread-ring 134.99  27,628  530  10,000,000

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=gpp&lang2=gpp

 C++ GNU g++ measurements
Program & Logs  Time secs   Memory KB   Size B   N 
binary-trees    4.47    6,996   541  16
chameneos-redux 16.69   1,004   1729     6,000,000
fannkuch    7.78    844 554  11
fasta   18.72   788 1248     25,000,000
k-nucleotide    7.46    9,304   1380     1,000,000
mandelbrot  3.02    896 1097     3,000
meteor-contest  0.15    792 5311     2,098
n-body  14.62   932 1705     20,000,000
nsieve  2.08    5,764   313  9
nsieve-bits 3.86    3,316   494  11
partial-sums    4.05    852 531  2,500,000
pidigits    1.66    1,052   652  2,500
recursive   2.40    1,008   566  11
regex-dna   5.58    12,704  1588     500,000
reverse-complement  0.54    13,288  810  2,500,000
spectral-norm   23.84   900 442  5,500
startup 0.86        108  200
sum-file    6.47    852 260  21,000
thread-ring 101.28  2,960   626  10,000,000

Answer 6

Although most people wouldn't use them the same way it can be possible for a program written in Java to have similar speeds (in some cases even faster) than the same program written in C++. (Let's assume for now, that both have the same algorithm implemented in the same way, neither of them uses some special trick that would not be available in the other language and this is not a special "benchmark" algorithm that builds on some special feature of a language/toolset)

Or, at least that is what we have observed in our research: https://www.researchgate.net/publication/352705416_Improving_productivity_in_large_scale_testing_at_the_compiler_level_by_changing_the_intermediate_language_from_C_to_Java

In this research project, we wanted to see if we could improve on the build performance (and so hopefully on developer productivity) by extending a compiler to use Java as an additional intermediate language, besides C/C++. This way could generate, from the same source code, programs written in C/C++ and Java, that built to executables that read the exact same configuration files, produced the exact same functional behavior, and generated the exact same logs.

We have observed that in this setup the binaries built via C/C++ started up faster. The "binaries" built via Java became gradually faster, to the point where, in long-running scenarios, they could end up finishing earlier.

Based on our measurement, most probably the Just In Time (JIT) compiler of the JVM was able to notice some optimization opportunities during execution, that were either missed by the C/C++ compiler used or only present themselves during execution. We hope to investigate this further in a follow-up research.

Answer 7

Most discussion compare applications compiled from source. However if you have an old library eg from a third party, you can find that an old java library is much faster as it will still be able to use the latest instructions/techniques whereas an old library already compiled to native code cannot.

Answer 8

I guess the most interesting thing you can say on this topic is that a modern JVM does some speculative optimizations. Optimizations based on guesses about the stableness of some values, whith the possibility to unoptimize that code if the value should change in the future.

OTOH this is nothing inherent with the languages in question. I saw a research project a couple of years ago that managed to get an extra 20% out of some natively compiled code (maybe even from C++) by running it in an emulator emulating the same CPU as the hardware but performing some VM-style optimizations on the code.

Answer 9

If I believe what some Java evangelist say, I would answer "yes" to the first question. Ie. a Java program "can" be faster. Not always, though...
These Java evangelists point out the better memory management, avoiding overhead of new , etc.

To answer the second question, release mode for a C/C++ compiler means a compilation without debugging information: the latter stores additional information like line numbers corresponding to generated code (easier for debugging and error reporting), and avoids optimizations (which can change code order and mess with above info).
So release mode is, in general, faster and smaller. And can crash where the debug mode works! (Rare but I saw that.)

Answer 10

Release Mode means that you build your program because you want to release it out to the public. Usually, the compiler will try harder to make the executable smaller and faster. This often means getting rid of symbol information needed get a backtrace of a crash and using a higher optimize level. The latter makes compilation time slower, so it's not used when building in Debug Mode .

Answer 11

Yes it can . The JIT compiler can optmize the code to run faster. While in C++ you have to do that optmization by hand.