Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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?


AFAIU, 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.


I’m also hoping that the more monomorphization will take place over time.


Go's issues are mostly not performance related, so more monomorphization will really not solve a significant portion of them.


They 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.


I 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: