¿Es posible limitar el recuento de subprocesos para C ++ 17 paralelo `for_each`?

Utilizo std::for_eachcon std::execution::parpara realizar cálculos complejos en una gran entrada representada como vector de estructuras. El cálculo no necesita retrasos relacionados con el hardware (red o disco IO, por ejemplo), es el cálculo "solo CPU". Para mí, parece lógico que no tenga sentido crear más subprocesos del sistema operativo que los que tenemos en el hardware; sin embargo, Visual C ++ 2019 crea en promedio 50 subprocesos y, a veces, hasta 500, incluso solo hay 12 subprocesos de hardware.

¿Hay una manera de limitar hilos paralelos contar hasta hardware_concurrencycon std::for_eachy std::execution::par, o la única manera de crear hilos razonables count es para uso con código personalizado std::thread?

¿Es posible limitar el recuento de subprocesos para C ++ 17 en paralelo for_each?

No, al menos no en C ++ 17. Sin embargo, hay una propuesta para executorsun estándar por venir, que básicamente le da la capacidad de influir en el contexto de ejecución (en términos de ubicación y tiempo) para la interfaz del algoritmo STL de alto nivel:

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);

Hasta entonces, debe confiar en su proveedor de compiladores para que sepa qué es lo mejor para el rendimiento general, como, por ejemplo, los desarrolladores de Visual Studio afirman :

La programación en nuestra implementación es manejada por el grupo de subprocesos del sistema de Windows. El grupo de subprocesos aprovecha la información que no está disponible para la biblioteca estándar, como qué están haciendo otros subprocesos en el sistema, qué subprocesos de recursos del núcleo están esperando y similares. Elige cuándo crear más subprocesos y cuándo terminarlos. También se comparte con otros componentes del sistema, incluidos aquellos que no usan C ++.

La otra opción sería renunciar a depender únicamente de la biblioteca estándar y usar implementaciones STL que ya cuentan con la nueva propuesta.