3 ms·

Indeed a nice speedup! As to libraries: I'm the main author of github.com/google/highway which provides 'portable intrinsics' so you only have to write your co

by janwas 4y ago

Indeed a nice speedup! As to libraries: I'm the main author of github.com/google/highway which provides 'portable intrinsics' so you only have to write your code once for all platforms. It includes ready to use sorting and searching algorithms in hwy/contrib.

synergy20 4y ago
"Supported targets: scalar, S-SSE3, SSE4, AVX2, AVX-512, AVX3_DL (~Icelake, requires opt-in by defining HWY_WANT_AVX3_DL), NEON (ARMv7 and v8), SVE, SVE2, WASM SIMD, RISC-V V." wow this looks very interesting, I noticed the release passed 1.0 milestone, how did you unify all those intrinsics? I'm particularly interested in RVV1.0.
- janwas 4y ago
  :) We (several engineers) put together a table [1] of instructions that several architectures natively support. There was enough overlap that I thought a wrapper would make sense. With a lot of the JPEG XL code written, when SVE and RVV were being introduced/discussed, I realized that pretty much the same code would work there, too: we just needed to replace a constexpr VecClass::kLanes with Lanes(), which is what Highway now does. Beyond the initial set of efficient-everywhere ops, we've added some (such as AbsDiff) that help on say Arm without hurting other platforms, nor can user code do better itself. There are also a few (ReorderWidenMulAccumulate) that define a non-obvious relaxation of the interface which is more efficient for all platforms than holding to any one platform's interface. For RVV, one remaining concern is the VSETVLI - the revised intrinsics now require an avl argument, which Highway creates in each function. It's not yet clear whether the compiler will be smart enough to (peephole-?)optimize away the duplicates. 1: https://github.com/google/highway/blob/master/g3doc/instruction_matrix.pdf https://github.com/google/highway/blob/master/g3doc/instruct...

by janwas 4y ago

synergy20 4y ago

"Supported targets: scalar, S-SSE3, SSE4, AVX2, AVX-512, AVX3_DL (~Icelake, requires opt-in by defining HWY_WANT_AVX3_DL), NEON (ARMv7 and v8), SVE, SVE2, WASM SIMD, RISC-V V." wow this looks very interesting, I noticed the release passed 1.0 milestone, how did you unify all those intrinsics? I'm particularly interested in RVV1.0.

janwas 4y ago
:) We (several engineers) put together a table [1] of instructions that several architectures natively support. There was enough overlap that I thought a wrapper would make sense. With a lot of the JPEG XL code written, when SVE and RVV were being introduced/discussed, I realized that pretty much the same code would work there, too: we just needed to replace a constexpr VecClass::kLanes with Lanes(), which is what Highway now does. Beyond the initial set of efficient-everywhere ops, we've added some (such as AbsDiff) that help on say Arm without hurting other platforms, nor can user code do better itself. There are also a few (ReorderWidenMulAccumulate) that define a non-obvious relaxation of the interface which is more efficient for all platforms than holding to any one platform's interface. For RVV, one remaining concern is the VSETVLI - the revised intrinsics now require an avl argument, which Highway creates in each function. It's not yet clear whether the compiler will be smart enough to (peephole-?)optimize away the duplicates. 1: https://github.com/google/highway/blob/master/g3doc/instruction_matrix.pdf https://github.com/google/highway/blob/master/g3doc/instruct...