Are C++17 Parallel Algorithms Implemented Already

Are C++17 Parallel Algorithms implemented already?

You can refer https://en.cppreference.com/w/cpp/compiler_support to check all C++ feature implementation status. For your case, just search "Standardization of Parallelism TS", and you will find only MSVC and Intel C++ compilers support this feature now.

C++ compiler support for std::execution (parallel STL algorithms)

C++17 execution policies are supported by GCC 10 and Clang 11.

Here is a demo example https://gcc.godbolt.org/z/xahs5x1Kx

#include <execution>

int main()
{
    int a[] = {2,1};
    std::sort(std::execution::par_unseq, std::begin(a), std::end(a) );
    return a[0];
}

c++ : no execution performance for stl parallel algorithm

Some standard libraries have not implemented the parallel versions yet. In the case of GCC (libstdc++), some algorithms were implemented a while ago but they depended on Intel's TBB library.

MSVC standard library is particularly ahead on this, and you will get an actual parallel version, so you can try that one if you are on Windows.

See Are C++17 Parallel Algorithms implemented already? for more information.

---

ps. your case can be vectorized, so you can use std::execution::par_unseq.

How is scheduling handled in C++17 STL parallel algorithms?

As far as I can tell from the wording, such details are completely within the domain of implementation specification, as one would expect. The standard generally makes no effort to guarantee absolute performance of any kind, only complexity requirements, as you're seeing in this case.

Ultimately, though your source code can now take advantage of parallelism while being completely standard-defined, the actual practical outcome of running your program is up to your implementation, and I think that still makes sense. The goal of standardising features is not cross-platform performance, but portable code that can be proven correct in a vacuum.

I'd expect your toolchain to give further information on how this sort of thing works, and that may even influence your choice of toolchain! But it does make sense for them to have freedom in that regard, as they do in other areas. After all, there is a multitude of target platforms out there (theoretically infinite), all with their own potential and quirks.

It could be that a future standard emplaces further constraints on scheduling in order to kick implementers up the backside a little, but personally I wouldn't count on it.

How do I use the new C++17 execution policies?

c++17 was not yet finalized. And various compilers have not yet fully implemented it.

-std=c++17 means "give me all of C++17 you have finished", not "be a perfectly valid C++17 compiler".

This feature is not supported by your compiler and/or standard library at this point. Check back in a few weeks/months/years.

There is no generally accepted "please give me C++17 if you fully support it, and otherwise give me an error" flag you can pass to a compiler; partly because it is of little practical use. If the subset of C++17 they provide is sufficient, then you win. And if you need a fully compliant compiler, specific versions of compilers don't know if they have bugs, so you couldn't trust the flag anyhow and would have to test it against compiler versions. And if you already know what versions of the compiler have sufficiently valid C++17, you don't need a flag to tell you.

---

Related Topics