Привет
Как в cpp можно узнать, сколько потоков оптимально запускать на конкретной машине?
Есть, скажем, очередь из n=1000 блоков данных. Есть процессор с 4-мя ядрами. Есть ли какие-то встроенные механизмы, чтоб узнать, что оптимально запустить 4 std::thread, которые будут разбирать из очереди и обрабатывать эти блоки по мере возможности? Или, возможно, есть какие-то более высокоуровневые средства для параллельной обработки множества блоков (не считая всякие железо-зависимые CUDA'ы)?
Спасибо
Здравствуйте, Михaил, Вы писали:
М>Как в cpp можно узнать, сколько потоков оптимально запускать на конкретной машине? М>Есть, скажем, очередь из n=1000 блоков данных. Есть процессор с 4-мя ядрами. Есть ли какие-то встроенные механизмы, чтоб узнать, что оптимально запустить 4 std::thread, которые будут разбирать из очереди и обрабатывать эти блоки по мере возможности? Или, возможно, есть какие-то более высокоуровневые средства для параллельной обработки множества блоков (не считая всякие железо-зависимые CUDA'ы)?
Linux/macOS/cygwin:
long number_of_processors = sysconf(_SC_NPROCESSORS_ONLN);
Здравствуйте, Михaил, Вы писали:
М>... есть какие-то более высокоуровневые средства для параллельной обработки множества блоков (не считая всякие железо-зависимые CUDA'ы)? М>Спасибо
Да «пожалуйста»:
OpenCL (Open Computing Language) is a framework for writing programs that execute across heterogeneous platforms consisting of central processing units (CPUs), graphics processing units (GPUs), digital signal processors (DSPs), field-programmable gate arrays (FPGAs) and other processors or hardware accelerators. OpenCL specifies programming languages (based on C99 and C++11) for programming these devices and application programming interfaces (APIs) to control the platform and execute programs on the compute devices. OpenCL provides a standard interface for parallel computing using task- and data-based parallelism.
OpenCL is an open standard maintained by the non-profit technology consortium Khronos Group. Conformant implementations are available from Altera, AMD, Apple (OpenCL along with OpenGL is deprecated for Apple hardware, in favor of Metal 2[7]), ARM, Creative, IBM, Imagination, Intel, Nvidia, Qualcomm, Samsung, Vivante, Xilinx, and ZiiLABS.
OpenMP is an implementation of multithreading, a method of parallelizing whereby a master thread (a series of instructions executed consecutively) forks a specified number of slave threads and the system divides a task among them. The threads then run concurrently, with the runtime environment allocating threads to different processors. ...
By default, each thread executes the parallelized section of code independently. Work-sharing constructs can be used to divide a task among the threads so that each thread executes its allocated part of the code. Both task parallelism and data parallelism can be achieved using OpenMP in this way.
The runtime environment allocates threads to processors depending on usage, machine load and other factors. The runtime environment can assign the number of threads based on environment variables, or the code can do so using functions. The OpenMP functions are included in a header file labelled omp.h in C/C++.
The Parallel Patterns Library (PPL) provides an imperative programming model that promotes scalability and ease-of-use for developing concurrent applications. The PPL builds on the scheduling and resource management components of the Concurrency Runtime. It raises the level of abstraction between your application code and the underlying threading mechanism by providing generic, type-safe algorithms and containers that act on data in parallel. The PPL also lets you develop applications that scale by providing alternatives to shared state.
The PPL provides the following features:
Task Parallelism: a mechanism that works on top of the Windows ThreadPool to execute several work items (tasks) in parallel
Parallel algorithms: generic algorithms that works on top of the Concurrency Runtime to act on collections of data in parallel
Parallel containers and objects: generic container types that provide safe concurrent access to their elements
оно количество ядер вернёт. А спрашивают про оптимальное количество потоков для разбора коллекции задач. Я например встречал число std::thread::hardware_concurrency * 2. Есть мнение, что кто-то что-то померил и получил, что надо умножать на два. Весьма спорное утверждение с учётом того, что число потоков желательно рассчитывать исходя из исходной загруженности системы. Но более продвинутых алгоритмов я не находил (хотя признаться и не искал).
Здравствуйте, sergii.p, Вы писали:
SP>оно количество ядер вернёт. А спрашивают про оптимальное количество потоков для разбора коллекции задач. Я например встречал число std::thread::hardware_concurrency * 2. Есть мнение, что кто-то что-то померил и получил, что надо умножать на два. Весьма спорное утверждение с учётом того, что число потоков желательно рассчитывать исходя из исходной загруженности системы. Но более продвинутых алгоритмов я не находил (хотя признаться и не искал).
Это все сугубо от кода зависит. Если он какой-то блокирующий ввод-вывод делает, то умножать на поболее чем 2 стоит. А если потоки сильно за общий ресурс толкаться будут, то и на 2 умножать не надо.
Общего рецепта нет.
Здравствуйте, Михaил, Вы писали:
М>Привет М>Как в cpp можно узнать, сколько потоков оптимально запускать на конкретной машине? М>Есть, скажем, очередь из n=1000 блоков данных. Есть процессор с 4-мя ядрами. Есть ли какие-то встроенные механизмы, чтоб узнать, что оптимально запустить 4 std::thread, которые будут разбирать из очереди и обрабатывать эти блоки по мере возможности? Или, возможно, есть какие-то более высокоуровневые средства для параллельной обработки множества блоков (не считая всякие железо-зависимые CUDA'ы)?
Очень просто запускаете с разным количеством потоков (1,2,3..100,...) и строите зависимость общей производительности (throughoutput) от этого количества. Если есть явный максимум то выбираете это число.
Здравствуйте, Михaил, Вы писали:
М>Привет М>Как в cpp можно узнать, сколько потоков оптимально запускать на конкретной машине? М>Есть, скажем, очередь из n=1000 блоков данных. Есть процессор с 4-мя ядрами. Есть ли какие-то встроенные механизмы, чтоб узнать, что оптимально запустить 4 std::thread, которые будут разбирать из очереди и обрабатывать эти блоки по мере возможности?
Вроде как, оптимальным всегда считалось соотношение "количество потоков = количество физических ядер + 1". С hyperthreading'ом уже не так всё однозначно и зависит от характера потоков. Но, скорее всего, "количество потоков = количество логических ядер + 1". Притом, очень желательно потоки привязывать к конкретным номерам ядер.
Здравствуйте, sergii.p, Вы писали:
SP>Я например встречал число std::thread::hardware_concurrency * 2.
И я где-то про такой же коэффициент вычитал.
С ним мои две пары ядер (гипертрэйдинг же) были загружены на 100%, перепахивая очередь.
Здравствуйте, sergii.p, Вы писали:
SP>Здравствуйте, reversecode, Вы писали:
R>>https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency
SP>оно количество ядер вернёт. А спрашивают про оптимальное количество потоков для разбора коллекции задач. Я например встречал число std::thread::hardware_concurrency * 2. SP>Есть мнение, что кто-то что-то померил и получил, что надо умножать на два. Весьма спорное утверждение с учётом того, что число потоков желательно рассчитывать исходя из исходной загруженности системы. Но более SP>продвинутых алгоритмов я не находил (хотя признаться и не искал).
Про это написанно у Рихтера при описании порта завершения. Там же все и объясняется, почему.
Ты всего лишь получишь количество логических ядер. Hyperthreading не учтён. А он мог дать очень существенную прибавку!
Хуже того: только тех, которые незапаркованы в данный момент (и легко могут быть сняты с парковки, даже автоматически — при повышении нагрузки в системе).
