C++26 Shipped a SIMD Library Nobody Asked For(lucisqr.substack.com)

6 pointsby ibobevvor 4 Monaten2 comments

lucisqr.substack.com

C++26 Shipped a SIMD Library Nobody Asked For

https://lucisqr.substack.com/p/c26-shipped-a-simd-library-nobody

2 comments

janwasvor 4 Monaten

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.

mwkaufmavor 4 Monaten

Jumped out at me, after reading similar int32 promotion woes in bitfields yesterday (https://news.ycombinator.com/item?id=47469945):

   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.