4 ms·

I guess it need not be the case that generics will slow down compilation that much. Problem with C++ template generics is that they are reinstantiated per type

I guess it need not be the case that generics will slow down compilation that much. Problem with C++ template generics is that they are reinstantiated per type __per compilation unit__. I think they can * Use dynamic dispatch liberally - such that one instantiation per object size in order to avoid boxing. That said, I don't know how the experimental generics work. And this will obviously prevent some optimizations, notably escape analysis. * defer compilation of generic code to the end i.e "just before linking" phase instead of eliminating duplicates at link time. * Some kind of caching mechanism for generic code such that you `sed` the machine code / plan9 intermediate to replace it with type specialization wherever required - should work if you are willing to sacrifice some optimizations, As majority of time is spent in code generation. On the flip side, Go team can come up with different optimization strategy for that part of code because Go doesn't do many optimizations in current form. I am no expert on compilers / optimization. But generics will obviously reduce the total code one needs to compile. And combined with some techniques I guess they can control compile times from regressing.

mshockwave 6y ago
Interesting ideas! some comments from a C++ compiler perspective: > Use dynamic dispatch liberally - such that one instantiation per object size in order to avoid boxing. That said, I don't know how the experimental generics work. And this will obviously prevent some optimizations, notably escape analysis. I think you're right about optimization: dynamic dispatch is what most of the template users want to avoid > defer compilation of generic code to the end i.e "just before linking" phase instead of eliminating duplicates at link time. Pretty cool. Never thought about that, though I believe LTO in gcc/clang might cover this part in some near future, or already had some partial supports. > Some kind of caching mechanism for generic code such that you `sed` the machine code / plan9 intermediate to replace it with type specialization wherever required Not sure about this though...not sure if the benefit outperforms the overhead cuz it sounds pretty expensive. But as a similar approach, JIT compilation might be a way.
htfy96 6y ago
For caching mechanism, there's zapcc (https://github.com/yrnkrn/zapcc https://github.com/yrnkrn/zapcc) which launches a background server at first compilation, and reuses instantiated template from the server in the following compilation. Sadly this project was discontinued.

mshockwave 6y ago

Interesting ideas! some comments from a C++ compiler perspective: > Use dynamic dispatch liberally - such that one instantiation per object size in order to avoid boxing. That said, I don't know how the experimental generics work. And this will obviously prevent some optimizations, notably escape analysis. I think you're right about optimization: dynamic dispatch is what most of the template users want to avoid > defer compilation of generic code to the end i.e "just before linking" phase instead of eliminating duplicates at link time. Pretty cool. Never thought about that, though I believe LTO in gcc/clang might cover this part in some near future, or already had some partial supports. > Some kind of caching mechanism for generic code such that you `sed` the machine code / plan9 intermediate to replace it with type specialization wherever required Not sure about this though...not sure if the benefit outperforms the overhead cuz it sounds pretty expensive. But as a similar approach, JIT compilation might be a way.

htfy96 6y ago

For caching mechanism, there's zapcc (https://github.com/yrnkrn/zapcc https://github.com/yrnkrn/zapcc) which launches a background server at first compilation, and reuses instantiated template from the server in the following compilation. Sadly this project was discontinued.