[jandrewrogers]

Sampling bias. Most of the people responding are probably those with a strong opinion because of what they work on. Everyone else is likely relatively indifferent to it.

It is a misconception that GCs only affect latency-sensitive systems. High-performance throughput-optimized systems are also sensitive at ~1µs granularity for different reasons, so GCs are not used there either.

That a GC is adverse to the performance both latency-oriented and throughput-oriented workloads doesn't leave many use cases in "high-performance" systems. Maybe systems that are severely I/O bound but is barely a thing these days.

[sph]

> Maybe systems that are severely I/O bound but is barely a thing these days.

Any kind of web service is barely a thing today? Which is what 99% of HN posters are working on, hence my comment.

> High-performance throughput-optimized systems are also sensitive at ~1µs granularity for different reasons, so GCs are not used there either

Games are high-performance throughput-optimized systems that have adopted GC languages for 15+ years now, and again a type of application which is much more latency sensitive than most people deal in their day to day.

Nobody is claiming GC is a panacea, but it’s good enough for a lot more use cases people give it credit for.

[jandrewrogers]

If you are severely I/O bound it isn't intrinsic, it means your server is badly under-provisioned in the I/O department. Linux on a modern server can push 200 GB/s of I/O. Even if web services were engineered to a standard that could consume that much I/O, which they are not, you would have to be astonishingly wasteful to burn it all.

It is rare to be severely I/O bound because software engineered for I/O performance tends to run out of memory bandwidth first.

Games are not throughput-optimized systems in any conventional sense. They are a canonical example of latency-optimized systems.

I have nothing against GCs, I use them regularly even in performance-sensitive contexts. But too many people understate the adverse impact of GCs on performance contrary to evidence and theory.

[sph]

I/O bound means waiting on I/O, which isn’t necessarily because it is slow, but because it is simply waiting on data to arrive, like a web service most of its idle time. If your client is dozens of milliseconds away, a GC pause is pretty much invisible, unless you are trying to squeeze every last request/second from a machine (instead of simply scaling horizontally)

That said, from your profile, you seem to work on a very sensitive niche that might colour your opinion, with good reason. What I am claiming is most of us are not building such strict a system.

Even in my toy hobby of OS development a GC isn’t the end of the world unless your goal is to compete with, say, Linux in a some kind of performance challenge, where in that case memory allocation might be the least of your bottlenecks.

[pjmlp]

So you also are fully skilled in using value types, stack allocation and GC region free memory in such languages?

[wolvesechoes]

> Most of the people responding are probably those with a strong opinion because of what they work on

Quite the opposite. People here have strong opinion because they work on web apps and CLI toys.

[pjmlp]

It is also a misconception that all GC are born alike, and that don't exit languages with support for value types, stack allocation and GC free memory regions with C like pointer fun if so desired, while being mostly GC enabled.

[senderista]

Could you elaborate on "GCs are not used there [high-performance throughput-optimized systems]"? Are you referring to the cascading effects of tail latency on systems with high fanout?

[jandrewrogers]

Sophisticated throughput-optimized systems rely on deep latency-hiding. Schedulers see millions of atomic operations into the future, continuously rewriting the schedule globally to maximize locality and minimize resource contention based on real-time changes to workload, resource availability, and system behaviors.

In short, for each of the millions of in-flight operations (which might only map to a handful of user operations), it is trying to precisely optimize the concurrency, timing, and dependency sequencing such that when operations are executed every resource required is hot, uncontended, and available with high probability. When this works well it dramatically reduces the number of hidden stalls in execution. The schedule is constrained by tail latency requirements; a theoretically throughput-optimal schedule can defer execution indefinitely.

For an analytical database engine, an "atomic operation" is typically a query operation on a database page. A modern server can retire 100M ops/sec. While I am oversimplifying a bit, a 1 millisecond GC pause can blindly wreck the schedule for 100,000 operations in an unpredictable way. In these architectures we try to eliminate all context switches for the same reason which are 100x cheaper.

Practically, 1µs stall is a good heuristic for a noise floor. The schedulers have pretty wide concurrency on big systems, so the implied 100 operations are unlikely to have a dependency. Many stalls that are difficult to precisely control like cache line fills fit in here too.

If there was a GC that had a worst-case stall of 1µs then you could probably use it for these cases. Unfortunately, "low-latency" GCs tend to be more like 1000x that. I don't think there is any way of closing that gap short of putting a GC in hardware.

[pjmlp]

Real time GC as used by the military in weapons control systems, and on factory automation robots, keeping PTC and Aicas in business, people pay to use them.

[jandrewrogers]

TBH, physics limits how latency-sensitive weapons systems need to be and you can largely just disable the GC in these contexts. They use CPUs from the 1990s to do hypersonic terminal guidance. You don’t have to do any performance engineering for many latency-sensitive weapon systems. Could probably write it in Javascript.

For throughput-optimized systems, some of which are real-time, you never see a GC. That loss in performance is simply too large such that the computation becomes intractable. A lot of really poor systems admittedly exist but no one considers them “good”.

[pjmlp]

Throughput-optimized systems like HFT?

https://www.lmax.com/exchange/technology

No, you could not guide battleship weapons in Javascriptt

https://www.lockheedmartin.com/en-us/products/aegis-combat-s...

https://dl.acm.org/doi/abs/10.1145/2402709.2402699

And no they don't disable the GC, they have real time GC implementations,

https://www.ptc.com/en/products/developer-tools/perc

[jandrewrogers]

I think you may be confused about what "throughput-optimized" means. HFT is not throughput-optimized by definition. The LMAX link literally says it is a latency-optimized system. An optimal throughput-optimized system has unbounded worst-case latency -- the opposite of "latency-optimized".

None of those links contradict anything I wrote, I am already familiar with all of them.

[Capricorn2481]

> Most of the people responding are probably those with a strong opinion because of what they work on.

I can assure you that's not the case on here. The people working in truly low latency environments are not commenting on GC threads to begin with because it's a non-starter for them. For whatever reason, there is just a chunk of people that eat a lot of FUD around GCs who are working in the exact domains they thrive in.

[senderista]

Not to mention that in general GC simply requires more memory.