У вас есть основы, которые запирают параллелизм частям программы. C++ 17 получает много из них (например, параллельные версии foreach, sort, find и friends, map_reduce, map, reduce, prefix_sum ...) см. C++ Extensions for Parallelism
Тогда у вас есть такие предметы, как продолжения. Подумайте, std::future, но с продолжением. Существует несколько способов их реализации (boost имеет хороший вариант, так как std не имеет следующего (...) или затем (...) метода, но большая выгода заключается в том, что не нужно ждать это сделать следующую задачу
auto fut = async([](){..some work...}).then([](result_of_prev){...more work}).then... ;
fut.wait();
отсутствие синхронизации между последующими задачами важно, так как связи между задачами/нитями/... это то, что замедляет параллельные программы.
так что с этой задачей на основе параллельности очень хорошо. С планировщиком задач вы просто передаете задания и уходите. У них могут быть методы, например семафор, для связи, но это необязательно. Оба Intel Thread Building Blocks и Microsoft Parallel Pattern Library имеют fa для этого.
После этого у нас есть модель fork/join. Это не подразумевает создание N потоков для каждой задачи. Просто у вас есть эти N, идеально независимые вещи, которые нужно делать (fork), и когда они сделаны, есть точка синхронизации где-нибудь (join).
auto semaphore = make_semaphore(num_tasks);
add_task([&semaphore]() {...task1...; semaphore.notify(); });
add_task([&semaphore]() {...task2...; semaphore.notify(); });
...
add_task([&semaphore]() {...taskN...; semaphore.notify(); });
semaphore.wait();
Сверху вы можете начать просмотр шаблона, который является потоковым графом. Будущее (A >> B >> C >> D) и Fork Join (A | B | C | D). С этим вы можете объединить их для формирования графика. (A1 >> A2 | B1 >> B2 >> B3 | C1 | D1 >> D2 >> (E1 >> E2 | F1)), где A1 >> A2 означает, что A1 должен предшествовать A2, а A | B означает, что A и B может работать одновременно. Медленные части находятся в конце графиков/подграфов, где встречаются вещи.
Цель состоит в том, чтобы найти независимые части системы, которые не нуждаются в общении. Параллельные алгоритмы, как отмечалось выше, почти во всех случаях медленнее, чем их последовательные копии, пока рабочая нагрузка не станет достаточно высокой или размер становится достаточно большим (при условии, что общение не слишком чатовое). Например, сортировка. На четырехъядерном компьютере вы получите около 2,5X производительности, которые дают или принимают, потому что слияние является частым и требует много синхронизации и не работает со всеми ядрами после первого раунда слияния. На графическом процессоре с N, который является очень большим, можно использовать менее эффективную сортировку, такую как Bitonic, и она заканчивается очень быстро, потому что у вас много рабочих, чтобы работать через работу, и все спокойно делают свое дело.
Некоторые трюки для уменьшения связи включают в себя, используя массив для получения результатов, чтобы каждая задача не пыталась заблокировать объект, чтобы подтолкнуть значение. Часто позже сокращение этих результатов может быть очень быстрым.
Но со всеми типами параллелизма медлительность происходит от общения. Уменьшите его.
Можете ли вы уточнить, какое именно параллельное программирование вам интересны? Распределенное программирование с использованием MPI значительно отличается от параллелизма уровня цикла с использованием OpenMP. – mch 2008-11-01 17:58:17
Меня особенно интересуют общие шаблоны и идиомы в параллельном программировании - будь то с распределенной памятью или моделями с общей памятью на одной машине или на нескольких машинах. – 2008-11-01 18:09:35