4 ms·

> 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

> 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.

socialdemocrat 4y ago
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.
cogman10 4y ago
> 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.
- mypalmike 4y ago
  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.
- pcwalton 4y ago
  > 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.
  - cogman10 4y ago
    Dang, I thought go was at least copying/moving. So it'll be roughly arena allocation performance.
- littlestymaar 4y ago
  > 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. 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)
  - cogman10 4y ago
    I'd give this article a read to understand how java gets around this problem. https://dzone.com/articles/thread-local-allocation-buffers 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.

socialdemocrat 4y ago

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.

cogman10 4y ago

> 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.

mypalmike 4y ago
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.
pcwalton 4y ago
> 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.
- cogman10 4y ago
  Dang, I thought go was at least copying/moving. So it'll be roughly arena allocation performance.
littlestymaar 4y ago
> 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. 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)
- cogman10 4y ago
  I'd give this article a read to understand how java gets around this problem. https://dzone.com/articles/thread-local-allocation-buffers 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.