[Capricorn2481]

What type and size of applications have you worked on?

@pron, who works on the JVM and is a C++ expert, has been writing a lot recently about low level languages becoming increasingly impossible to optimize with more LOC and more people working on it (dozens, or even hundreds of developers).

The idea being be a language with an aggressive JIT, moving garbage collector, and bump allocation is going to allocate/deallocte faster than malloc, and get the most important average optimizations at all times, where as the equivalent low level app will struggle to get the ideal allocation pattern the more people that work on it, or be forced to use slow dynamic dispatch. He wouldn't describe a GC as pessimistic, he'd say it's literally faster, and that's why he (a C++ programmer) works on it. The JVM was built by people saying "we are doing a handful of the same things in C++ all the time."

There are specific cases where it's good to have low level control, but they aren't everywhere.

[jandrewrogers]

I work on analytical data engines. Lots of spatial and graph-like joins on PB-to-EB scale data models often concurrent with extremely high rates of real-time ingest into the same data model. I’ve also done a lot of work in HPC and more conventional databases at smaller scales. Typical code base is in the range of 100k-1M LoC in C++. Java has more LoC equivalent but it isn’t used much for these applications anymore because it scales significantly worse as systems and hardware become larger.

Almost all optimization is architectural in nature. Properly performance-engineered code allocates no memory after bootstrap. There is no possible way even in theory for a GC to outperform schedule-aware allocation from a fixed pool. In most cases the GC is just generic C++ code anyway; that indirection is unnecessary.

An important caveat is that I mostly deal with throughput-optimized code. It isn’t latency-sensitive and this article is about low-latency code. Nonetheless, the schedulers require predictable execution at ~1µs granularity for throughput optimization purposes, which is difficult to guarantee in Java.

I can write highly optimized code in C++ in a straightforward way that doesn’t really have a Java equivalent because equivalent guarantees are not provided as a practical matter.

TBH, even when I wasn’t trying to performance-engineer code I’ve never seen Java run as fast as the equivalent C++.

[MaxBarraclough]

> There is no possible way even in theory for a GC to outperform schedule-aware allocation from a fixed pool.

You mean in the absence of any reference-counting overhead? That doesn't sound like a fair comparison.

> In most cases the GC is just generic C++ code anyway; that indirection is unnecessary.

You can't use the JVM's GCs from C++. C++ heavily relies on RAII, so it doesn't seem like a good fit anyway. I'm not aware of any serious efforts at a high performance GC for C++.

As Herb Sutter points out, moving GCs require non-stable pointers, which C++ isn't suited to. [0]

> the schedulers require predictable execution at ~1µs granularity for throughput optimization purposes, which is difficult to guarantee in Java

Can't say I know much about that kind of issue, how does it work in C++ code?

[0] https://herbsutter.com/2011/10/25/garbage-collection-synopsi...

[MaxBarraclough]

I recommend his recent appearance on the Inside Java podcast, where these topics are explored well. The episode is number 59, titled Java *is* Memory Efficient.

https://www.youtube.com/watch?v=M_HCG1JPMQE (or any podcast application)