3 ms·

By that metric you're almost always better off writing specialized code all the time and duplicating stuff around a lot. (In all languages, not just go)

mcronce 5y ago
This is only the case* when there is actually something to be gained by specializing the implementation of a data type or function for a given type. In my experience that isn't particularly common. * Excluding Go's implementation of generics, which are frequently less performant than even vtable dispatch, let alone manually copied implementations.
jamal-kumar 5y ago
Is that so? It kind of sounds like there's cases to consider where there's actually a performance gain, but in certain use cases in languages with implementations of this feature in a different way... From the article I linked: "Historically, monomorphization has been the design of choice for implementing Generics in systems languages such as C++, D, or Rust. There are many reasons for this, but it all boils down to trading longer compile times for significant performance gains in the resulting code. When you replace the type placeholders in generic code with their final types before the compiler has performed any optimization passes, you create an exciting universe of optimizations that are essentially impossible when using boxed types. At the very least, you get to de-virtualize function calls and get rid of virtual tables; in the best case scenario, you get to inline code, which in turn enables further optimizations. Inlining code is great. 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. So, as somebody who works on performance for large Go applications, I admit I was not particularly excited about Generics in Go, really. I was excited about monomorphization, and about the potential for the Go compiler to perform optimizations that it simply can’t do when it’s dealing with interfaces. Cue my disappointment: The Generics implementation in Go 1.18 does not use monomorphization… at least, not quite."
ByteJockey 5y ago
Almost certainly. It's really only C++ and Rust that monomorphize everything (this is one of the reasons their builds take so long).

mcronce 5y ago

This is only the case* when there is actually something to be gained by specializing the implementation of a data type or function for a given type. In my experience that isn't particularly common. * Excluding Go's implementation of generics, which are frequently less performant than even vtable dispatch, let alone manually copied implementations.

jamal-kumar 5y ago

Is that so? It kind of sounds like there's cases to consider where there's actually a performance gain, but in certain use cases in languages with implementations of this feature in a different way... From the article I linked: "Historically, monomorphization has been the design of choice for implementing Generics in systems languages such as C++, D, or Rust. There are many reasons for this, but it all boils down to trading longer compile times for significant performance gains in the resulting code. When you replace the type placeholders in generic code with their final types before the compiler has performed any optimization passes, you create an exciting universe of optimizations that are essentially impossible when using boxed types. At the very least, you get to de-virtualize function calls and get rid of virtual tables; in the best case scenario, you get to inline code, which in turn enables further optimizations. Inlining code is great. 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. So, as somebody who works on performance for large Go applications, I admit I was not particularly excited about Generics in Go, really. I was excited about monomorphization, and about the potential for the Go compiler to perform optimizations that it simply can’t do when it’s dealing with interfaces. Cue my disappointment: The Generics implementation in Go 1.18 does not use monomorphization… at least, not quite."

ByteJockey 5y ago

Almost certainly. It's really only C++ and Rust that monomorphize everything (this is one of the reasons their builds take so long).