4 ms·
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 ty
by nasretdinov 3mo ago
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 3mo agoIt's all tradeoffs. Fully monomorphized generics tend to blow up compile time.
- drivebyhooting 3mo agoFull 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 3mo agoicache 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.