Jörn Engel (joern.delete@this.purestorage.com) on May 21, 2022 1:23 pm wrote:
> From a quick glance, Jan's abstraction isn't horrible. It has compress, but appears to be missing
> expand. Shouldn't be too hard to add later.
Right, expand is on the wishlist. We add ops whenever there is a use case and that one hasn't come up yet but likely will soon.

> That may be necessary for SVE support. It breaks my mental model a bit, I currently assume that
> vectors are one of 16, 32 or 64 bytes. Jan's approach is probably better.
:) Some implementations of RISC-V V indeed have greater than 64 byte vectors.

> I dislike the idea of classes. Nothing about vector instructions implies an object-oriented
> approach. It doesn't prevent an object-oriented approach either, so classes clearly work.
> But for an abstraction it is an artificial limitation that is entirely unnecessary.
I actually agree, and Highway is designed to not require classes for vectors. This is necessary because SVE and RISC-V vectors cannot (with current compilers) be wrapped in a class.
Only the fixed-size vectors (WASM, x86, NEON) are implemented using classes - this allows us to avoid long type suffixes in the op names, as seen in SLEEF.

> it also indicates a cultural divide, you either prefer C or C++ and I happen to fall on the
> C side of that divide. Guess I will continue to use my way instead of the highway. ;)
Fair enough :) Some colleagues did ask for a C version of Highway, but that would have required a completely different approach. Perhaps it's an option to compile only the vector code using C++.