Highway TL here. I agree with the main points, with a few clarifications:
> tag-dispatched free functions like hn::Mul(d, a, b)
We only require tags for certain ops, mainly memory, casts and reduction; not arithmetic. Operator overloading is supported but until recently compilers didn't allow that for SVE vectors.
> It’s a Google project with Google-scale maintenance, but the bus factor is real — the core development is driven by a small team
We have 101 contributors, including 14 current or former Googlers in several teams.
> being length-agnostic means you can’t easily express fixed-width algorithms that depend on knowing the vector size at compile time, which is common in cryptography and codec work
We explicitly support fixed-length 128-bit vectors, acknowledging that these are common and important.
Integer promotion still breaks everything. int8_t + int8_t produces int32_t in C++. This is one of the oldest pain points for SIMD programmers working with image data, where 8-bit and 16-bit arithmetic dominates. std::simd inherits this problem because it’s a library on top of the language, not a fix to the language. Writing a pixel blending operation with std::simd<uint8_t> means fighting integer promotion at every step.
Highway TL here. I agree with the main points, with a few clarifications:
> tag-dispatched free functions like hn::Mul(d, a, b)
We only require tags for certain ops, mainly memory, casts and reduction; not arithmetic. Operator overloading is supported but until recently compilers didn't allow that for SVE vectors.
> It’s a Google project with Google-scale maintenance, but the bus factor is real — the core development is driven by a small team
We have 101 contributors, including 14 current or former Googlers in several teams.
> being length-agnostic means you can’t easily express fixed-width algorithms that depend on knowing the vector size at compile time, which is common in cryptography and codec work
We explicitly support fixed-length 128-bit vectors, acknowledging that these are common and important.
Jumped out at me, after reading similar int32 promotion woes in bitfields yesterday (https://news.ycombinator.com/item?id=47469945):