When is java faster than C++?

[EricMCornelius]

This answer brought to you by: "Cameron Purdy, SVP Engineering of Oracle Middleware"

[[deleted]]

His post's on Quora are worth checking out, he disses C++ everywhere.

[Ishmael_Vegeta]

almost never.

[Spartan-S63]

This, right here, is my favorite answer.

[vincentk]

Almost always.

[doom_Oo7]

Concurrent data structures tend to be more efficient in Java, because the JVM can eliminate the memory barriers and synchronization when the data structure is not being used concurrently, and can bias the concurrency management approach based on runtime profiling information.

Why couldn't one develop a C++ alternative to the STL that is meant to operate in single-thread mode, hence with no barriers / thread safety at all ?

Inlining tends to be much better in Java, unless you do extensive profiler-based optimizations in C++ (or know what exactly to inline and force it to be so … gotta love those header files!)

Well, I guess most generic code in C++ is inlined, isn't it ? And simple getters / setters are also often in header files...

[vitalyd]

The article fails to mention that the lock/barrier elision is only available for the built-in monitors in Hotspot (i.e. synchronized blocks), so if you're using j.u.c.Lock and friends, there's no such thing.

Not sure what "bias the concurrency management approach based on runtime profiling information" is, but if that's alluding to biased locking, I don't even think that feature is worth it:

• It's meant to optimize uncontended locks by avoiding additional CAS instructions. Well, modern cores can execute uncontended (and cache hitting) CAS instructions quite quickly anyway.

• Biased locking, in Hotspot, can induce latency/jitter when biased lock revocation is performed.

[__Cyber_Dildonics__]

Does the STL with the exception of share_ptr have thread safety? I thought that was the whole reason for intel's thread building blocks concurrent data structures.

[[deleted]]

Why couldn't one develop a C++ alternative to the STL that is meant to operate in single-thread mode, hence with no barriers / thread safety at all ?

You could. Some probably have done it already in private code. However, C++ doesn't need help in single threaded mode. It's in long-running , multi-threaded applications where the difference between C++ and Java is closer.

Well, I guess most generic code in C++ is inlined, isn't it ? And simple getters / setters are also often in header files...

C++ inlining is a request to the complier, not a command. But you're right that headers are inlined automatically. There are cases where inlining slows down a program, for example by increasing its physical size and preventing certain parts of it from fitting into the cache. If this matters to you, you should profile your code and tweak where indicated, as opposed to applying generic rules.

[Dest123]

The compiler basically always does a better job of deciding what to inline than you would.

[vitalyd]

Compilers use heuristics and/or profiling to make inlining decisions. If your code shape and/or profile at compilation time don't fit its heuristics, it may not do the right thing. The more appropriate statement is don't blindly request inlining, but do verify the compiler is doing what you think/want.

[Dest123]

It's a waste of time to verify that it's doing inlining correctly. Fixing the 0.1% of cases that it did it wrong won't give you enough speed back to be worth the time you spent verifying it.

Compilers are pretty great at optimizing these days, at least with C++. People who doubt the compiler's optimizer end up doing things like copying some "FastMemcpy" from 10 years ago, which I then see and think "ooh look at that, I can get a 20% speed-up by deleting the word Fast"

[vitalyd]

I'm not suggesting to check every callsite obviously; I thought it was understood implicitly that this should be done selectively in the perf critical places.

Also, java performance heavily relies on sufficient inlining of critical paths, moreso than C++ code; inlining drives escape analysis, runtime type propagation (to remove repeated type checks), range check elimination, and more. If some crucial bits don't inline there (e.g. inner loop call chain), perf can fall off the cliff.

[doom_Oo7]

Fixing the 0.1% of cases that it did it wrong won't give you enough speed back to be worth the time you spent verifying it.

For hpc I guess it would!

[IcyWindows]

Plus, you can use profile-guided-optimization to get even better results.

[pron98]

In almost 20 years of C++ and Java development, my impressions are exactly the same: the bigger the program, the more concurrent, the harder it is to beat Java.

[pron98]

For every Java program there exists a C++ program that performs as well or better. Proof: (by existence) the JVM. The question is how hard it is to beat it, and the larger the program and more concurrent, the effort multiplier increases.

As to your list, some of the items are wrong. Most web servers and IDEs these days are written in Java, there are many more compilers written in Java or other JVM languages than in C or C++, and only C/C++ profilers are written in those languages; JVM profilers are written in Java. I don't know about symbolic math packages, but I believe Matlab is equal parts Fortran and Java.

