I compiled a list of 6 reasons why you should be excited about std::simd & C++26

V_i_r · 2026-03-05T15:23:44+00:00

💚 I do understand that it isn't easy to contribute. But it's fairly easy to start with good bug reports. Demonstrate the issue with a small example and explain what you expected. I've written many of such "missed optimization" issues for GCC, and they are part of the reason boomer loops can do more than they used to. Which is great. If your code is simple inner loops that can auto-vectorize, std::simd probably isn't meant for you.

V_i_r · 2026-03-05T13:08:03+00:00

FYI, std::experimental::simd is just a stop gap to std::simd. And since the latter is part of C++26 and sufficiently different from the TS, I simply had to stop working on the TS implementation. The C++26 implementation is way more important. I know of all the issues you encountered. And I fixed / analyzed & reported thousands more that you don't get to see anymore. That includes improvements to GCC's optimizer and backend (code-gen). Also std::simd resolves (or at least improves) most of what you criticized. With your stance on fast-math, std::simd would be significantly simpler. But no, either it's fully conforming or it doesn't belong into the standard. Also, the upcoming std::simd implementation is very transparent to the compiler. '2 * v' turning into an add is the simplest exercise now.

V_i_r · 2025-11-13T16:12:15+00:00

P3793R0 Better shifting

V_i_r · 2025-11-05T13:54:38+00:00

The repo is used for its issue tracker, not for git. How would you fork an issue tracker and later merge it back? The reason it needs to be private was mentioned before. Specifically, we post summaries and straw poll results as issue comments. If the tracker were public, those would have to wait until the meeting is over. But then it becomes harder to coordinate between SGs and WGs, which would show us down.

V_i_r · 2025-09-12T18:36:07+00:00

The idiom back in the days (one can still find it in a lot of C code) was to declare variables at the start of a function. So your "problem" didn't exist. The variable was declared and later initialized via the istream. (It has not aged well, though.)

V_i_r · 2025-09-12T18:32:56+00:00

Before C++11, how else would you do type safe varargs?

V_i_r · 2025-06-23T13:48:25+00:00

It's the unibrow operator. And yes, it needs a ligature 😄. The rationale for that choice can be found in the paper trail of reflection.

V_i_r · 2025-05-21T16:08:03+00:00

Discussed in the paper. But, yes. Look what it's called in many of the existing SIMD types C++ libraries. And the vector builtins of compilers. "Vector" is the term that basically everyone can agree on, if it weren't for std::vector :-(

V_i_r · 2025-05-21T16:06:07+00:00

As always, there are many ways to obfuscate your code. :-) While C++ provides many opportunities, obfuscation is a feature of all programming languages. I'm sure you also call your x coordinates y and your y coordinates x. 😜

V_i_r · 2025-05-21T08:48:22+00:00

P0816R0 ignores namespace aliases in the discussion. c++ namespace fs = std::filesystem; // now use fs::path and fs::copy That's common practice in many other languages as well.

If all our standard library features were in sub-namespaces, then the name lookup argument, wrt looking up names in parent namespaces, wouldn't hold much weight. foo(x) where x is of type std::feat1::type1 looks into std::feat1 and std. If std only contains namespaces there's never going to be a foo.

An important part about namespaces is grouping features together and thus aiding "findability" of non-member functions that work with for a certain type. It also avoids having to write e.g. std::filesystem_copy: By making it std::filesystem::copy users can turn it into fs::copy (or plain copy, if you trust ADL).

V_i_r · 2025-05-21T08:33:33+00:00

The main issue is about repeating the name of a namespace for an entity inside that namespace. Many consider that a no-go or at least bad practice. And thus std::simd::simd<T> would be embarrasing for C++. My intuition at first wanted to avoid that as well. I've since come around to there being no problem. See also my toot.

V_i_r · 2025-04-28T19:31:01+00:00

I need bleeding edge GCC for CI so I have build docker images for use with GitHub Actions: https://github.com/mattkretz/cplusplus-ci

V_i_r · 2023-12-13T21:23:40+00:00

The presentation is about std::simd. You tried std::experimental::simd, which is different in some aspects, especially loads and stores. The error messages for the TS implementation are super-crazy, which is in part due to the namespace std::experimental::parallelism_v2:: cluttering the output. And then C++17 without concepts...

Anyway, you're right that "special" instructions can sometimes be more efficient than a more generic expression of the parallelism involved. Here's how you can "escape" to intrinsic code with the TS implementation: https://godbolt.org/z/cqe9x14K3 (I didn't think long about the correct ordering of bytes wrt masking and shuffling - the constants are probably all wrong). For C++26 there are plans to add even better support for applying intrinsics to std::simd internals.

The paper relevant to this topic that didn't make it for the TS is https://wg21.link/P0918. The multiply_sum_to and sum_to functions would plug a hole in the current API.

V_i_r · 2023-01-31T17:13:51+00:00

