Hacker News Reader

Comment by cogman10 | Hacker News Reader

Sarcasm aside, it is possible for Go to beat C in some scenarios.

The secret is the garbage collector. In high memory allocation applications a GC can be more efficient than direct heap allocations. This is especially true if the C/C++ application is making heavy use of reference counting. A GC will ultimately have lower overhead than managing the reference counting.

All that said, in pure CPU calc scenarios with low allocations, C will almost certainly beat the pants off of go. Go's compiler is... subpar. Yes, it compiles fast, but it does that by ditching optimizations (perhaps this changes with LLVMGo).

View on HN

> In high memory allocation applications a GC can be more efficient than direct heap allocations.

Anybody who cares about allocation speed in C or C++ (or Rust or <insert low level language>) will use arena / bump / slab allocators. GC is more efficient when you're writing naive code and you don't get to write naive code if you care about speed / memory usage.

I'm not saying it's not possible to reach or surpass C-like speeds with Go, but when comparing C to higher level languages with GC there should be an asterisk next to the statement you're making.

But this is hardly like comparing to Java as Go gives you a lot of flexibility in how you organize, allocate and use memory thanks to pointer support and composite value types. Making an Arena allocator is something you could do in Go as well.

But it is hard to manage memory effectively everywhere in C without creating a lot of overhead for the programmer.

> will use arena / bump / slab allocators.

While not always the case, it is often the case that a good GC will beat all of those. A generational copying GC with parallel collection will treat most allocations as pointer bumps. Giving them the speed of a bump allocator with periodic fragmentation fixes when collection happens. It will beat both slab and arena allocators.

> naive code and you don't get to write naive code if you care about speed / memory usage.

I mean, you can certainly always implement a GC in C (most GCs are implemented in C/C++). Which does suggest that anything you can do with a GCed language can ultimately be replicated in a memory managed language.

However, the point of a GC is that naive code IS faster and easier to reason about. You don't have to create and manage elaborate data specific object pools in order to get the same speeds as if you did.

The other thing to consider about GCs is they enable algorithms that are really hard to replicate in memory managed languages. Concurrent algorithms are WAY easier to reason about because you don't have to wrap your head around object lifetime with thread lifetime.

Very nicely stated. Being able to more easily reason about code, as enabled by GC, allows the kinds of large refactorings and algorithmic optimizations that people working on C codebases tend to shy away from.

That said, I've definitely seen use cases, particularly in games, where memory pools are clearly optimal. And certainly the deterministic nature of such pools has advantages as well.

> While not always the case, it is often the case that a good GC will beat all of those. A generational copying GC with parallel collection will treat most allocations as pointer bumps. Giving them the speed of a bump allocator with periodic fragmentation fixes when collection happens. It will beat both slab and arena allocators.

Unfortunately Go's allocator is none of those. It has slow allocation performance because they don't do generational GC.

Dang, I thought go was at least copying/moving. So it'll be roughly arena allocation performance.

Wouldn't memory barrier add a significant overhead in this case? (compared to an arena not needing any memory synchronization at all if it's only needed on a single thread)

I'd give this article a read to understand how java gets around this problem.

https://dzone.com/articles/thread-local-allocation-buffers

The short answer is that for java at least (and I suspect other GCs in other languages, but haven't confirmed) there's a thread local allocation buffer which is just the pointer bumps.

Thanks, I'll read that.

Does escape analysis play into it? This could allow the Go compiler to reduce the number of heap allocations (which are not free in either language), which in turn also reduces the load on the GC.

I'm not familiar with the state of go escape analysis. It would play into it, but then you'd also argue that you don't need it in C because you'd simply put that sort of thing on the stack rather than the heap.

GC will win when heap allocations are frequent, short lived, and unavoidable.

> a GC can be more efficient than direct heap allocations

Unoptimised, naive allocations perhaps. I'm old enough to still remember when Microsoft used similar line of reasoning to create artificial cases where C# beat C++ performance.

I would wager that the majority of C/C++ codebases (e.g. internal business code) use naive allocation. In C++ particularly, naive allocation (I might define this as straight up "has-a" ownership-based heap allocations and deletions) is considered best practice by many.

Not only that, shared_ptr is also popular in such codebases, and shared_ptr usually has an additional allocation to store reference count in the "control block".

shared_ptr is nothing more than low latency GC that can't handle cycles. It's the extreme end of the latency throughput tradeoff.

Given that most C++ code in modern Windows applications is for jungling COM instances, no need for artificial cases when every couple of lines there is a Release() or AddRef() call, with possible OS IPC in the middle.

Reply on news.ycombinator.com