this is not really JUCE-specific, but several people here may already have encountered this:
I was implementing some code in C++ (using C++17) in Visual Studio 2022 using the “new” std::execution policy par with a for_each loop, which worked fine and gave some worthwhile speedup. It’s something like this:
But then when I tried to compile the C++ code on iOS in Xcode 15 (having set C++ Language Dialect to -std=c++17) that gives me errors such as: “No member named ‘par’ in namespace ‘std::execution’”
I’ve looked around a bit and it seems like Apple Clang doesn’t support the execution policy things yet.
I then also tried setting the C++ Language dialect to c++20 (and also gnu++17 and gnu++20), but none of that worked.
Are there ways of getting this to work in Xcode for iOS too, or do I have to accept that such code is just not cross-platform at this point due to compiler differences?
Edit:
And is there actually a way to detect in code if execution::par is available at all?
Or will it come down to checking _MSC or similar preprocessor defines to differentiate the code?
I think such code is not portable across compilers and standard libraries at the moment. Even once parallel algorithms are supported by Apple Clang, I would expect them to need a recent (future?) deployment target.
There are standard preprocessor definitions to check for specific language and library features. The one you need is __cpp_lib_parallel_algorithm.
Thanks @reuk for your reply.
Yes, it’s probably going to take some years, before this is all going to be actually standard.
The standard preprocessor check was what I needed indeed.
I’m assuming it’s also not a good idea to move processing code using for_each loops with execution::par to a processing chain that is run on the audio thread, right?
Because when it actually does do parallelization, it will be spawning separate threads, if I understood it correctly, and that doesn’t seem like something one should do on the audio thread…
Now, I also saw that from C++20 there is a 4th option execution::unseq, which does seem like it may be useful for parallelization of audio processing code that needs to run on the audio thread.
Because if I understood it correctly, that one should not spawn threads, but vectorize code (if possible and the compiler implements it, and if the code can be written in a vectorization-safe way).
@ttg
The table is actually not very clear, if you read the line “Parallel algorithms and execution policies” you will find the Intel Parallel STL table marked.
You can indeed use the parallel algorithms with clang /Apple clang (on macOS, iOS, Android or Linux), but you have to link against tbb and tbbmalloc (statically or dynamically), and download and install oneDPL from intel: oneDLP
or install it with homebrew (MacOS, iOS):
brew install onedpl
To avoid linking errors, it is better to include the headers in the following way (example):
#include <dpl/algorithm>
#include <dpl/execution>
and then you can use the parallel execution (example)
std::for_each(std::execution::par_unseq ... more code)
You can use the parallel stl in the same way in Android or iOS, see: Google Open Source Parallel STL
As stated there, you need to compile and link against tbb.
I’ve been using the parallel stl in this way since about 2020. It works fine in Android or iOS too.
