Garbage collection is completely orthogonal to the quality of emitted codegen.
What GC does have impact on is the way VM handles memory management:
- Cost of allocation helper calls / are they (partially) inlined
- Cost of write barriers
- Cost of GC pauses, their frequency or the cost paid in other places if it's shifted from GC pauses (which Go does)
- Cost of thread suspension/yielding strategy - relates to the previous point but is distinct should a GC have full stop-the-world phase
Generally speaking, Go's compiler is weak but where Go manages to get performance back are two areas:
- Go forces you to write a lot of, effectively, manually inlined code by virtue of being painful to use abstractions and generics in
- By constraining the range of tools you can use, it focuses on providing lightweight implementation for those (e.g. channels)
This allows Go to excel at particular niche it is targeted at (networked back-end services) but results in its severe underperformance against expectations the moment you step away from that use case.
Both JVM and .NET are good counterexamples to Go that being garbage collected does not mean sacrificing performance. Unfortunately, historical choices in JVM prevent it from reaching zero-cost abstraction + low/zero-allocation style of performance oriented code in C, C++ and Rust so C# remains pretty much the only GC-based language that lets you do so.
Swift receives honorable mention but it appears to consistently have much worse performance due to ARC and virtual dispatch so it can't really compete unless you write totally-not-C code in it.
You’re arguing against my point while going on to make the same point.
Please note that I said “optimised” and not “quality”. The GP said quality but I deliberately didn’t. I want to be clear that myself and the author were strictly talking about code that is optimised for execution speed.
There are a few other issues with your comment too. Such as conflating inlining with code deduplication wrt generics.
What GC does have impact on is the way VM handles memory management:
- Cost of allocation helper calls / are they (partially) inlined
- Cost of write barriers
- Cost of GC pauses, their frequency or the cost paid in other places if it's shifted from GC pauses (which Go does)
- Cost of thread suspension/yielding strategy - relates to the previous point but is distinct should a GC have full stop-the-world phase
Generally speaking, Go's compiler is weak but where Go manages to get performance back are two areas:
- Go forces you to write a lot of, effectively, manually inlined code by virtue of being painful to use abstractions and generics in
- By constraining the range of tools you can use, it focuses on providing lightweight implementation for those (e.g. channels)
This allows Go to excel at particular niche it is targeted at (networked back-end services) but results in its severe underperformance against expectations the moment you step away from that use case.
Both JVM and .NET are good counterexamples to Go that being garbage collected does not mean sacrificing performance. Unfortunately, historical choices in JVM prevent it from reaching zero-cost abstraction + low/zero-allocation style of performance oriented code in C, C++ and Rust so C# remains pretty much the only GC-based language that lets you do so.
Swift receives honorable mention but it appears to consistently have much worse performance due to ARC and virtual dispatch so it can't really compete unless you write totally-not-C code in it.