[drivebyhooting]

The biggest issue with stenciling is lack of inlining. So for example if the argument to a generic function is an array backed container, then element access will have to go through a method call that cannot be inlined.

Besides the call indirection, the compiler also loses optimization opportunities.

With the stenciling design many generic functions found in the C++ stl have to pay significant abstraction costs.

Anyway, I like the go design.

[nasretdinov]

That is true. Moreover, in general the performance of generic code in Go isn't any better than interface-driven one. Generics are there in Go just for better type safety, and IMO that's sufficient already :)

[rednafi]

It's all tradeoffs. Fully monomorphized generics tend to blow up compile time.

[drivebyhooting]

Full monomorphization can also greatly increase code size and icache pressure. Especially if LTO was not possible.

I haven’t seen icache pressure causing performance degradation in the wild but it is in theory possible.

[yencabulator]

icache pressure was the bane of my optimization work around 2002. Mostly because it fluctuated unpredictably even from fairly small fairly faraway changes. The system got large enough, with a long enough hot code path that was very hot, that it was almost pointless to benchmark a subsystem in isolation. Simplistic attempts to make any subsystem faster typically made the whole system slower.

In general, whatever subsystem took the cache misses showed up as the slow part, and I owned the very first component in the pipeline... It was fun to compile time disable my component to demonstrate that nothing got faster, though.