On Sun, 21 Oct 2018 at 13:53, Axel Wagner <axel.wagner...@googlemail.com>
wrote:
> Last addition:
>
> On Sun, Oct 21, 2018 at 2:03 PM roger peppe <rogpe...@gmail.com> wrote:
>
>> Ah, I *think* I see where you might be coming from now. You're thinking
>> that the compiler could do some kind of Go-to-Go transformation for generic
>> functions so that they looked exactly as if they'd been written using
>> interfaces, and then later transform that back into devirtualized calls.
>> Even if it were possible in general (I'm fairly sure it's not), I don't see
>> why anyone would want to take such an indirect approach when it's quite
>> possible for the compiler to compile to an intermediate format that
>> preserves all the information needed and decide how to generate the code
>> based on that.
>>
>
> The claim you made was, that generics improve performance (due to static
> dispatch and inlining etc). I contradict that claim. I believe static
> dispatch and inlining can be achieved without talking about type-parameters
> or generics at all.
>
> And to answer the question of "why would you do that" - because if you
> treat it as a generic (lol) devirtualization pass, code that *doesn't* use
> generics (but does use interfaces) also benefits from that automatically.
> For example we could actually get a powerful and properly performing
> version of image/draw without having to re-write it into a parametric API -
> the performance of existing interface-based APIs would be equivalent to
> parametric ones.
>
> It's also easier to reason about, because you are separating the
> type-checking phase from the optimization phase. Your heuristics doesn't
> need to know about the generic type info at all and you can tweak both
> individually.
>
> Essentially, the advantages of splitting it into modular pieces is the
> same reason, why functional languages desugar all language constructs into
> pure functions - if `->` is the only type constructor you need to worry
> about, it becomes much easier to talk about how different features
> interact, optimizations and whether a change to the type-system is sound.
> Also, optimizations for that basic type-constructor compound to all
> constructs.
>
> In essence, a lot of the problems discovered in the alias-discussion and
> also in the generics discussion now come down to a question of how these
> things interact with all the existing features and whether we fully
> understood the whole space of programs the language allows. Treating
> generics as essentially syntactic sugar for interfaces/reflect/… creates
> orthogonality - at least in every compilation stage *after* type-checking.
>
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. 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
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.