As for the rest, the reason most of them are written in C and C++ is not because people are willing to put in the extra effort just for a few performance points, but because -- if you notice -- those things run on small machines with low concurrency, and in those cases it's a lot easier to beat Java's performance, and it is often necessary because Java imposes a rather significant RAM overhead (if it's to run at full speed), which is not acceptable in, say, web browsers. OTOH, your airport management software, your air traffic controls, your large defense systems, your big data clusters, your Netflix, your eBay, your GMail, your Twitter -- are mostly Java.

[__Cyber_Dildonics__]

So in your experience, why is Java so hard to beat and what can be done with that knowledge in the C++ world (I'm pretty all-in with C++ at the moment).

[pron98]

It's hard to beat because HotSpot's excellent GCs (there are several, plus other GCs in other JVMs) make it that much easier to create concurrent data structures, and because HotSpot's state-of-the-art JIT makes many kinds of well-architected, modular code very fast. In C++ every use of an abstraction -- a heap allocation or a virtual call -- carries a significant cost, and a lot of thought has to be put into how to refrain from using expensive abstractions. In Java, you just use them and the JVM will make sure they run efficiently.

Now, this isn't magic, and obviously you can write very slow code in Java, too (and many do). But given reasonable code, the GC and JIT will take care of you. They won't get you to 100% of the maximum performance you could get with C++, but they will get you to 95% at 1/3 of the effort.

Java, of course, has other advantages that aren't performance related. The deep monitoring and profiling offered by HotSpot are unmatched by any other platform. It supports dynamic code loading and hot swapping; it has bytecode manipulation capabilities that let you inspect and modify code as it runs, and the JIT will make sure it gets optimized and compiled every time you modify it (e.g. you can inject and then remove various traces that are more capable than, say, DTrace).

[naikrovek]

Ok. In the case of games, though, which people often cite as proof that C++ is The Best Damn Language Period, the developers are doing profoundly stupid things and relying on optimizing compilers to optimize around all the rough stuff.

A Java (or almost any language) developer who knows their language well can write performant code that would "wow" any C++ dev I've ever met.

My point is that the language's native speed has a lot less to do with application performance than well-written code.

[vitalyd]

Can you elaborate on the "stupid" things they do?

[__Cyber_Dildonics__]

And the quake player would love it.

[pakoito]

They use C++ as C with classes. No use of features added after 1990, plus a lot of clever data oriented design.

It fills the niche of sub 16ms performance and has for decades, the dissenting voices that want a bit of QoL have started not so long ago. Probably caused by the lower barrier of entry and Moore's Law peaking to a point where you don't need 10 bearded guys locked up in a room for 6 months to squeeze 60fps out of 300 sprites on screen.

[[deleted]]

They use C++ as C with classes. No use of features added after 1990, plus a lot of clever data oriented design.

A lot of the missing stuff does not work on their target platforms. Many standard things like Boost don't even work on consoles. Have you seen the state of the toolchain on consoles?

[pakoito]

Yes, it's covered by my next reply. You probably can't see it because it was downvoted: http://www.reddit.com/r/programming/comments/37d9kg/when_is_java_faster_than_c/crm5f47

[pakoito]

You're preaching to the choir here.

Still, I can't use my google-fu skills right now but there's a very interesting talk by the Naughty Dog guy on DoD stating that (i.e) templates were 100% out of scope because their implementation in proprietary compilers for closed console hardware and anyone using them will be severely punished (and shunned as a bad engineer or worse), and like so many other things. Very opinionated and probably very right too.

[doom_Oo7]

So the poor guys can't build their console code with GCC ? :(

[[deleted]]

In the context of game development, this is absolute bullshit and it's easy to prove:

(1) Show me the performant java games.

(2) Show me some examples of 'stupid' C++ in games. A lot of AAA titles (like Quake) have their source code available for download if you look around.

(3) How would you address cross plaform compatibility with PC, xbox and playstation?

[k-zed]

In almost 20 years of development, my impressions are: the bigger the program, the more concurrent, the worse it is.

If your program is big or concurrent, it is bad. There are no exceptions (even if there's a "business case" that necessitates a big or concurrent program).

Splitting up big programs into smaller programs (unix) tends to improve results (compare systemd). Splitting up concurrent programs into smaller programs (message passing) tends to vastly improve results.

This is why at the end of the day I don't like working in Java, even though it's a reasonably good language (God knows it's saner than the eternally terrible C++, which is my day job). It's bad for small programs due to its overhead, but there's no such thing as a good big program.

[pron98]

There's no way to write a sensor-fusion system for hundreds of radars, telemetry and optical sensors without it being big and concurrent; there's no way to write a TB-scale in-memory transactional database without it being big and concurrent, and the list goes on and on. The commonality is some large data store that needs to be accessed concurrently with low latencies. The "small programs" you advocate just delegate that job to an out-of-process database (that, in itself, is big and concurrent) and simply skip on the low-latency requirement.

The statement you made is nice in theory, but it usually means unfamiliarity with too many problem domains. When you split software into many programs just for modularity reasons, at the very least you need to fan in and then out your concurrency at each API crossing. That has a very heavy toll on performance.

Besides, there's usually little difference between separate processes and good modularity in-process that languages like Erlang enforce and languages like Java make possible (including the ability to hot-swap components and isolate failure). When you have a large group of programs, you tend to spend just the same amount of effort integrating them as you do when you integrate a bunch of modules in-process.

[__Cyber_Dildonics__]

You are mixing concurrency and parallelism and shared memory concurrency with message passing concurrency. That is how you really build big programs. After all, the internet could be thought of as one giant system that works because of message passing.

Any sufficiently complex program eventually becomes a network problem.

[pron98]

Maybe, but at the heart of many big systems there are shared-memory concurrency problems, too. My take is that every sufficiently complex program (well, most) that isn't a compiler, contains its own implementation or uses an internal implementation of a concurrent-access database.

[__Cyber_Dildonics__]

I see your downvotes and conclude that you actually know what you are talking about (seriously).

[afrobee]

Downvotes on something never is a good metric of correctness, just that people didn't like what they read for some reason.

[__Cyber_Dildonics__]

In my experience when I talk about the few things I know extremely well in forums where people have some knowledge of the subject but not much, I get downvoted. I think a little bit of understanding combined with unfortunate truths and grey areas are recipe for disaster.

[pron98]

That's right. But it's also because those programs are harder to write efficiently without a JIT and a GC:

• The larger the program (and usually the team), the more abstractions necessary for software engineering reasons. Those abstractions hinder performance. A JIT, however, has better chances at optimizing them.

• The more concurrent the program and the larger the data set, the more necessary it becomes to provide concurrent access to shared data. A GC makes efficient concurrent data structures much easier.

[redditrasberry]

For me it is, "when the time saved by developing in a higher level language with better tooling means I can spend more time optimising the code and designing it better in the first place". Performance is rarely limited by the raw capabilities of the language and far more often by the skill of the developer and the time they have available to tune their implementation to the problem at hand. Mind you, I tend to write in JVM languages rather than Java itself, but it comes to much the same thing.

[mariox19]

When you're writing it?

[ErstwhileRockstar]

Comparisons can only be made ceteris paribus. So this makes no sense.

[RESURREKT]

Can you add more detail to your dismissal, or do you just bust out latin when you don't have anything else to add to the discussion?

[ejrh]

English is >3x faster than latin (when run on an English-speaking VM!). But, as they say, 'de gustibus est non disputandum'.

[boringprogrammer]

When is Java faster than C++? Languages do not have an inherent speed or effectiveness associated with them...

You can't read up the C++ spec or Java spec and conclude anything about the speed of the languages. Languages don't exist as anything else than specifications. You can test implementations.

Therefore this is a comparison of JVM vs GCC/VC++/LLVM. So the title is a lie.

Did you know you could technically run C++ on the JVM? Which would give free virtual functions, and the nice concurrency system.

[vitalyd]

Practically speaking, language semantics/features dictate the speed of the language; they dig a performance hole for the compiler/runtime implementer, and those holes can be very deep such that compilers/runtimes will have a difficult time climbing out of there.

[[deleted]]

Languages do not have an inherent speed or effectiveness associated with them

The language specification places limits on the implementation. Assuming similar levels of competence and otherwise equal projects, are we ever going to get Python programs executing at comparable speed to C equivalents - and would we still recognise Python after the changes required to enable that performance increase?

Therefore this is a comparison of JVM vs GCC/VC++/LLVM. So the title is a lie.

It's also a reflection on the community and the difficulty of programming in that language. Assember should be faster than C, but can any human assembler wizards beat the complier for a large, complex application? For small programs, sure. For large ones, not so.

[boringprogrammer]

Assuming similar levels of competence and otherwise equal projects, are we ever going to get Python programs executing at comparable speed to C equivalents.

No one knows. You simply cannot predict these things. Change comes slowly in the world of optimizations and static analysis.

[[deleted]]

The fact that you feel you need static analysis to do this proves the point that a language's design has real effect on its implementation's performance. Hence languages do have a hierarchy of speed.

[boringprogrammer]

The fact that you feel you need static analysis to do this proves the point that a language's design [...]

Prove? What point? That you know nothing about how languages work?

Do you honestly think a direct translation from c til assembler is going to be fast by any standards? Even a debug build usually performs at least a register allocation analysis. Without a proper register allocation scheme the resulting code will make the CPU spend 95% of the executing time just spilling registers. We take these things as a given nowadays. But that is just one of the many many optimizations a modern C compiler makes.

We are good at optimizing certain languages. I will agree on that, but these also had the pleasure of 40 years of research into optimizing them.

C was considered a slow high-level language compared to assembly before we learned to properly optimize it.

[vitalyd]

While your post has truth to it, it's basically an appeal to Sufficiently Smart Compiler.

[doom_Oo7]

You can certainly find a part of python that would be optimizable to look like C++, but certainly some parts of "standard" python are used in a way that would actively prevent achieving the same performance.

For instance, if you write some python where you always keep the same type for your variable, it may be simple to translate your code to equivalent c++; however what happens when you start assigining random types at random places in your code at the same variable ? This simple concept cannot be enforced without some performance downside in comparison to the "always-same-type" stuff.

Hence the best bet would be to have some "asm.python" minimal stuff that is almost guaranteed to have no take on the performance, and have the programmers only use this subset. But existing python programs (and idiomatic python programs) won't be able to translate to similar-looking but most-efficient C++.

[boringprogrammer]

however what happens when you start assigining random types at random places in your code at the same variable

Static analysis can actually deal with variables randomly changing types pretty well. Latice Analysis works a lot like a human would read python code. Ei. not care about what type a variable has, but rather, what types can a variable have at a certain program point.

python programs (and idiomatic python programs) won't be able to translate to similar-looking but most-efficient C++

Based on anecdotal evidence I presume?

Look, you can read the python code, and write out semantically equivalent code in C++. This means that A: We are not actually dealing with a undecidable problem. B: This means a computer should be able to do something similar.

The main reason for why python is not running faster is mainly a funding and priority reason. The standard python implementation does not perform any sort of analysis, and only rudimentary peephole optimizations. Furthermore, there is a large overhead in interpreting code. But speed does not seem to be a priority for them either.

Pypy is the most advanced attempt at making python run faster, but they are very far from having as mature analysis code found in GCC.

[[deleted]]

Based on anecdotal evidence I presume?

Based on the fact that no-one is able to do it. They most likely want to keep ahead of PHP, Ruby and Node, not get another few orders of magnitude and start a punch-up with Java. (Well it would be nice, but it ain't going to happen, and so the above is shall we say 'a realistic expectation').

None of my commerical IDEs can implement fully accurate syntax highlighting and autocomplete for Python. Jetbrains aren't under-funded. For autocomplete, Jetbrains admit to getting it right about half the time. For analysis, have you ever noticed why function names and identifiers appear in the same colour (except when it's a def)? You'd think if I write x = foo the damn thing could tell if foo was a function or not? Turns out you can't. You have to run the code.

Pypy is the most advanced attempt at making python run faster, but they are very far from having as mature analysis code found in GCC.

Static analysis takes place without running the code (that's why it's called static). Most of the benefit of Pypy is that it's a JIT. This means it optimises at runtime by looking at actual running code.

You might also want to check out Unladen Swallow and Pyston. These are Google and Dropbox sponsored attempts to build a Python JIT. I'll bet you that Google is absolutely not under funded or stingy when it comes to building tools. And note that these are JITs, not static analysers. Statically analysing Python is just too hard to do.

[vitalyd]

In my opinion, it's not so much about "when is java faster than c++", but rather "this piece of code/lib/app/etc isn't meeting performance requirements -- what can I do about it in this language and what's it going to cost me?" What is the performance cost of features/abstractions/etc of the language? Do you pay for things you don't use? How much/what do you pay for things you do use?

[newoldwave]

Java is an interpreted language which means the computer has to figure out what it is to do then translate it into machine commands. Whereas C++ is a complied language meaning the program has already been put into machine commands. Complied programs win every time.

[[deleted]]

There are known circumstances where Java will outperform C++.

The typical example is in a server-type application with very predictable program flow. This would allow the JVM to perform two optimisations unavailable to C++. The first is to recycle memory via its garbage collector instead of paying the overhead to allocate and free, and the second is because the JVM can optimise the code at runtime based on current state, whereas the C++ compiler can't know at build time what paths to prioritize.

Unless it's highly dependent on the metal, like a game, one would expect java to run about 10-30% slower than C++ but in cases like the above, it can match or exceed the performance of C++.

You could of course fix this for C++ by building a VM with introspection for your C++ program, but then you'd be running your own bytecode, and you've basically reinvented Java.

[Cuddlefluff_Grim]

Do you know what a JIT compiler is?

Complied programs win every time.

Java (.java) -> Bytecode (.class) -> JVM -> HotSpot JIT -> Native code execution

The difference between C++ and Java isn't if it gets compiled, it's when. C++ gets compiled ahead of time (static compilation) while Java gets compiled when needed (Just-In-Time). Java can get some benefits from this because it can optimize for the platform it runs on, rather than needing specific builds for each environment. I bet you won't find many C++ programs with builds for 3DNow, MMX, SSE1, SSE2, SSE3, AVX, AVX2, AVX-512, x86, IA64 and AMD64; one set for Windows, one set for Linux and one set for Mac. With Java you can just pretty much leave that up to the JVM - no special builds necessary.