Sure: https://play.golang.org/p/W_ruqI22Vhv Seems a fairly straight-forward transformation to me - and again easy to devirtualize.
On Thu, Oct 25, 2018 at 8:56 AM roger peppe <rogpe...@gmail.com> wrote: > > On Thu, 25 Oct 2018, 12:52 am Axel Wagner, <axel.wagner...@googlemail.com> > wrote: > >> 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 >> > > Try that again with the generic sum function instead of addPair, which I > only included so I could explore what it looked like when one generic > function calls another. > > 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.
