Java runs about 2x slower than C++ for general CPU-bound stuff - (although it does use much more RAM). That sounds slow, but it's faster than most other languages out there. However, C++ does give you the ability to more easily use processor extensions (SSE, AVX, etc), which you can't use from Java AFAIK - which makes a big difference in performance for certain applications.
> C++ does not support any processor extensions, they are not defined anywhere in ANSI/ISO C++ language standard.
> They are a language extension not guaranteed to be available in all C++ compilers in the same form, thus not portable.
This is true only if you're a language lawyer, but there's very little point to sticking pedantically to a language standard and not take advantage of the ubiqtuitous language extensions available. All the popular compilers out there support all the latest CPU instruction sets with the same syntax, etc. E.g. xmmintrin.h for SSE, avxintrin.h for AVX.
> Java can make use of processor extensions by writing a small Assembly snippet callable via JNI.
While this is true, you destroy any performance gain with the complexity of the JNI calling convention. It only pays off if you're doing a quite long stints of SSE/AVX/NEON code at once. Wrapping a small vector dot product or matrix multiplication in JNI will not yield any performance gain in practice. So while you can call native code via JNI, it's nowhere near as practical as writing it with intrinsics in C code. In addition, you get compiler optimizations to your native code if you use intrinsics from C, if you do it via JNI you lose all interprocedural optimization.
I think generally the libraries in Java help programmers use data structures that make the language seem faster (trees/hashes) .
These structures exist in c++ but aren't as easy to use so aren't used as frequently.
Those processors extensions will make mathy c++ code significantly faster. When I was on an ada project all the mathy code was written in c/c++ for speed. Pretty amazing the difference.
What? C++ comes with robust trees & hashes via the STL, along with a pretty extensive library of algorithms that work on all the STL containers. And, unlike Java, C++ lets you pack value objects contiguously in memory, which can be a massive performance win due to better cache behavior/no pointer chasing.
And, unlike Java, C++ lets you pack value objects contiguously in memory, which can be a massive performance win due to better cache behavior/no pointer chasing.
Certainly, and it is one of the features that I am often missing in Java. Rather than having an array of structs, you need to make n parallel arrays, where n is the number of struct fields. And sometimes such hacks are necessary to make things compact and fast.
But I do understand why they don't provide value types. Say, that I am allocating an array of foobar_t. And foobar_t is defined in another library. If the author of the other library changes the layout of foobar_t, you get ABI breakage. This is what brought the whole PIMPL/d-pointer mess that is often necessary in C++ and to some extend C libraries.
IBM's Java 7 and 8 beta's already have this. It's called Packed Objects and it lets you have have high density data with no pointer chasing along with a much cleaner interface to off-heap languages like C/C++/C# and even languages like Fortran/COBOL etc.
Java is not as fast or faster than C(++). The assertion always makes me cringe. I won't say Java is slow(though the startup time is annoying for some tasks), as it does perform better than many languages. But how does it make sense to you that a platform written in C can produce results faster than C is capable of?
There is no contradiction that a compiler written in a language with expensive semantics (say python), could compile a program written in another language (say C) to produce highly efficient machine code.
The JVM operations, such as JIT compilation and garbage collection, are bound by the performance of C code.
The performance of the code you write depends significantly on the quality of the machine code produced by the JIT compiler. This quality of this code is not theoretically dependent on the implementation language of the JIT.
> There is no contradiction that a compiler written in a language with expensive semantics (say python), could compile a program written in another language (say C) to produce highly efficient machine code.
Maybe not a contradiction in logic, no. But in practice the compiler has to solve a problem that is much harder than the problem the programmer would have to solve to write efficient C code for this one case. It's also one that has different complexity.
So you're in the situation now that a few compilers (VERY few, though this is very very hard to do) will actually beat stupid programmers in optimization, but there is nothing any compiler can do to beat the optimizations a good programmer will implement.
As for startup time, the sad part of that is that is one area where you could really improve C/C++ : startup time. Right now a C program has 4 distinct things that need to run before main() starts, and involve quite a bit of calculation, C++ has a lot more (the various kinds of initializers which can cause arbitrarily complex calculation).
A lot of these initializers result in constant (and small) memory layouts, and could in fact be run at compile time. What you generally do in initialization phase is to calculate registered classes (e.g. for serialization, or protocols) and make indexes of them. Maybe even compile regexes. All of that could be optimized to occur at compile time (as long as memory usage of the code is reasonable).
You think I am saying that a compiler can do optimization better than a human.
What I assert is that the implementation language of a the tool that generates machine code guarantees nothing about either the source language, or the quality of the generated code. This was the assertion of the parent that invalid. He said that because the Java JIT compiler was written in C, that necessarily implies that the generated machine code would be slower that C.
Consider an Assembler, written in C, that generates machine code. By your logic you can't argue that assembly code is always less efficient than C.
Or alternatively Fortran compilers, written in C, which produce machine code that outperforms code generated from C for many tasks.
What language do you think your favorite C compiler is written in?
Now compare that C compiler to the jvm compiler, which has the benefit of using detailed information about the exact system configuration and other runtime behaviours during its compilation phases.
The JVM compiler compiles for the JVM, which is written in C. So, how again can something written in C perform faster than...something written in C?
I'm not claiming that line by line transcription, C will always perform each particular operation faster than Java. But the fact that you could write the entire JVM in C means that you could recreate the exact platform and replicate the results. Is that sane? No, not really.
Comparing languages is typically silly, as it mostly boils down to implementation. If you -really- intend to compare speeds of languages, it would necessitate writing the best possible code in both languages, which may or may not even resemble each other. Under those circumstances, Java is not capable of beating C. Ever.
I don't understand why this is an argument anymore, it doesn't really even make much sense...unless my definition of 'language speed' is unusual.
The JVM compiler compiles for the JVM, which is written in C. So, how again can something written in C perform faster than...something written in C?
Well, first of all, the JVM generates machine code, not C.
Apart from that, you can easily be shown to be wrong. If you are compiling a binary with C, you are compiling for the lowest common denominator. Say, if you are compiling for x86_64, you are probably compiling for all x86_64 CPUs. You can optimize for newer instances of x86_64 (say Core i3), but you cannot use any instructions that are not available on e.g. Core 2, if that is the lowest common denominator that you support.
The Java VM could, on the other hand, decide to use instructions during the compilation of hot spots which are available on a Core i3 and not on a Core 2, when it detects that the CPU is a Core i3.
> The JVM compiler compiles for the JVM, which is written in C
This is absurd.
First of all, there isn't one JVM. There are dozens to chose from, many of them certified. Each implemented in whatever language their designers have chosen.
Some JVMs are meta-circular, meaning they are also written in Java. For example, Squawk, Maxime, Jikes RVM.
Second, even if you mean Oracle's JVM, the embedded version is not the same as the desktop/server one, one uses C the other C++.
Not to mention that after Java 8's release, Hotspot might be replaced by Graal, the new JIT compiler written in Java as well.
Currently being developed and already in use by AMD for their Java/GPGPU work.
Both the JVM and a C compiler produce native machine code that is executed by the processor directly. Neither is an interpreter in the classic sense[1]. It doesn't matter what language they're written in -- you could write C compiler or a JVM in PHP (assuming it can make the syscalls to load object code at runtime). No matter how awful the performance of the PHP runtime is, it would not prevent the C or Java program executed from being fast (in the long run).
Because the eventual target is native code, the only limit on performance[2] is what program transformations the compiler is willing to perform. This is limited by how much information the compiler has, and what sort of transformations are valid in the language.
For the first, it's about a wash. Java has a mix of 'safety' features that may obligate inserting checks at runtime that C would assume away, but it also forbids a lot of things that a C compiler would have to accept that limit the ability to optimize programs. In particular, a C compiler has to make a lot of pessimistic assumptions about what all those pointers are doing and what happens to memory across an external function call.
JVMs have a solid advantage in the second -- it performs the equivalent of profile guided optimization at runtime against real usage patterns, something that AFAIK no C compiler even attempts... and the runtime tooling needed to turn C into something you could JIT-optimize would result in something I don't think most C programmers would recognize.
A third issue is GC, which is on by default in Java-land and off by default in C: if your program is under very little memory stress and has very complex memory access patterns, the overhead of malloc()/free() is going to be huge compared to the cost of running the occasional GC. But, if your program is under strong memory stress and the logic to determine when to malloc() and when to free() is trivial, GC overhead will be a serious issue.
None of this means a given Java environment is faster than a given C environment but there's not really anything you could assume from first principles that makes one faster than the other. Neither reaches the ultimate "speed of light" of computation that is self-modifying hand-tuned machine code favored by all Real Programmers[3].
But the real bottom line for performance is which language has faster library implementations, and which has idioms that programmers actually use that produce faster or slower code. Those considerations are probably going to be way more important than the hypothetical top speed of a perfect program made by cycle-counting weenies. It's also the sort of thing you'd have to run actual experiments at large scale to answer.
[1] the JVM might interpret Java bytecode that isn't frequently run based on some optimization heuristic, but it doesn't have to. A 100% JIT emitting JVM could exist, and might even be a JVM flag for all I know.
[2] if you ignore the time JVM spends optimizing at load/JIT time, which you can in most cases aside from startup time.
> So, how again can something written in C perform faster than...something written in C?
Easy. JVM has runtime information it can use that C compiler simply doesn't have. There are some synthetic benchmarks that show how "java is faster than C".
There's far more than branch prediction optimization, which AFAIK, is bread and butter of profile-guided optimization.
Even that assumes that your program does not significantly shift its behavior mid-execution--in fact, you're optimizing for the average, not the current case.
One of the coolest JIT things is ability to inline virtual calls. Think about that, I could have my code calling a 3rd party library calling another 3rd party library thru 10 levels of stack and if all that call ever returns is "false", then JIT will optimize right through all that.
I don't believe PGO does virtual call inlining. That's a C++ nonstarter. In C, the equivalent would be inlining for function pointer calls.
doesnt matter,the jvm takes a lot of resources which is problematic is some situations.raw speed is nothing without the memory footprint or AAA games would be written in java.they are not for a good reason:lack of direct memoy management.
I am not saying one should use it or not, or how it is strictly better than something else, just saying I can easily see _in theory_ how a jit compiler written in C can be faster than plain C.
> But how does it make sense to you that a platform written in C can produce results faster than C is capable of?
It's actually quite easy.
Now, of course for every Java program there exists a C++ program that performs at least as well – proof: the JVM – but that doesn't mean that that program could be written by humans at acceptable cost. The JVM does a lot of optimistic inlining that's simply not possible in C/C++ (in those languages you'll need to write the same code lots of times).
But in any case, it's perfectly possible that a platform written in C could produce results faster, because it's not an interpreter but a compiler that translates the application directly to machine code, and which could benefit from optimizations not available ahead-of-time.
If by "lack of", you mean "4 choices":
DirectByteBuffers (Azul/IBM/OpenJDK/Oracle etc)
Packed Objects (IBM)
Real-time Java (Azul/IBM)
Unsafe (Azul/Oracle/IBM/OpenJDK etc)
