3 ms·

That's wishful thinking. GCC isn't able to do that with C language, a 20 years old compiler with a 40 years language. How would a compiler know that you can use

That's wishful thinking. GCC isn't able to do that with C language, a 20 years old compiler with a 40 years language. How would a compiler know that you can use a SHA2 instruction? Yes, there are intrinsics but then what about specialized vectorized instructions which don't match any primitive types or operations in the language (like, you can't express "add with carry" in C or Go)? And how can you explain a compiler that there is no data dependency in memory access between different buffers? Yes it might be able to prove it by itself in some cases, but history has shown that things like autovectorization are too fragile and can't be relied upon. Optimized C libraries like compressors or security have assembly implementations as well. I'm not sure why using assembler should be considered a signal of a defect rather than a proof of optimization. There's really nothing wrong in using assembly to write a bytes.Index version optimized for AVX2.

DannyBee 10y ago
"That's wishful thinking. GCC isn't able to do that with C language, a 20 years old compiler with a 40 years language. How would a compiler know that you can use a SHA2 instruction?" Well, actually, they could, it's just not worth pattern matching because it occurs so infrequently. "but history has shown that things like autovectorization are too fragile and can't be relied upon." Errr, i'd say the opposite. History has shown that good autovectorizing compilers can come pretty damn close to whatever you want. Usually the only issue is that they may insert too many runtime checks, and that's easily solvable.
- giovannibajo1 10y ago
  Can you show me an opensource library implementing performance-sensitive computations in any field (graphics, numerics, crypto, etc.) which relies on autovectorization to obtain the performance characteristics that clients rely upon? The large majority of performance-sensitive libraries I know of rely on carefully written native code (C, C++), with a mixture of assembly and/or intrinsics. This, to me, is a failure to concretize autovectorization from textbooks into an industry-accepted solution.
pcwalton 10y ago
> How would a compiler know that you can use a SHA2 instruction? Intrinsics. There's basically zero benefit to coding this stuff in assembly. Many standard libraries prefer intrinsics, because there's basically zero benefit to writing this stuff in assembly and many drawbacks from an optimization perspective.

DannyBee 10y ago

"That's wishful thinking. GCC isn't able to do that with C language, a 20 years old compiler with a 40 years language. How would a compiler know that you can use a SHA2 instruction?" Well, actually, they could, it's just not worth pattern matching because it occurs so infrequently. "but history has shown that things like autovectorization are too fragile and can't be relied upon." Errr, i'd say the opposite. History has shown that good autovectorizing compilers can come pretty damn close to whatever you want. Usually the only issue is that they may insert too many runtime checks, and that's easily solvable.

giovannibajo1 10y ago
Can you show me an opensource library implementing performance-sensitive computations in any field (graphics, numerics, crypto, etc.) which relies on autovectorization to obtain the performance characteristics that clients rely upon? The large majority of performance-sensitive libraries I know of rely on carefully written native code (C, C++), with a mixture of assembly and/or intrinsics. This, to me, is a failure to concretize autovectorization from textbooks into an industry-accepted solution.

pcwalton 10y ago

> How would a compiler know that you can use a SHA2 instruction? Intrinsics. There's basically zero benefit to coding this stuff in assembly. Many standard libraries prefer intrinsics, because there's basically zero benefit to writing this stuff in assembly and many drawbacks from an optimization perspective.