Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++26 Shipped a SIMD Library Nobody Asked For

lucisqr.substack.com

Post reply on HN
Print view View original

151–160 of 170 posts

Re: C++26 Shipped a SIMD Library Nobody Asked For

#151

Post by AlotOfReading »

camel-cdr wrote: post #52
AlotOfReading wrote: post #43

Earlier quoted context omitted.

Such as? I have a database that has big columns that get functions applied to them to compute the result set. This is a perfect case for length agnostic instructions, except out ends up horribly memory bound. A nice optimization is to only compute those lanes containing rows that might actually be in the result set by keeping track of a sparse record that depends on the lane size. But the cnt instructions are optiona…

CNT and CNTP don't seem to be optional for SVE, from what I found. (unless you mean HISTCNT) It seems to me like you want tp use CNTP on a bitset that tells you, which rows are relevant, skipping them if CNT is 0? Is that what you where describing?

I was confused and thinking that streaming mode and CNT were in separate extensions, but they're both in SME. My bad.

Anyway, essentially yes. My previous comment didn't mention all of the context. The join enforces that the result set is the intersection of the individual column sets, so it gets increasingly sparse as individual columns are computed. So I just maintain a bit tree that says which columns could populate the result set and skip computing the other lanes, which depends on the vector width and benefits from knowing it at compile time.

Re: C++26 Shipped a SIMD Library Nobody Asked For

#152

Post by jandrewrogers »

janwas wrote: post #80
jandrewrogers wrote: post #3

I have written a lot of SIMD for both x86 and ARM over many years and many microarchitectures. Every abstraction, including autovectorization, is universally pretty poor outside of narrow cases because they don’t (and mostly can’t) capture what is possible with intrinsics and their rather extreme variation across microarchitectures. If I want good results, I have to write intrinsics. No library can optimally generate…

In such discussions, whenever you mention abstractions are universally "pretty poor", to the extent anyone is listening, I think this hyperbole can do real damage. Maybe it prevents people from getting relevant performance gains, even if not 100% of the optimum, which is anyway unattainable. And what is the alternative? Not many projects can afford to hand write intrinsics for all platforms. And are you aware that Hi…

I am aware of Highway. It doesn’t add much value for the kind of SIMD code I write. I have better abstractions because I don’t have to consider portability nearly as much. Some useful constructions don’t have a good expression on weaker SIMD architectures.

Re: C++26 Shipped a SIMD Library Nobody Asked For

#153

Post by daemin »

One thing I will point out is that the code in the article is compiled with `-march=native` and `-ffast-math`, meaning that they're really only compiling for the exact same machine they are running on and no other. This seems like it is mainly applicable to places which can easily recompile code for the exact known hardware that they run on, such as HFT and some scientific computing.

Places which compile code to distribute for people to run on a variety of processors and platforms (or that require floating point code to be consistent between them), i.e. games and applications, will still be targetting a low end baseline architecture and therefore have a different outcome. I can say that in this space we are only now reaching the point where we can start compiling for AVX2, as we can expect the lowest end-user processor to support it.

Re: C++26 Shipped a SIMD Library Nobody Asked For

#154

Post by teo_zero »

jandrewrogers wrote: post #3

I have written a lot of SIMD for both x86 and ARM over many years and many microarchitectures. Every abstraction, including autovectorization, is universally pretty poor outside of narrow cases because they don’t (and mostly can’t) capture what is possible with intrinsics and their rather extreme variation across microarchitectures. If I want good results, I have to write intrinsics. No library can optimally generate…

> If I want good results, I have to write intrinsics.

Any good book / article / tutorial to begin learning it? Most docs I've tried assume you already know what you can do and focus on how to express it in assembly or with intrinsics. However, I'm not even aware of what operations are commonly implemented in hardware. For example, FMA is not normally tought, is not expressed in higher-level languages... how am I supposed to imagine such a thing exists, even before looking it up in a reference manual?

Re: C++26 Shipped a SIMD Library Nobody Asked For

#156

Post by janwas »

janwas wrote: post #137
fweimer wrote: post #122

Earlier quoted context omitted.

People reported challenges building V8 (whether upstream or the Node.js variant) on s390x with z13 support. I don't know if it was discussed on the porters mailing list because it's not public: https://groups.google.com/g/v8-s390-ports Elsewhere, some people interpreted https://github.com/google/highway/issues/1895 as meaning that Highway code does not work on z13 at all.

