переключиться на параллельное кодирование - PullRequest
3 голосов
/ 18 сентября 2008

мы все пишем код для одного процессора. Интересно, когда мы все сможем написать код на нескольких процессорах?

что нам нужно (программные средства, логика, алгоритмы) для этого переключения?

edit: на мой взгляд, так как мы выполняем много задач параллельно, мы должны конвертировать эти реальные решения (алгоритмы) в компьютерный язык. так же, как кодирование ООП было сделано для процедурного кодирования. ООП - это стиль программирования в реальной жизни, а не процедурный. так что я надеюсь на такие решения.

Ответы [ 7 ]

4 голосов
/ 18 сентября 2008

Нам нужны естественные абстракции для высококонкурентных алгоритмов. Актеры (подумайте: Эрланг) проделывают большой путь в этом направлении, но они не являются универсальным решением для всех. Некоторые более специфические абстракции, такие как fork / join или map / lower, могут быть еще проще применить к распространенным проблемам.

Хитрость во всех этих абстракциях параллелизма заключается в том, что они требуют программирования в функциональном стиле. Параллелизм плохо сочетается с общим изменяемым состоянием. Как говорится, «Замки считаются вредными». Поскольку большинство разработчиков имеют исключительно императивный опыт, переход на метод продолжения без разделения ресурсов часто бывает чрезвычайно сложным.

Кстати, в отношении абстракций параллелизма Clojure имеет некоторые очень интересные особенности в этом направлении. Он не только имеет своего рода акторов, но и определяет модель транзакционной памяти (например, базы данных) вместе с глобальным механизмом атомарных ссылок. Эти две функции позволяют параллельным операциям совместно использовать «изменяемое» состояние, не беспокоясь о блокировке или гонке.

В конце концов, все сводится к образованию. Большая часть необходимой теоретической работы по абстракциям параллелизма уже выполнена, нам просто нужно принять это. К сожалению, как доказывают Эрланг и Хаскелл, иногда лучшие идеи остаются отодвинутыми на крайне ограниченный демографический уровень. Надеемся, что такие усилия, как Scala и Clojure, позволят внедрить более продвинутые абстракции в мейнстрим, перенеся их на существующую, хорошо поддерживаемую платформу (JVM).

4 голосов
/ 18 сентября 2008

Я думаю, что наиболее важным требованием является хороший язык с нативными конструкциями, поддерживающими параллелизм, или язык, который может автоматически генерировать параллельный код. Существует немало языков, которые соответствуют этому описанию, но ни один из них не настолько популярен, чтобы его можно было использовать для массового использования. Это, в свою очередь, вызвано несколькими причинами:

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

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

Примером языка, разработанного с большой степенью параллелизации, является Erlang - и он фактически используется в коммерческих проектах.

3 голосов
/ 09 октября 2008

Существует несколько инструментов / языков, которые популярны или набирают популярность. Если вы используете FORTRAN, C или C ++, вы можете использовать OpenMP (не слишком сложно реализовать) или библиотеки Message Passing Interface (MPI) (мощный и наибольший потенциал ускорения, но тоже сложно и сложно). OpenMP использует директивы препроцессора для маркировки областей, которые могут быть распараллелены, особенно циклы. MPI использует сообщения, которые передают данные назад и вперед между процессами, и самая большая сложность заключается в том, чтобы все синхронизировать, не выходя из узких мест, и не заставляя процессы ждать. Однако я бы сказал, что MPI определенно находится на выходе. В научных / высокопроизводительных вычислительных сообществах стало ясно, что ускорение редко стоит дополнительного времени на разработку.

Что касается предстоящих языков, ознакомьтесь с Fortress . Он все еще разрабатывается, но цель состоит в том, чтобы создать язык, более удобный для научных вычислений, чем FORTRAN. Программы будут указаны в очень высоком математическом синтаксисе. Кроме того, параллелизм будет неявным; программист должен будет работать, чтобы делать вещи в последовательном. Кроме того, он защищен Sun и основан на Java, поэтому он будет переносимым.

3 голосов
/ 18 сентября 2008

К сожалению, для массового параллельного программирования - если не будет прорыва в компиляторах, чтобы помочь, мы будем выбрасывать многое из того, что мы знаем об алгоритмах (я думаю, Дон Кнут даже сказал это) Прочитайте об Эрланге, чтобы взглянуть на это возможное будущее.

0 голосов
/ 17 августа 2013

для Java теперь вы можете обратиться к Parallel Java Library или DPJ (детерминированный Parallel Java!) Он предложит вам большую помощь в извлечении параллелизма из кодов !!

0 голосов
/ 24 сентября 2008

Самое важное требование - это иметь возможность разбить вашу проблему на более мелкие проблемы, которые могут быть решены независимо друг от друга. После того, как вы выяснили, как вы собираетесь это сделать, обо всем остальном легче подумать и задать дополнительные вопросы реализации (например, «части моего расчета зависят от других частей - как мне ждать, пока они закончатся?» ) стать конкретными, конкретными вещами, которые вы можете исследовать или спросить здесь.

0 голосов
/ 18 сентября 2008

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...