Написание псевдокода для параллельного программирования - PullRequest
22 голосов
/ 07 апреля 2011

Как вы пишете псевдокод для параллельного программирования? Особенно, как вы различаете локальные и общие переменные? Как вы представляете такие операции, как рассеяние, сбор, уменьшение, трансляция и двухточечная связь? Есть ли какие-то стандарты по этому поводу?

Ответы [ 6 ]

12 голосов
/ 17 апреля 2011

Псевдокод в значительной степени просто английский.Таким образом, вы можете использовать все, что ясно и недвусмысленно.Это не язык программирования, поэтому вам не нужно представлять такие операции, как «разброс» .. вы можете просто сказать «разброс».

Стандартов для псевдокода нет, но хороший псевдокодпросто и легко понять.

4 голосов
/ 17 апреля 2011

Я нашел по крайней мере один псевдоязык для параллельного программирования: Peril-L .Это формально, но на мой вкус немного слишком низко.

1 голос
/ 04 июня 2014

Короткий ответ на ваш вопрос заключается в том, что не существует традиционного способа написания псевдокода для параллельного программирования.

Это связано с тем, что существует множество способов параллельного программирования с точки зрения различных параллельных архитектур (например, SMP, графических процессоров, кластеров и других экзотических систем) и подходов параллельного программирования. Я имею в виду «подходы к программированию», потому что в большинстве случаев это библиотеки или аннотации, а не языки (см. MPI, OpenMP, TBB и т. Д.). Таким образом, даже если вы сможете выбрать архитектуру и язык, у вас будут трудности с определением семантики библиотеки или системы аннотаций.

К счастью, были разработаны более строго определенные подходы к программированию. Тем не менее, они обычно основаны на передаче сообщений или в общей памяти. Поиск подходящей нотации / псевдокода будет зависеть от того, в какой степени вам требуется определить семантику и какие типы проблем параллельного программирования вы пытаетесь выразить.

Вот два предложения:

  • PRAM . Программирование с общей памятью тесно связано с моделью вычисления параллельной машины с произвольным доступом (PRAM). Это было широко изучено, и в нем разработано много алгоритмов. Быстрый поиск литературы выведет подходящие нотации PRAM.
  • СНТ . Связь последовательных процессов (CSP) - это формализм (алгебра) для выражения и рассуждения о системах передачи сообщений. Он оказал влияние на дизайн многих языков, в частности occam .

Модель PRAM очень проста и должна использоваться в качестве основы для нотаций программирования с общей памятью. Сам CSP может быть слишком математическим для псевдокода, а нотация occam может быть слишком многословной. Это было мнение Бринча Хансена (великого в параллельном программировании), который разработал свой родственный язык, SuperPascal, для использования в качестве нотации для объяснения параллельных алгоритмов в публикациях.

Насколько мне известно, не было разработано никаких других языков для параллельных вычислений, которые могли бы быть строго определены и / или пригодны для использования в качестве нотации высокого уровня.

1 голос
/ 24 апреля 2011

Попробуйте «написание диаграмм» здесь: http://www.websequencediagrams.com/

В итоге вы получите лучшее из обоих миров, довольно простые английские выражения («псевдокод») и чистые диаграммы. Я смог объяснить довольно сложное параллельное программирование моим менеджерам и коллегам, используя эти диаграммы. И последнее, но не менее важное: на схеме «источник» можно проверить систему управления источниками.

0 голосов
/ 23 апреля 2011

Рассматривали ли вы подход, основанный на поведенческом развитии?Недавно я собрал довольно сложный многопроцессорный / многоядерный код, используя подход BDD, и нашел его очень полезным.Лучшая часть подхода заключалась в том, что я мог описать все на простом английском языке и сосредоточиться на проблеме, а не на деталях реализации.Мои первые несколько итераций были однопоточными, чтобы код прошел все тесты и решил проблему.Я повысил производительность системы, используя многопроцессорность в выбранных местах, при этом следя за тем, чтобы она не сломала тесты, которые прошла однопоточная система.Рефакторинг был намного проще, потому что код уже был значительно проще, чем если бы я раньше проектировал детали оптимизации проектирования, и я мог бы сосредоточиться на мониторинге времени обработки реорганизованных систем, поскольку я получал точно такие же результаты, как и предыдущие итерации.

Взгляните на книгу Test Driven Development для Embedded C , чтобы найти некоторые идеи.Я использовал эту книгу во время своей разработки и сделал ее постоянной частью моей библиотеки.

0 голосов
/ 21 апреля 2011

Это эссе Мэтью Адамса , вероятно, является лучшим введением, которое я видел, проходя через процесс многопоточности с использованием формы псевдокода.

...