3 ms·

I hope people aren't writing directly to AVX2. When using a wrapper such as Highway, you get exactly this kind of update after a recompile, or even just running

• imtringued 2y ago
  Most video encoders and decoders consist of kernels with hand written SIMD instructions/intrinsics.
  • janwas 2y ago
    Agreed. FWIW we demonstrated with JPEG XL (image codec, though also with animation 'video' support) that it is possible to write such kernels using the portable Highway intrinsics.
• dragontamer 2y ago
  > I hope people aren't writing directly to AVX2. Did you not read the article? It's using AVX intrinsics and NEON intrinsics.
  • janwas 2y ago
    I did, and I truly do not understand why some people do this. As shown in the reddit comments on this article [1], the initial intrinsics version was quite suboptimal and clearly worse than portable code [2]. When not busy unnecessarily rewriting everything for each ISA, it is easier to see and have time for vital optimizations such as unrolling :) [1]: https://www.reddit.com/r/cpp/comments/1gzob1g/understanding_simd_infinite_complexity_of_trivial/ https://www.reddit.com/r/cpp/comments/1gzob1g/understanding_... [2]: https://github.com/google/highway/blob/master/hwy/contrib/dot/dot-inl.h#L95 https://github.com/google/highway/blob/master/hwy/contrib/do...
• jandrewrogers 2y ago
  Many use cases for SIMD aren't trivially expressible through wrappers and abstractions. It is sometimes cleaner, easier, and produces more optimized codegen to write the intrinsics directly. It isn't ideal but it often produces the best result for the effort involved. An issue with the abstractions that does not go away is that the optimal code architecture -- well above the level of the SIMD wrappers -- is dependent on the capabilities of the silicon. The wrappers can't solve for that. And if you optimize the code architecture for the silicon architecture, it quickly approximates writing architecture-specific intrinsics with an additional layer of indirection, which significantly reduces any notional benefit from the abstractions. The wrappers can't abstract enough, and higher level abstractions (written with architecture aware intrinsics) are often too use case specific to reuse widely.
  • janwas 2y ago
    Wrappers can be zero-overhead, so any claim of better codegen vs the underlying intrinsics sounds dubious. "best result for the [higher] effort involved" also contradicts my experience, so I ask for evidence. One counterexample: our portable vqsort [1] outperforms AVX-512-specific intrinsics [2]. I agree that high-level design may differ. You seem aware that Highway, and probably also other wrappers, supports specializing code for some target(s), but possibly misunderstand how, given the "additional layer of indirection" claim. Wrappers give you a portable baseline, and remove some of the potholes and ugly syntax, but boil down to inlined wrapper functions. If you want to specialize, that is supported. And what is the downside? Even if you say the benefit of a wrapper is reduced vs manually written intrinsics (and reinventing all the workarounds for their missing instructions), do you not agree that the benefit is still nonzero? [1]: https://github.com/google/highway/tree/master/hwy/contrib/sort https://github.com/google/highway/tree/master/hwy/contrib/so... [2]: https://github.com/Voultapher/sort-research-rs/blob/38f37eefbbc7d7f5f3f80f778a7fa0f27eaebe8c/writeup/intel_avx512/text.md#updated-vqsort-results https://github.com/Voultapher/sort-research-rs/blob/38f37eef...
    • saagarjha 2y ago
      The downside is that you write an implementation in Highway, find that it doesn't perform how you want, and then you have to rewrite it.
• Remnant44 2y ago
  I would wager that most real world SIMD use is with direct intrinsics.