zlacker

[return to "From slow to SIMD: A Go optimization story"]
1. koala_+1o[view] [source] 2024-01-23 19:31:46
>>rbanff+(OP)
TIL that the Go compiler still does not have autovectorization.
◧◩
2. klabb3+Z61[view] [source] 2024-01-23 23:06:00
>>koala_+1o
I never do this kind of work so I can’t say. But if I did, I’d imagine I want more control. I mean, perf improvements are welcome to all code, but if I need a piece of code to have a specific optimization I’d rather opt-in through language constructs, so that the compiler (or other tooling) can tell me when it breaks. A well designed API with adapters from and to regular code would be better, no?

For instance, imagine I have auto-perf something and I check (manually mind you) the asm and all is good. Then someone changes the algorithm slightly, or another engineer adds a layer of indirection for some unrelated purpose, or maybe the compiler updates its code paths which misses some cases that were previously supported. And the optimization goes away silently.

[go to top]