3 ms·

This is nice, but I can't help but feel it's a little wrong that we're still making free-lists like in the olden days.

by thirsteh 13y ago

tptacek 13y ago
You absolutely don't need to do any of this to write Go programs that outperform Ruby or Python.
- thirsteh 13y ago
  Generally, sure. But it's still pretty easy to write garbage-generating Go applications that exhaust memory because the GC isn't compacting. In some applications this is a nobrainer: use a free list. In some others, like when you don't actually know what kind of buffer size you'll need, it's not so easy (although you could argue you should just fixed-sized chunks for whatever you're doing, and recycle those, but that's a lot of work.) What I'm saying boils down to: Free lists are definitely useful, but the GC could be better.
  - jbooth 13y ago
    "Could be better" is of course true for every single situation, no matter how good. But even Java, which has what is generally regarded as the most advanced GC ever written, still has lots of applications doing the free-list of ByteBuffers or even better, the free-list of off-heap-allocated DirectByteBuffers which don't have to be moved during tenured generation compactions. It seems pretty reasonable to me to have one or two freelists at the spots you're frequently allocating 64kb buffers, along with using the GC for the other 5,000 allocations in your project.
    - thirsteh 13y ago
      Sure. No disagreement. Let me put it another way: Go's GC is still in its infancy compared to those in most other languages. It's perfectly fine to use, but there are some big things (e.g. no compaction) that stick out when using the language, whether you're working with free-lists or something else.
      - tptacek 13y ago
        I think you're going to find that even with no attention to allocation at all, your Golang programs are going to outperform their Ruby and Python equivalents. That's a dicier assertion to make versus other languages, notably Java, but if you're coming to Golang from a high level language like Python, you're probably going to be happy with the performance you get out of naive code.
        thirsteh 13y ago
        You're right (except for some cases like crypto and regex where other languages "cheat" by using C bindings or unstable versions), but that isn't where it has bit me. In general all my Go programs have been more than fast enough, but on several occasions I've had memory starvation problems that I would not be having in other languages (even if there is a way to do it without doing a lot of allocation and fragmentation in Go.) I love Go, but "it's fast" isn't a good reason not to improve a subpar GC. (Which fortunately isn't a position the Go team is taking. I know everyone there would like to see a lot of interesting things happen with the GC. It just hasn't been one of the more pressing issues so far, and I've agreed. It's also a very difficult and "boring" thing to work on for most people, so it's not surprising that somebody hasn't just added an Azul C4-style concurrent GC in their spare time.)
        aaronblohowiak 13y ago
        Yes, Golang is very young and its gc is one of the more 'immature' portions. However, in comparison to the tools that it is regularly displacing the overall speed is still a huge win. Eventually, Golang will get a better gc and in the meantime we can already enjoy faster programs. Nobody is arguing that the gc of today should be Golang's gc forever.
        wglb 13y ago
        Have you noticed the starvation in 64 bit programs or 32 bit programs?
        13y ago
    - cmbaus 13y ago
      I agree, given the type of issues they are addressing (very high throughput application servers), I don't think a general purpose allocator (garbage collected or not) will ever get the performance they want. Recycling buffers is not a bad strategy for this type of application, no matter the language.
  - JulianMorrison 13y ago
    When malloc() has to deal with defragmenting allocations of varying length, I believe it does it by allocating from several pools each holding blocks of a fixed size, picking the smallest category that will fit. It wouldn't be hard to extend the buffered-channel technique to do this.
zwieback 13y ago
The olden days are not that old. I find myself using static arrays, free lists, malloc and its OO brethren as well as GC when available. All of those things have been around for as long as I can remember. It's nice not to have to worry about freeing allocated memory but if you write a lot of low-level code there's a certain level of unease about letting the language or OS take on something that can have such a large performance impact.

This is nice, but I can't help but feel it's a little wrong that we're still making free-lists like in the olden days.

tptacek 13y ago

You absolutely don't need to do any of this to write Go programs that outperform Ruby or Python.

thirsteh 13y ago
Generally, sure. But it's still pretty easy to write garbage-generating Go applications that exhaust memory because the GC isn't compacting. In some applications this is a nobrainer: use a free list. In some others, like when you don't actually know what kind of buffer size you'll need, it's not so easy (although you could argue you should just fixed-sized chunks for whatever you're doing, and recycle those, but that's a lot of work.) What I'm saying boils down to: Free lists are definitely useful, but the GC could be better.
- jbooth 13y ago
  "Could be better" is of course true for every single situation, no matter how good. But even Java, which has what is generally regarded as the most advanced GC ever written, still has lots of applications doing the free-list of ByteBuffers or even better, the free-list of off-heap-allocated DirectByteBuffers which don't have to be moved during tenured generation compactions. It seems pretty reasonable to me to have one or two freelists at the spots you're frequently allocating 64kb buffers, along with using the GC for the other 5,000 allocations in your project.
  - thirsteh 13y ago
    Sure. No disagreement. Let me put it another way: Go's GC is still in its infancy compared to those in most other languages. It's perfectly fine to use, but there are some big things (e.g. no compaction) that stick out when using the language, whether you're working with free-lists or something else.
    - tptacek 13y ago
      I think you're going to find that even with no attention to allocation at all, your Golang programs are going to outperform their Ruby and Python equivalents. That's a dicier assertion to make versus other languages, notably Java, but if you're coming to Golang from a high level language like Python, you're probably going to be happy with the performance you get out of naive code.
      - thirsteh 13y ago
        You're right (except for some cases like crypto and regex where other languages "cheat" by using C bindings or unstable versions), but that isn't where it has bit me. In general all my Go programs have been more than fast enough, but on several occasions I've had memory starvation problems that I would not be having in other languages (even if there is a way to do it without doing a lot of allocation and fragmentation in Go.) I love Go, but "it's fast" isn't a good reason not to improve a subpar GC. (Which fortunately isn't a position the Go team is taking. I know everyone there would like to see a lot of interesting things happen with the GC. It just hasn't been one of the more pressing issues so far, and I've agreed. It's also a very difficult and "boring" thing to work on for most people, so it's not surprising that somebody hasn't just added an Azul C4-style concurrent GC in their spare time.)
        aaronblohowiak 13y ago
        Yes, Golang is very young and its gc is one of the more 'immature' portions. However, in comparison to the tools that it is regularly displacing the overall speed is still a huge win. Eventually, Golang will get a better gc and in the meantime we can already enjoy faster programs. Nobody is arguing that the gc of today should be Golang's gc forever.
        wglb 13y ago
        Have you noticed the starvation in 64 bit programs or 32 bit programs?
        13y ago
  - cmbaus 13y ago
    I agree, given the type of issues they are addressing (very high throughput application servers), I don't think a general purpose allocator (garbage collected or not) will ever get the performance they want. Recycling buffers is not a bad strategy for this type of application, no matter the language.
- JulianMorrison 13y ago
  When malloc() has to deal with defragmenting allocations of varying length, I believe it does it by allocating from several pools each holding blocks of a fixed size, picking the smallest category that will fit. It wouldn't be hard to extend the buffered-channel technique to do this.

zwieback 13y ago

The olden days are not that old. I find myself using static arrays, free lists, malloc and its OO brethren as well as GC when available. All of those things have been around for as long as I can remember. It's nice not to have to worry about freeing allocated memory but if you write a lot of low-level code there's a certain level of unease about letting the language or OS take on something that can have such a large performance impact.