4 ms·
The site gives assembly code of the inner loop, but isn't the problem that there is additional overhead on the calling of generic functions?
by bouncycastle 4y ago
The site gives assembly code of the inner loop, but isn't the problem that there is additional overhead on the calling of generic functions?
- wahern 4y agoAFAIU, as compared to pure monomorphization, yes, sometimes the model imposes runtime indirection. This is particularly the case for methods. However, for simple yet common cases, such as functions taking []T, the model permits inlining into the caller.
- throwaway894345 4y agoI’m also hoping that the more monomorphization will take place over time.
- mcronce 4y agoGo's issues are mostly not performance related, so more monomorphization will really not solve a significant portion of them.
- throwaway894345 4y agoThey aren’t performance related because idiomatic Go pushes people toward performance. Generics currently push people away from performance (of course there are exceptions). I don’t expect it will be a huge deal either way, but it would be nice not to have to choose between performance and expressiveness.
- chrchang523 4y agoI believe Lemire's point is that the compiler is still able to inline the function despite the generic definition, so at least in this somewhat narrow case generics are a zero-cost abstraction.