5 ms·

I'll assume you're talking about throughput, rather than latency/real-time constraints. I'm pretty dubious, given that Google extensively utilizes C++ in their

I'll assume you're talking about throughput, rather than latency/real-time constraints. I'm pretty dubious, given that Google extensively utilizes C++ in their more performance sensitive portions of their architecture. Their custom web server, for example, is written in C++. Lets not forget the rather large HPC codebases out there in Fortran. Can you prove any of this?

pron 14y ago
Obviously, Java is less predictable than C++ so it's not suitable for hard real-time (though RTSJ JVMs are!), but I'd say that in the common case, Java would have lower latencies, too (when everything is compiled after a good warmup). I don't know why Google uses C++, but I'd guess that it's for predictability. A web server would rather always have a reasonably low latency than somewhat lower latencies in most cases with a chance for an occasional latency spike. Also, small, well-contained C++ program would probably perform better than Java, and I don't know how big is each of Google's C++ apps. And like I said, this is very hard to prove; it's just been my experience after replacing a couple of legacy C++ apps with Java ones. But I think it could be "theoretically proven" (if that even means anything for such an empirical claim), by analyzing why and where C++ has any performance advantages vs. where Java has them, and showing that the larger the codebase and the team, the C++ advantages must disappear, while Java's become more significant. Just to give two examples of why that should be: in a large application, the domain model might require some class methods to be virtual. The JVM can detect at runtime that in practice only one or two implementations are present, and would inline them. This is not possible for the C++ compiler. The other example is memory management. Java's memory allocation is so much faster than malloc (it's just a pointer bump), allows for better concurrency, and automatically reduces fragmentation. The way to get good memory management in C++ is by forsaking malloc for manual management (say, object pools), but that becomes increasingly difficult to maintain in a large, ever shifting codebase with many developers involved. Also, Java has better concurrency support which is, as you've said, important for throughput. The only counter example is arrays of structs that are simply not supported on the JVM, and where C++ would have obvious cache-miss advantages.
- Symmetry 14y ago
  Does dynamic compilation really that much better than profile guided optimization? That is, I suspect that in the situation you describe a C++ compiler using PGO would do just as well at detecting which of the implementations are present. In theory this might change between runs, but I can't believe that's as common as it being the same.
  - pron 14y ago
    I suspect that in the situation you describe a C++ compiler using PGO would do just as well Quite possibly, though not necessarily better. And you still won't have the memory management advantages. But let me revise my statement: if you have unconstrained development resources, you could probably make large C++ software a little faster than a Java counterpart in many cases, but that little improvement would come at a very big development cost in almost all cases.
    - Symmetry 14y ago
      In cases where developers have unconstrained resources I'd actually expect C{,++} to be about 50% faster than Java as you see in the programming languages shootout due to better ability to optimize memory use. But I'd expect most professionally produced software to use PGO, and hence get most of the same benefit from runtime information as Java.
      - pron 14y ago
        But you can't optimize large software that has to be maintained. Even if you could (because you have unlimited resources), you won't be getting a 50% improvement because you'll be spending a lot of the time on IO and task switching anyway. And just to make sure: whatever improvement you get will be very costly. We're talking manual control of memory fences, NUMA memory allocation and placement, lock biasing and more. All stuff the JVM does a very good with little effort for the Java programmer.

pron 14y ago

Obviously, Java is less predictable than C++ so it's not suitable for hard real-time (though RTSJ JVMs are!), but I'd say that in the common case, Java would have lower latencies, too (when everything is compiled after a good warmup). I don't know why Google uses C++, but I'd guess that it's for predictability. A web server would rather always have a reasonably low latency than somewhat lower latencies in most cases with a chance for an occasional latency spike. Also, small, well-contained C++ program would probably perform better than Java, and I don't know how big is each of Google's C++ apps. And like I said, this is very hard to prove; it's just been my experience after replacing a couple of legacy C++ apps with Java ones. But I think it could be "theoretically proven" (if that even means anything for such an empirical claim), by analyzing why and where C++ has any performance advantages vs. where Java has them, and showing that the larger the codebase and the team, the C++ advantages must disappear, while Java's become more significant. Just to give two examples of why that should be: in a large application, the domain model might require some class methods to be virtual. The JVM can detect at runtime that in practice only one or two implementations are present, and would inline them. This is not possible for the C++ compiler. The other example is memory management. Java's memory allocation is so much faster than malloc (it's just a pointer bump), allows for better concurrency, and automatically reduces fragmentation. The way to get good memory management in C++ is by forsaking malloc for manual management (say, object pools), but that becomes increasingly difficult to maintain in a large, ever shifting codebase with many developers involved. Also, Java has better concurrency support which is, as you've said, important for throughput. The only counter example is arrays of structs that are simply not supported on the JVM, and where C++ would have obvious cache-miss advantages.

Symmetry 14y ago
Does dynamic compilation really that much better than profile guided optimization? That is, I suspect that in the situation you describe a C++ compiler using PGO would do just as well at detecting which of the implementations are present. In theory this might change between runs, but I can't believe that's as common as it being the same.
- pron 14y ago
  I suspect that in the situation you describe a C++ compiler using PGO would do just as well Quite possibly, though not necessarily better. And you still won't have the memory management advantages. But let me revise my statement: if you have unconstrained development resources, you could probably make large C++ software a little faster than a Java counterpart in many cases, but that little improvement would come at a very big development cost in almost all cases.
  - Symmetry 14y ago
    In cases where developers have unconstrained resources I'd actually expect C{,++} to be about 50% faster than Java as you see in the programming languages shootout due to better ability to optimize memory use. But I'd expect most professionally produced software to use PGO, and hence get most of the same benefit from runtime information as Java.
    - pron 14y ago
      But you can't optimize large software that has to be maintained. Even if you could (because you have unlimited resources), you won't be getting a 50% improvement because you'll be spending a lot of the time on IO and task switching anyway. And just to make sure: whatever improvement you get will be very costly. We're talking manual control of memory fences, NUMA memory allocation and placement, lock biasing and more. All stuff the JVM does a very good with little effort for the Java programmer.