15 ms·

Well sure. Not writing hand tuned assembly can make your code slower, too. Go's value as a language is how it fills the niche between Rust and Python, giving yo

Well sure. Not writing hand tuned assembly can make your code slower, too. Go's value as a language is how it fills the niche between Rust and Python, giving you low level things like manual memory control, while still making tradeoffs for performance and developer experience.

mrweasel 5y ago
I might have worded it differently, but yeah, of cause generics can make your code slower, what did people expect.
- tsimionescu 5y ago
  It depends what they are replacing. Typically, generics used to replace runtime polymorphism (using [T any] []T instead of []any) would be a speed boost in C#, C++, or Rust; and would have no impact on speed in Java.
  - morelisp 5y ago
    And it is also a speed boost in Go, assuming you don't call any methods. (Which, if you were really using [T any], you either weren't or you were dissembling about your acceptable types.)
- zellyn 5y ago
  I don't know about you, but when I imagine what compilers do with generic code, I typically imagine monomorphization, which (aside from increasing cache pressure a little), should generally not make things slower, but rather introduce possibilities for inlining that could make it faster.
  - mrweasel 5y ago
    Apparently I scrolled right past that bit of the article. I’m a little unsure how it’s suppose to make the code faster, but maybe because I compare it wrong. The alternative to generics is writing all the different function by hand, in my mind at least. I don’t fully understand how generics are suppose to be made faster than a custom function for that datatype.
    - wtetzner 5y ago
      I think the reasoning is that for something that's commonly used for many different types, you won't go through the effort of re-implementing that function for each type (it may not even be feasible to do so). Which means you'll end up with some sort of indirection to make it generic.
    - mcronce 5y ago
      The point is they shouldn't be slower than a manually-copied implementation for that concrete type. They also should be faster than vtable dynamic dispatch in the vast majority of cases. (I also fail to see a compelling reason that they couldn't have been implemented by passing the fat pointer directly, making the codegen the same as passing an interface, instead of having that business with the extra layer of indirection.) If there are specialization opportunities when hand-implementing the function for a given concrete type, I would indeed expect that to be faster than a monomorphized generic function.
    - masklinn 5y ago
      > I don’t fully understand how generics are suppose to be made faster than a custom function for that datatype. The point is that a monomorphized generic function should not be slower than the custom-function-per-datatype, but because Go's generics are not fully monomorphized they can be, and in fact can be slower than the a function-for-interface.
- whimsicalism 5y ago
  > I might have worded it differently, but yeah, of cause generics can make your code slower, what did people expect. ? In most languages, it is compile-time overhead, not runtime.
  - masklinn 5y ago
    I wouldn't say "most", it's very variable. Also not unlike Go I think C# uses a hybrid model, where all reference types get the same instances of the generic function.
- marssaxman 5y ago
  I would have expected generics to make the compiler take longer, not the compiled program.
- wtetzner 5y ago
  From the article: > Monomorphization is a total win for systems programming languages: it is, essentially, the only form of polymorphism that has zero runtime overhead, and often it has negative performance overhead. It makes generic code faster. The point is that the way Go implements generics is in such a way that it can make your code slower, even though there is a well-known way that will not make your code slower (at the cost of compile times).
  - ramesh31 5y ago
    >even though there is a well-known way that will not make your code slower (at the cost of compile times). That's the point though. The Golang team was surely aware of both approaches, and chose what they did as a conscious design decision to prefer faster compile times. People love Go because of the iteration speed compared to C++. And these little things start to add up if you don't have a clear product vision about what your language is meant for.
    - wtetzner 5y ago
      Of course, I understand that they made that decision. I was just replying to this: > of cause generics can make your code slower, what did people expect. It's not unreasonable that some people might have expected monomorphization.
      - erik_seaberg 5y ago
        In fact I sort of thought they had announced monomorphization, though I wasn’t following really carefully.

mrweasel 5y ago

I might have worded it differently, but yeah, of cause generics can make your code slower, what did people expect.

tsimionescu 5y ago
It depends what they are replacing. Typically, generics used to replace runtime polymorphism (using [T any] []T instead of []any) would be a speed boost in C#, C++, or Rust; and would have no impact on speed in Java.
- morelisp 5y ago
  And it is also a speed boost in Go, assuming you don't call any methods. (Which, if you were really using [T any], you either weren't or you were dissembling about your acceptable types.)
zellyn 5y ago
I don't know about you, but when I imagine what compilers do with generic code, I typically imagine monomorphization, which (aside from increasing cache pressure a little), should generally not make things slower, but rather introduce possibilities for inlining that could make it faster.
- mrweasel 5y ago
  Apparently I scrolled right past that bit of the article. I’m a little unsure how it’s suppose to make the code faster, but maybe because I compare it wrong. The alternative to generics is writing all the different function by hand, in my mind at least. I don’t fully understand how generics are suppose to be made faster than a custom function for that datatype.
  - wtetzner 5y ago
    I think the reasoning is that for something that's commonly used for many different types, you won't go through the effort of re-implementing that function for each type (it may not even be feasible to do so). Which means you'll end up with some sort of indirection to make it generic.
  - mcronce 5y ago
    The point is they shouldn't be slower than a manually-copied implementation for that concrete type. They also should be faster than vtable dynamic dispatch in the vast majority of cases. (I also fail to see a compelling reason that they couldn't have been implemented by passing the fat pointer directly, making the codegen the same as passing an interface, instead of having that business with the extra layer of indirection.) If there are specialization opportunities when hand-implementing the function for a given concrete type, I would indeed expect that to be faster than a monomorphized generic function.
  - masklinn 5y ago
    > I don’t fully understand how generics are suppose to be made faster than a custom function for that datatype. The point is that a monomorphized generic function should not be slower than the custom-function-per-datatype, but because Go's generics are not fully monomorphized they can be, and in fact can be slower than the a function-for-interface.
whimsicalism 5y ago
> I might have worded it differently, but yeah, of cause generics can make your code slower, what did people expect. ? In most languages, it is compile-time overhead, not runtime.
- masklinn 5y ago
  I wouldn't say "most", it's very variable. Also not unlike Go I think C# uses a hybrid model, where all reference types get the same instances of the generic function.
marssaxman 5y ago
I would have expected generics to make the compiler take longer, not the compiled program.
wtetzner 5y ago
From the article: > Monomorphization is a total win for systems programming languages: it is, essentially, the only form of polymorphism that has zero runtime overhead, and often it has negative performance overhead. It makes generic code faster. The point is that the way Go implements generics is in such a way that it can make your code slower, even though there is a well-known way that will not make your code slower (at the cost of compile times).
- ramesh31 5y ago
  >even though there is a well-known way that will not make your code slower (at the cost of compile times). That's the point though. The Golang team was surely aware of both approaches, and chose what they did as a conscious design decision to prefer faster compile times. People love Go because of the iteration speed compared to C++. And these little things start to add up if you don't have a clear product vision about what your language is meant for.
  - wtetzner 5y ago
    Of course, I understand that they made that decision. I was just replying to this: > of cause generics can make your code slower, what did people expect. It's not unreasonable that some people might have expected monomorphization.
    - erik_seaberg 5y ago
      In fact I sort of thought they had announced monomorphization, though I wasn’t following really carefully.