Sorry, should've added what I consider the source: https://play.golang.org/p/3_um7p3IxwK
On Thu, Oct 25, 2018 at 10:09 AM Axel Wagner <axel.wagner...@googlemail.com> wrote: > 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.
