5 ms·

Please excuse my ignorance, but here goes: Been a Go dev for almost 3 years now. I am basically shitting myself over the prospect of all the Go code out there

Please excuse my ignorance, but here goes: Been a Go dev for almost 3 years now. I am basically shitting myself over the prospect of all the Go code out there turning from something I understand, to something riddled with generics, of which I have no concept whatsoever. I've built some pretty complex stuff entirely without them and never felt there was anything missing, but maybe I just never knew what I was missing. Now, I also don't know what a ring buffer is, so perhaps this is the perfect time for someone very generous to explain to me what a ring buffer is, why generics are what enabled this and how on earth it's multiple times faster than channels, which have been a first-class primitive in Go since the beginning (and should therefore have had the living daylights optimised out of them...) Many thankings :)

pjmlp 5y ago
A memory bound queue and by making use of generics, it has more performance due to having one indirection less per element and being able to store all of them in a continuous memory segment.
- throwaway77384 5y ago
  Thank you, much appreciated!
- ithkuil 5y ago
  That doesn't answer the question though. Go channels (and slices and maps) are special built-in types that are already "generic", i.e. they have type parameters: "make(chan Foo, 10)". Is there some property of the built-in buffered channel contract that makes it hard to implement as efficiently as this ring buffer? Anyway. The ability to implement user-defined data structures with the full power of the language (e.g. building your own 'chan T') allows one to choose some different guarantees and target different use cases
  - lijogdfljk 5y ago
    If it is indeed faster, my gut is that it wasn't generic, it was "generic" hah. Ie runtime reflection was used instead of true compile-time generics. Runtime reflection has a cost, and is (was!) one the strongest arguments against Go. All powerful "generic" code you'd write in Go heavily relied on reflection over interfaces that caused memory behavior commonly associated with worse performance. Compile-time generics can often perform similar behavior but with a far better memory layout resulting in better performance. Purely speculation though about `chan`, i have no clue.
    - dfawcus 5y ago
      Have a look at the runtime, on my system the code is in /usr/local/go/src/runtime/chan.go There are some reflection calls in there, together with mutex lock/unlock and calls to 'typedmemmove' which seems to involve the use of memory barriers (mbarrier.go in the same directory).
spoiler 5y ago
I won't go into super much detail, but think of generics as functions over types that generate new types based on type inputs (gross oversimplification). Comparable to functions that take value and return values, also it happens before your program runs (during compilation/build time). A ring buffer is just a normal buffer, except that when it "runs out" of space instead of overflowing or returning an error, it "loops back" on itself, and starts writing from the start. You can still grow it, if needed. The nice thing about generics here is that it allows you to have a RingBuffer[string], RingBuffer[int], and RingBuffer[MyType] without having to implement them separately. The compiler will even take care of memory sizing/layout, and all the other razzledazzle. As for performance, it's not fully related to generics, but a sibling comment explained the implementation detail and how it affects performance.
- throwaway77384 5y ago
  Thank you for the information. Much appreciated!
- travisby 5y ago
  It might also be worth comparing to the stdlib's `container/ring` implementation of a non-generic ring buffer, to see how your code might differ between `RingBuffer[string]` and how the `interface{}` version of container/ring works! https://pkg.go.dev/container/ring#example-Ring.Do https://pkg.go.dev/container/ring#example-Ring.Do The casting back and forth from T and `interface{}` is expensive, boilerplatey/extracode, and panic-prone.
- gavinclarke0 5y ago
  I implemented it using generics not for performance gains but to avoid type assertions and interfaces which I find are a major source of error and side step many of the benefits of a type safe language. Any performance gains is merely a side affect.
stevefan1999 5y ago
if you have not known what a ring buffer is, may I suspect you to be a developer who taught yourself?
- throwaway77384 5y ago
  I certainly am, yes. Spent about 12 years in the wrong career and then realised my love for programming (after a lifelong love of computers. Not sure how I missed that...) I started with Python (and Kivy). Then went on to Go (which felt like a revelation over Python. For me, anyway). Along with that came JS, HTML, CSS and React. Because of Go, I had become prejudiced against interpreted, dynamically typed languages. But over time I actually came to quite like JS. If wielded correctly, it can be very quick to get stuff working in JS and now I think either kinds of languages have their merits. Though, admittedly, React still eludes me. It feels incredibly confusing to me. My next port of call will probably be something like Rust, but I have a product that takes up all of my time, so it's a bit tricky to find the time to catch up on my CS learning. There is probably nothing that can replace a full-on university education in CS, but I'm not sure when or where I'd fit that into my life (I have a degree and thus know what it takes). I really hope to be able to do as much of that education on my own, however. Any tips or hints welcome!
  - holografix 5y ago
    That’s a cool background. Can you share more about your product? I’m also struggling to see the great benefit of generics apart from “it’s quicker than using interface types, trust us”. I didn’t know a ring buffer was a “formal” data structure thingy but implemented one for a toy multiplayer game I’m building very slowly. There’s a “circular list” of the 5 last received messages from the server and if the position as indicated by the server deviated above a certain threshold I warp the player back to where they should be according to the server. I knew these message objects were gonna be allocated/nuked constantly so I just have 5 one pointing to the other and the last pointing back to the first and I go around overwriting them.
    - styluss 5y ago

