Est-il possible de limiter le nombre de threads pour C ++ 17 parallèle `for_each`?

J'utilise std::for_eachavec std::execution::parpour effectuer des calculs complexes sur une énorme entrée représentée comme vecteur de structures. Le calcul ne nécessite aucun délai lié au matériel (réseau ou disque IO par exemple), il s'agit d'un calcul "juste CPU". Pour moi, il semble logique qu'il n'y ait aucun sens à créer plus de threads d'OS que nous en avons de matériels; cependant, Visual C ++ 2019 crée en moyenne 50 threads, et parfois jusqu'à 500, même s'il n'y a que 12 threads matériels.

Existe-t-il un moyen de limiter le nombre de threads parallèles à hardware_concurrencyavec std::for_eachet std::execution::par, ou la seule façon de créer un nombre de threads raisonnable est d'utiliser du code personnalisé avec std::thread?

Est-il possible de limiter le nombre de threads pour C ++ 17 parallèle for_each?

Non, du moins pas en C ++ 17. Cependant, il existe une proposition pour executorsune norme à venir, qui vous donne essentiellement la possibilité d'influencer le contexte d'exécution (en termes de lieu et de temps) pour l'interface de l'algorithme STL de haut niveau:

thread_pool pool{ std::thread::hardware_concurrency() };
auto exec = pool.executor();
std::for_each(std::execution::par.on(exec), begin(data), end(data), some_operation);

Jusqu'à alors, vous devez soit votre fournisseur de confiance du compilateur qu'il sait ce qui est le mieux pour la performance globale, comme par exemple les développeurs de Visual Studio Etat :

La planification de notre implémentation est gérée par le pool de threads système Windows. Le pool de threads tire parti des informations non disponibles pour la bibliothèque standard, telles que ce que font les autres threads du système, ce que les threads de ressources du noyau attendent, et similaires. Il choisit quand créer plus de threads et quand les terminer. Il est également partagé avec d'autres composants du système, y compris ceux qui n'utilisent pas C ++.

L'autre option serait de renoncer à se fier uniquement à la bibliothèque standard et d'utiliser les implémentations STL qui présentent déjà la nouvelle proposition.