4 ms·

This is a case in which generational GC can help. If you allocate goroutine stacks in the nursery, then you can use a bump allocator, which makes the throughput

This is a case in which generational GC can help. If you allocate goroutine stacks in the nursery, then you can use a bump allocator, which makes the throughput extremely fast. Throughput of allocation matters just as much as latency does! (By the way, Rust used to cache thread stacks back when it had M:N threading, because we found that situations like this arose a lot.)

shereadsthenews 8y ago
You can't bump-allocate 6K contiguous to an existing 2K allocation, and Go currently requires the stack to be contiguous.
- pcwalton 8y ago
  That's right, but you can bump-allocate a new 6K and copy over. It's a lot faster than falling through to a general-purpose malloc implementation.
  - shereadsthenews 8y ago
    That’s not obviously true. Page sized and page aligned allocation is pretty fast in Go. Having a generational GC where all pointers are movable could have systemic impact in the performance of the whole program.
    - pcwalton 8y ago
      If it were fast enough, then caching stacks wouldn't be a win. Bump allocation is like 6 instructions. The idea that generational GC would not be a win does not match the experience of any other language. Generational GC is virtually always a win for languages like Go. This is just another reason why Go should adopt it.
      - shereadsthenews 8y ago
        It's possible. Go has been replaying the entire history of GC research at about 2.5x forward speed. They should intercept the state of the art eventually.
      - readittwice 8y ago
        Isn't it a win because the goroutine now starts with 4K of stack instead of 2K? This makes the stack large enough, such that the stack doesn't have to expanded on every request.
readittwice 8y ago
It might make allocation a bit faster, but is this really where performance was lost? I guess for the runtime it is more expensive to copy the stack contents (so nearly 2K) and e.g. update pointers in it (a simple memcpy might not be enough).

shereadsthenews 8y ago

You can't bump-allocate 6K contiguous to an existing 2K allocation, and Go currently requires the stack to be contiguous.

pcwalton 8y ago
That's right, but you can bump-allocate a new 6K and copy over. It's a lot faster than falling through to a general-purpose malloc implementation.
- shereadsthenews 8y ago
  That’s not obviously true. Page sized and page aligned allocation is pretty fast in Go. Having a generational GC where all pointers are movable could have systemic impact in the performance of the whole program.
  - pcwalton 8y ago
    If it were fast enough, then caching stacks wouldn't be a win. Bump allocation is like 6 instructions. The idea that generational GC would not be a win does not match the experience of any other language. Generational GC is virtually always a win for languages like Go. This is just another reason why Go should adopt it.
    - shereadsthenews 8y ago
      It's possible. Go has been replaying the entire history of GC research at about 2.5x forward speed. They should intercept the state of the art eventually.
    - readittwice 8y ago
      Isn't it a win because the goroutine now starts with 4K of stack instead of 2K? This makes the stack large enough, such that the stack doesn't have to expanded on every request.

readittwice 8y ago

It might make allocation a bit faster, but is this really where performance was lost? I guess for the runtime it is more expensive to copy the stack contents (so nearly 2K) and e.g. update pointers in it (a simple memcpy might not be enough).