Thanks for sharing. The first link seems non public indeed. I can imagine there is some compile issue we could reasonably fix, with the help of someone who has Z13 access. Please encourage them to raise an issue. I will be back on May 26. After that, it should at least be able to use the scalar fallback. The issue with Z14 is that it lacks fp32 support. Would their usage be integer only?

Correction (typo): Z13 lacks fp32.

Re: C++26 Shipped a SIMD Library Nobody Asked For

#157

Post by janwas »

jandrewrogers wrote: post #152
janwas wrote: post #80

Earlier quoted context omitted.

In such discussions, whenever you mention abstractions are universally "pretty poor", to the extent anyone is listening, I think this hyperbole can do real damage. Maybe it prevents people from getting relevant performance gains, even if not 100% of the optimum, which is anyway unattainable. And what is the alternative? Not many projects can afford to hand write intrinsics for all platforms. And are you aware that Hi…

I am aware of Highway. It doesn’t add much value for the kind of SIMD code I write. I have better abstractions because I don’t have to consider portability nearly as much. Some useful constructions don’t have a good expression on weaker SIMD architectures.

To be clear, "better abstractions" here seems to mean macros for assembly language. To each their own.

What bothers me is advocating for this, or denigrating more generally useful alternatives, without mentioning the very narrow niche where this sits.

Video codecs only change every few years. This makes it more worthwhile/feasible to spend eng time on a few kernels.

Even then, not supporting SVE (you don't, right?) gives less incentive for the Arm CPU ecosystem to invest in it, helping keeping us stuck in the NEON local minimum. Not ideal :/

Re: C++26 Shipped a SIMD Library Nobody Asked For

#158

Post by whizzter »

camel-cdr wrote: post #95
whizzter wrote: post #93

Agreed, fixed with vectors needs to be a language feature, better compile times and would solve issues for most people. Personally, I think that like Clang way to adding GLSL like vectors and semantics would've gone a long way. SVE might be an elegant design, but in reality there are probably a multiple factor of game and other 3d code being written that needs vectors compared to other fields, and there limited vecto…

In GPUs GLSL like types compile down to what basically is variable length SIMD. A vec4 doesn't get compiled to a SIMD vector with four floats, but rather to four SIMD vectors, each containing N FP32 elements (usually 32 or 64). Look at what this simple shader compiles down to on RGA: https://godbolt.org/z/4GrfY61vf

Right, and AVX512 would thus be more relevant if ISPC-like features was mainstreamed in CPU bound C++ compilers.

Re: C++26 Shipped a SIMD Library Nobody Asked For

#159

Post by nnevatie »

janwas wrote: post #75
mpyne wrote: post #9

Earlier quoted context omitted.

> I think a legitimate criticism is that it is unclear who std::simd is for. I think it's for people like me, who recognize that depending on the dataset that a lot of performance is left on the table for some datasets when you don't take advantage of SIMD, but are not interested in becoming experts on intrinsics for a multitude of processor combinations. Having a way to be able to say "flag bytes in this buffer matc…

Have you considered our Highway library? Runtime dispatch need not be a PITA :) It's basically portable intrinsics, and a much more complete set (>300) than the ~50 in std.

Runtime dispatch is still a PITA in Highway, especially compared to ISPC. A simple algorithm or kernel becomes a multi-file macro-hell, basically.

Re: C++26 Shipped a SIMD Library Nobody Asked For

#160

Post by feelamee »

jcranmer wrote: post #146
feelamee wrote: post #140

Earlier quoted context omitted.

> Your BLAS library will provide you just the four basic element types, ..., and you still need fallback logic anyways to handle the other types. so, your problem with it is that it does all you want (e.g. LAPACK bindings) AND give extra features?? > so it takes a decent amount of dispatch logic to convert the template interface to the actual library calls I can't estimate how much this degrades performance. But, it…

> so, your problem with it is that it does all you want (e.g. LAPACK bindings) AND give extra features?? You've completely misunderstood the point: the point is that the "extra features" means you won't get the main feature (BLAS bindings).

I don't see any problems implementing those 4 types as bindings and others by manual implementation
Post reply on HN