Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Comments on Parallel execution with algorithms and execution policies
Parent
Parallel execution with algorithms and execution policies
I've just learned about algorithms, ranges and views (from a book), including execution policy such as std::execution::par and I naively tried:
import std;
int main() {
auto values {std::ranges::views::iota(0, 10)};
std::for_each(
std::execution::par,
std::begin(values), std::end(values),
[] (const auto value) {
std::println("value: {}, thread: {}",
value, std::this_thread::get_id());
}
);
return 0;
}
According to std::this_thread::get_id(), all iterations are handled by the same thread.
Does the compiler consider this a too simple task to warrant the overhead of setting up multiple threads or are there other preconditions to be met?
I am compiling with:
g++ -std=c++26 -O2 -Wall -fmodules -fsearch-include-path bits/std.cc -ltbb parallel.cpp -o parallel
Post
I can’t comment on mavieth’s answer, but I think their conclusion is correct; the libstdc++ std module doesn’t use the oneTBB backend.
It seems like the problem is that oneTBB, when included as headers, injects translation-unit-local stuff into the module purview… which is not allowed.
oneTBB is modularized (import tbb;, see the third line in the table), so if you wanted to use it in a modules context, you could… but you’d have to use the actual oneTBB API, not the standard API.
We will probably have to wait for libstdc++ and oneTBB to sort out their issues before libstdc++ can use oneTBB as a back-end during a modules build.
1 comment thread
0 comment threads