Hacker News new | ask | show | jobs
by dsymonds 4590 days ago
That sounds like a variation on rsc's 3rd approach (but with runtime code generation instead of boxing) with the same drawback: slower execution. It also makes certain kinds of debugging harder (how do you map a PC that's pointing to generated code? what if the code generation is the thing going wrong?).

C# on CLR is a VM approach, whereas Go compiles to native code. Concepts that are easy in the first (e.g. runtime code generation) often don't map particularly nicely to the second.
1 comments
kmontrose 4589 days ago
Why would you expect execution to be slower? If you invoke List<T>.Add(T) where T = int you end up running the same machine code that would have been generated if instead you had a method List.Add(int). There is a cost paid to generated that specific method, but it's on the first invocation. I'd expect it to be much faster than boxing, because you can elide a bunch of a allocations and generate tighter code since you have additional typing information at code gen time.

I suppose debugging could go sideways in theory, but it doesn't happen in practice on .NET and I doubt the go team couldn't figure out how to make it work.

It's worth noting that .NET never interprets bytecode, it always converts a method into machine code before execution. Go has already had dynamic code generation as part of it's implementation (I don't know if it's still around in 1.2), so it's hardly like it can't do the same thing .NET is.

link
malkia 4588 days ago
Okay, then how does AOT works with C# templates? Really how? Do you have to pre-declare some known types ahead? (Or could it be that the AOT compiler scans all possible variants (doable since it's static language))?
link
kmontrose 4588 days ago
AOT is a Mono extension to .NET, there are some cases it doesn't work and generics can cause some of them. See: http://www.mono-project.com/AOT for more details

For .NET proper, new machine code is generated at runtime. I believe (but do not know for sure, offhand) that it basically takes the IL definition of the generic method, slots the now known type into it, and JITs it to get the machine code it needs. I do know that there are couple bits of IL that are meant to make it possible to write the same code to deal with both reference and value types, which is probably related.

Ngen (http://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.110).a...) let's you transforms assemblies into machine code up front, while still being .NET proper. However, if it can't find a use of generics with concrete types found at runtime (ie. you generate a List<int> via reflection) you'll still load up and use the JIT (see some discussion here: http://stackoverflow.com/q/16647568/80572).

I don't use AOT or Ngen regularly, so the particulars may be a little off in my explanations. But that's the gist of it.

link