Написание псевдокода для параллельного программирования

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

Ответ 1

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

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

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

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

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

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

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

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

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

После некоторых веб-исследований я понял, что своего рода "стандарт" все еще не существует. Как говорит @Larry Watanabe: "Псевдокод в значительной степени просто английский. Итак, вы можете использовать все, что понятно и недвусмысленно. Это не язык программирования, поэтому вам не нужно представлять такие операции, как" разброс "… вы можете просто сказать "разброс". "

Итак, вот мое личное решение с использованием algorithm2e: не так много подробностей о "разделяемой памяти", "локальной переменной" и т.д., Но при той же стратегии вы можете найти способ описать свою идею:

\usepackage[linesnumbered,ruled,vlined]{algorithm2e}
...
\begin{algorithm}
    \DontPrintSemicolon 
    \SetKwBlock{DoParallel}{do in parallel}{end}
    \KwIn{Some inputs}
    \KwOut{The ouput}
    \DoParallel{
        Compute a \;
        Compute b \;
        Compute c \;
    }
    \DoParallel{
        a1\;
        b1\;
        c1\;
    }
    \Return{the solution}\;
    \caption{Parallel Algo}
    \label{algo:parallelAlgorithm}
\end{algorithm}

Результат:

enter image description here

Он основан на определении новой команды с помощью выражения \SetKwBlock. Руководство по упаковке можно найти здесь. Я первоначально разместил ответ на этот вопрос также здесь.

Используя стратегию определения ваших ключевых слов, чтобы описать ваш алгоритм с деталями, которые вы предпочитаете, это должно быть всегда возможно. Примите во внимание, что:

  1. больше деталей & rarr; Чем больше вы будете ближе к вашим языкам программирования.
  2. меньше деталей & rarr; больше это можно рассматривать как псевдокод.

Заключение: это всегда вопрос компромиссов: вы решаете, где находится предел (принимая во внимание людей, на которых вы ссылаетесь).