3 ms·

I already agreed that allocation is faster in Java than in Go. What I'm saying is that allocation speed is less critical in Go than in Java. In Java, if you al

I already agreed that allocation is faster in Java than in Go. What I'm saying is that allocation speed is less critical in Go than in Java. In Java, if you allocate an object containing 10 other objects, you have to allocate 11 objects, because you only only have reference types (I know there is ongoing work to introduce value types). This is more work for the allocator, and for the GC. In Go, you allocate only once. Honestly, I'm not sure about this issue being very significant for most programs in either Go or Java. As a reminder, most C, C++ and Rust programs don't use a bump allocator either and they're doing well.

littlestymaar 9y ago
> What I'm saying is that allocation speed is less critical in Go than in Java. Indeed. In fact, Go couldn't afford not to have a generational GC without value type and Java would be really slow with Go's GC. > As a reminder, most C, C++ and Rust programs don't use a bump allocator either and they're doing well. C, C++ and Rust can't use a bump allocator since you need a compacting GC to do so. But allocations are really expensive in these languages and removing them is often the first step of optimization.
- ngrilly 9y ago
  > Go couldn't afford not to have a generational GC without value type And Java couldn't afford not to have value types without a generational GC ;-) > C, C++ and Rust can't use a bump allocator since you need a compacting GC to do so. But allocations are really expensive in these languages and removing them is often the first step of optimization. Agreed. This is why Go programmers use the same optimizations as C, C++ and Rust programmes is such a case (by allocating from a pool or an arena). Are you aware of cases where what is gained thanks to the bump allocator is lost because of compaction?
  - littlestymaar 9y ago
    > Agreed. This is why Go programmers use the same optimizations as C, C++ and Rust programmes is such a case (by allocating from a pool or an arena). Yes, unfortunately in Go allocations are harder to avoid[1] than in C++ or Rust, because Go rely on escape analysis whereas objects must be manually boxed in the other languages. [1]: https://groups.google.com/forum/#!topic/golang-nuts/Vcgx7hkhd3Q https://groups.google.com/forum/#!topic/golang-nuts/Vcgx7hkh...
    - ngrilly 9y ago
      It's not "unfortunate". It's a known drawback of the tradeoff chosen by Go.
      - pcwalton 9y ago
        Which can be effectively mitigated by having a generational garbage collector!
- jashmatthews 9y ago
  > C, C++ and Rust can't use a bump allocator since you need a compacting GC to do so. But allocations are really expensive in these languages and removing them is often the first step of optimization. Not true. You can use exactly the same techniques in C, C++ and Rust. It's called arena based allocation. Even malloc calls can be very cheap. The Hoard allocator uses bump pointer allocation for malloc into empty pages!
- yoklov 9y ago
  > C, C++ and Rust can't use a bump allocator since you need a compacting GC to do so. It's actually very common to do this in performance oriented code. You allocate a decently sized temporary chunk of memory at the start of some period of work (say a frame of a game, or something like that) and then most/all temporary allocations are done from that in a bump pointer fashion. None of it get's freed, but in practice this isn't a big problem as long as you allocate a sufficiently large buffer (or handle overflow by allocating a second) At the end of the period of work, you free the buffer. In the end you pay for a single malloc/free (and even this you can reduce if you re-use the buffer multiple times), despite having possibly many more allocations. The downside is that you have some restrictions, you need to be sure none of the objects in the buffer outlives it, in C++ you probably want to ensure all the objects you allocate from it are trivially destructible, etc. Either way, it's very common to do this sort of thing, at least in C and C++. That's partially because the system allocator is typically slow, but mostly because this sort of control is a big reason to use languages like this.

littlestymaar 9y ago

> What I'm saying is that allocation speed is less critical in Go than in Java. Indeed. In fact, Go couldn't afford not to have a generational GC without value type and Java would be really slow with Go's GC. > As a reminder, most C, C++ and Rust programs don't use a bump allocator either and they're doing well. C, C++ and Rust can't use a bump allocator since you need a compacting GC to do so. But allocations are really expensive in these languages and removing them is often the first step of optimization.

ngrilly 9y ago
> Go couldn't afford not to have a generational GC without value type And Java couldn't afford not to have value types without a generational GC ;-) > C, C++ and Rust can't use a bump allocator since you need a compacting GC to do so. But allocations are really expensive in these languages and removing them is often the first step of optimization. Agreed. This is why Go programmers use the same optimizations as C, C++ and Rust programmes is such a case (by allocating from a pool or an arena). Are you aware of cases where what is gained thanks to the bump allocator is lost because of compaction?
- littlestymaar 9y ago
  > Agreed. This is why Go programmers use the same optimizations as C, C++ and Rust programmes is such a case (by allocating from a pool or an arena). Yes, unfortunately in Go allocations are harder to avoid[1] than in C++ or Rust, because Go rely on escape analysis whereas objects must be manually boxed in the other languages. [1]: https://groups.google.com/forum/#!topic/golang-nuts/Vcgx7hkhd3Q https://groups.google.com/forum/#!topic/golang-nuts/Vcgx7hkh...
  - ngrilly 9y ago
    It's not "unfortunate". It's a known drawback of the tradeoff chosen by Go.
    - pcwalton 9y ago
      Which can be effectively mitigated by having a generational garbage collector!
jashmatthews 9y ago
> C, C++ and Rust can't use a bump allocator since you need a compacting GC to do so. But allocations are really expensive in these languages and removing them is often the first step of optimization. Not true. You can use exactly the same techniques in C, C++ and Rust. It's called arena based allocation. Even malloc calls can be very cheap. The Hoard allocator uses bump pointer allocation for malloc into empty pages!
yoklov 9y ago
> C, C++ and Rust can't use a bump allocator since you need a compacting GC to do so. It's actually very common to do this in performance oriented code. You allocate a decently sized temporary chunk of memory at the start of some period of work (say a frame of a game, or something like that) and then most/all temporary allocations are done from that in a bump pointer fashion. None of it get's freed, but in practice this isn't a big problem as long as you allocate a sufficiently large buffer (or handle overflow by allocating a second) At the end of the period of work, you free the buffer. In the end you pay for a single malloc/free (and even this you can reduce if you re-use the buffer multiple times), despite having possibly many more allocations. The downside is that you have some restrictions, you need to be sure none of the objects in the buffer outlives it, in C++ you probably want to ensure all the objects you allocate from it are trivially destructible, etc. Either way, it's very common to do this sort of thing, at least in C and C++. That's partially because the system allocator is typically slow, but mostly because this sort of control is a big reason to use languages like this.