pjmlp 5y ago

A memory bound queue and by making use of generics, it has more performance due to having one indirection less per element and being able to store all of them in a continuous memory segment.

throwaway77384 5y ago
Thank you, much appreciated!
ithkuil 5y ago
That doesn't answer the question though. Go channels (and slices and maps) are special built-in types that are already "generic", i.e. they have type parameters: "make(chan Foo, 10)". Is there some property of the built-in buffered channel contract that makes it hard to implement as efficiently as this ring buffer? Anyway. The ability to implement user-defined data structures with the full power of the language (e.g. building your own 'chan T') allows one to choose some different guarantees and target different use cases
- lijogdfljk 5y ago
  If it is indeed faster, my gut is that it wasn't generic, it was "generic" hah. Ie runtime reflection was used instead of true compile-time generics. Runtime reflection has a cost, and is (was!) one the strongest arguments against Go. All powerful "generic" code you'd write in Go heavily relied on reflection over interfaces that caused memory behavior commonly associated with worse performance. Compile-time generics can often perform similar behavior but with a far better memory layout resulting in better performance. Purely speculation though about `chan`, i have no clue.
  - dfawcus 5y ago
    Have a look at the runtime, on my system the code is in /usr/local/go/src/runtime/chan.go There are some reflection calls in there, together with mutex lock/unlock and calls to 'typedmemmove' which seems to involve the use of memory barriers (mbarrier.go in the same directory).

spoiler 5y ago

I won't go into super much detail, but think of generics as functions over types that generate new types based on type inputs (gross oversimplification). Comparable to functions that take value and return values, also it happens before your program runs (during compilation/build time). A ring buffer is just a normal buffer, except that when it "runs out" of space instead of overflowing or returning an error, it "loops back" on itself, and starts writing from the start. You can still grow it, if needed. The nice thing about generics here is that it allows you to have a RingBuffer[string], RingBuffer[int], and RingBuffer[MyType] without having to implement them separately. The compiler will even take care of memory sizing/layout, and all the other razzledazzle. As for performance, it's not fully related to generics, but a sibling comment explained the implementation detail and how it affects performance.

throwaway77384 5y ago
Thank you for the information. Much appreciated!
travisby 5y ago
It might also be worth comparing to the stdlib's `container/ring` implementation of a non-generic ring buffer, to see how your code might differ between `RingBuffer[string]` and how the `interface{}` version of container/ring works! https://pkg.go.dev/container/ring#example-Ring.Do https://pkg.go.dev/container/ring#example-Ring.Do The casting back and forth from T and `interface{}` is expensive, boilerplatey/extracode, and panic-prone.
gavinclarke0 5y ago
I implemented it using generics not for performance gains but to avoid type assertions and interfaces which I find are a major source of error and side step many of the benefits of a type safe language. Any performance gains is merely a side affect.

stevefan1999 5y ago

if you have not known what a ring buffer is, may I suspect you to be a developer who taught yourself?

throwaway77384 5y ago
I certainly am, yes. Spent about 12 years in the wrong career and then realised my love for programming (after a lifelong love of computers. Not sure how I missed that...) I started with Python (and Kivy). Then went on to Go (which felt like a revelation over Python. For me, anyway). Along with that came JS, HTML, CSS and React. Because of Go, I had become prejudiced against interpreted, dynamically typed languages. But over time I actually came to quite like JS. If wielded correctly, it can be very quick to get stuff working in JS and now I think either kinds of languages have their merits. Though, admittedly, React still eludes me. It feels incredibly confusing to me. My next port of call will probably be something like Rust, but I have a product that takes up all of my time, so it's a bit tricky to find the time to catch up on my CS learning. There is probably nothing that can replace a full-on university education in CS, but I'm not sure when or where I'd fit that into my life (I have a degree and thus know what it takes). I really hope to be able to do as much of that education on my own, however. Any tips or hints welcome!
- holografix 5y ago
  That’s a cool background. Can you share more about your product? I’m also struggling to see the great benefit of generics apart from “it’s quicker than using interface types, trust us”. I didn’t know a ring buffer was a “formal” data structure thingy but implemented one for a toy multiplayer game I’m building very slowly. There’s a “circular list” of the 5 last received messages from the server and if the position as indicated by the server deviated above a certain threshold I warp the player back to where they should be according to the server. I knew these message objects were gonna be allocated/nuked constantly so I just have 5 one pointing to the other and the last pointing back to the first and I go around overwriting them.
  - styluss 5y ago