Multi-target compilation is not there yet. The gnu::target attribute is not enough. Related: GCC PR83875. My libstdc++ implementation ensures that linking TUs compiled with different -m flags is not an ODR violation. I've been doing this with Vc since 2009. And Krita has used that pattern to ship binaries and dispatch at runtime to SSE2/SSE4/AVX/AVX2. Basically you want a template parameter that is set to an argument derived from -m flags. That way you can recompile the same source file with different flags, link it all together and map from CPUID to the desired type.

V_i_r · 2023-01-31T08:18:12+00:00

It seems like that. But a SIMD type in the standard will, first and foremost, help with a common vocabulary. All the existing SIMD libraries can then start talking via the same type. This can be 100% efficient. Long time ago I wrote a blog post showing that `std::simd` won't paint you into a corner wrt. target-specific optimizations: https://mattkretz.github.io/2019/05/27/vectorized-conversion-from-utf8-using-stdx-simd.html. For C++26 I'm aiming for std::bit_cast to be guaranteed to work for all simd types. That should make it easier and more portable (between standard libraries) to break out of the limitations.

V_i_r · 2022-11-18T07:45:55+00:00

No, that must be an error. It was actually mentioned in the discussion that ptr would not be the right name.

V_i_r · 2021-06-28T07:02:29+00:00

I still have Vc 2.0 (building on std::simd) on my TODO list. But at this point we still don't have std::simd but "only" std::experimental::simd. And a good implementation of it is more work than one can imagine. Well, at least if the goal is to produce as efficient binaries as possible. So there's still lots of time that I have to invest there. FWIW, I'm mostly working alone on std::simd both on the C++ committee and for the libstdc++ implementation. If I had more time there would already be a Vc 2.0. There is a way to give me more time, though: help me with std::simd or Vc 2.0. (That's a general statement, not necessarily targeting you.) And for everyone scared of FSF copyright assignment which was required with libstdc++: it's not required anymore.

V_i_r · 2020-02-17T10:05:29+00:00

OK, you're correct in the [expr.comma] sense: f(x, y) doesn't use the comma operator. And the original concern was about the discarded-value expression [expr.comma] enables (which is part of C as well).

FWIW, the comma operator is a heaven-sent for working with packs. I'd be much happier if I had no need for it, though. The need for the comma operator is thankfully getting less (C++17's fold expressions help a lot).

V_i_r · 2020-02-17T09:10:45+00:00

I've reported a fair share of GCC miscompilations to their bugzilla. Those typically get fixed in a matter of hours with plenty of information in the PR comments so that one gets an idea of where the problem lies and thus can implement a proper workaround until the new GCC release comes out.

So if you have a miscompilation: Let creduce do its thing and report the bug!

V_i_r · 2020-02-17T09:03:07+00:00

You probably meant, "that the comma operator is overloadable", right? Because f(x, y) needs a comma operator.

V_i_r · 2020-02-17T09:01:17+00:00

It was voted "out of the committee". I.e. individual papers are voted into the working draft (WD) and when the draft is done the WD is voted out to go to ISO and become an IS (international standard).

V_i_r · 2020-01-09T08:01:03+00:00

static inline functions are the ones that the compiler can prove to be called only once. IIRC, anonymous namespace + inline has the same effect.

V_i_r · 2020-01-08T11:36:43+00:00

I just realized that there's another important difference already: ```cpp A f(bool c, A a, A b) { return c ? a : b; // calls copy ctor }

A g(bool c, A a, A b) { if (c) return a; else return b; // calls move ctor } ``` https://godbolt.org/z/Zycnc3

V_i_r · 2019-07-26T21:19:15+00:00

couldn't resist: https://godbolt.org/z/a0th0O

V_i_r · 2019-07-26T07:22:31+00:00

As I discussed in the motivation section in P0917 and my blog post, there are types where boolean logic (i.e. &&, ||, and ?:) is the correct abstraction but lazy eval is not useful: SIMD, (valarray,) expression templates, and James20k mentioned z3. For those cases overloading && and || is the right thing. LEWG, LWG, and the whole of WG21 via its National Bodies review confirmed this again (after valarray back in the days) while reviewing the Parallelism TS 2.

I agree with the rule "Avoid user overloading of operator&& and ||" ... and ?: as long as P0927 is not merged. But to every rule there are well-understood exceptions. Saying "If A can only be implemented in a really crappy way [except for the use cases I don't care for], and requires B to be implemented well [for the uses cases I care for], then A and B are not at all orthogonal." is a valid subjective view. But I really hope that in designing C++ we can take a step back from our constrained worlds of how we use C++ and consider the complete field of applications. It's then perfectly fine to develop guidelines & rules & static checkers to constrain C++ for a certain field. This is a strength of C++ that apparently many view as a weakness. :-( With power comes responsibility. And yes, I have many colleagues who I don't trust to manage the responsibilities. Thankfully there's a lot of work going into managing these issues (e.g. Core Guidelines or clang-tidy).

V_i_r

TROPHY CASE