On Thu, Oct 25, 2018 at 12:39 AM roger peppe <rogpe...@gmail.com> wrote:
> I understand this argument. By putting some smarts into the compiler, we > would hope that we can see benefits not just in our generated generic code, > but also in other code that we've already written that uses generics. This > would be great if it wasn't very hard to do. > We disagree here. I still maintain that it is not harder. My intention above was to illustrate that, by assuming we have the generics-problem (including a heuristic to decide what to specialize) solved and then solving the devirtualization-problem using that solution. Unfortunately, that still seems to be unconvincing to you, though. For example (I got a little carried away here), here's an idea of what some > generated code using a reflect-based approach might look like: > > https://github.com/rogpeppe/genericdemo/blob/master/naive/naive.go > I'm sorry, but this seems like a strawman. This is how a realistic dynamic approach would look like: https://play.golang.org/p/Fbs0cpAnE43 or, if you prefer, using methods: https://play.golang.org/p/6YsyJaVQ789 And yeah, I maintain that it's easy to devirtualize that. Especially if we can give the compiler hints, like for example, https://play.golang.org/p/TZNQRlvofw2 Anyway. I give up, I guess :) > > Imagine how smart the compiler would have to be in order to > reverse-engineer that back to the equivalent inline code! > You'd end up having to write patterns for the exact code that is produced > from the compiler, with the danger that you wouldn't hit any real code at > all (and also, coming up with sound optimisations for small variations in > reflect code is likely to be really hard). > I suspect you'd end up with a very slow and very fragile compiler. > > FWIW I went a bit further and experimented with some more potential > representations of generic Go code so I could get an idea of the likely > overheads. The approach of sharing implementations that use the same > size/pointer layout seems to work ok, with about a 3 or 4 ns overhead per > generic call on my machine (about half the speed of a direct function > call). My experimentation is here: > https://github.com/rogpeppe/genericdemo/blob/master/generated.go . It > actually shouldn't be that hard to write some code to produce that kind of > code automatically, "gofront" if you like, without updating the compiler > wholesale. I need to stop now :) > > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
