Czy można ograniczyć liczbę wątków dla równoległego `for_each` C ++ 17?

Używam std::for_eachz std::execution::pardo wykonywania złożonych obliczeń na ogromnych danych wejściowych reprezentowanych jako wektor struktur. Obliczenia nie wymagają żadnych opóźnień związanych ze sprzętem (na przykład IO sieci lub dysku), są obliczeniami „tylko procesora”. Dla mnie wydaje się logiczne, że nie ma sensu tworzyć więcej wątków systemu operacyjnego niż mamy wątki sprzętowe; jednak Visual C ++ 2019 tworzy średnio 50 wątków, a czasem nawet 500 wątków, nawet jeśli jest tylko 12 wątków sprzętowych.

Czy istnieje sposób, aby ograniczyć równoległe wątki liczyć do hardware_concurrencyz std::for_eachi std::execution::parczy jedynym sposobem na stworzenie racjonalne wątki liczyć jest użycie kodu niestandardowego z std::thread?

Czy można ograniczyć liczbę wątków dla równoległego C ++ 17 for_each?

Nie, przynajmniej nie w C ++ 17. Jednak executorsw standardzie pojawi się propozycja , która w zasadzie daje możliwość wpływania na kontekst wykonania (pod względem lokalizacji i czasu) interfejsu algorytmu wysokiego poziomu STL:

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

Do tego czasu trzeba albo zaufania ze sprzedawcą kompilatora, który wie, co jest najlepsze dla ogólnej wydajności, jak np twórcy Visual Studio stanu :

Planowanie w naszej implementacji jest obsługiwane przez systemową pulę wątków systemu Windows. Pula wątków korzysta z informacji niedostępnych dla standardowej biblioteki, takich jak inne wątki w systemie, na jakie zasoby jądra czekają wątki i tym podobne. Wybiera, kiedy utworzyć więcej wątków i kiedy je zakończyć. Jest także współdzielony z innymi komponentami systemu, w tym tymi, które nie używają C ++.

Inną opcją byłoby zrezygnowanie z polegania wyłącznie na standardowej bibliotece i stosowanie implementacji STL, które już zawierają nową propozycję.