Какие проблемы способствуют использованию параллельных / параллельных архитектур?

Меня очень воодушевляет возможность использования языков со встроенным параллелизмом / параллелизмом, таких как stackless python и erlang, и твердо уверены, что нам всем придется двигаться в этом направлении в ближайшее время - или захотите, потому что это будет хороший / простой способ добиться масштабируемости и производительности.

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

  • Реализовали ли вы что-нибудь достаточно большое в stackless, erlang или другом?
  • Почему это был хороший выбор? Был ли это хороший выбор? Вы бы сделали это снова?
  • Какие характеристики вашей проблемы означают, что одновременный / параллельный подход был правильным?
  • Вы переделали существующую проблему, чтобы воспользоваться преимуществами параллелизма / параллелизма? а также
  • если да, то как?

Есть ли у кого-нибудь опыт, которым они готовы поделиться?


concurrency parallel-processing erlang python-stackless stackless
person Simon    schedule 12.02.2009    source источник
comment
К сожалению, чтобы правильно ответить на ваши вопросы, требуются часы обсуждений / объяснений. Слишком много для быстрых вопросов и ответов.   -  person Ilia K.    schedule 16.04.2011

Ответы (4)


arrow_upward
4
arrow_downward

в прошлом, когда настольные компьютеры имели один процессор, распараллеливание применялось только к «специальному» параллельному оборудованию. Но в наши дни настольные компьютеры обычно имеют от 2 до 8 ядер, поэтому теперь стандартным стало параллельное оборудование. Это большая разница, и поэтому дело не только в том, какие проблемы предполагают параллелизм, но и в том, как применить параллелизм к более широкому набору проблем, чем раньше.

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

  • Вы получаете проблемы с согласованностью данных и блокировкой. Поэтому вам нужно попытаться организовать вашу проблему так, чтобы у вас были полунезависимые структуры данных, которые могут обрабатываться различными потоками, процессами и вычислительными узлами.
  • Параллелизм также может внести недетерминизм в ваши вычисления, если относительный порядок, в котором параллельные компоненты выполняют свою работу, влияет на результаты. Возможно, вам потребуется защититься от этого и определить параллельную версию вашего алгоритма, устойчивую к различным порядкам планирования.
  • Когда вы выходите за рамки параллелизма внутри материнской платы и переходите к сетевым / кластерным / грид-вычислениям, вы также сталкиваетесь с проблемами пропускной способности сети, выхода из строя сети и надлежащего управления отказавшими вычислительными узлами. Возможно, вам потребуется изменить вашу проблему, чтобы было легче справляться с ситуациями, когда часть вычислений теряется при выходе из строя сетевого узла.
person Antti Huima    schedule 13.02.2009
comment
Вот ссылка на статью Херба Саттера, в которой он рассказывает о том, как, когда у нас есть больше возможностей для параллелизма, это позволяет нам думать об одной и той же проблеме новыми способами (включая переопределение исходного объема проблемы): drdobbs.com/cpp/205900309 - person Christopher Howlin; 23.09.2011

arrow_upward
2
arrow_downward

До того, как у нас появились операционные системы, люди, создающие приложения, сидели и обсуждали такие вещи, как:

  • как мы будем хранить данные на дисках
  • какую структуру файловой системы мы будем использовать
  • с каким оборудованием будет работать наше приложение
  • и т. д. и т. д.

Операционные системы возникли из коллекций «библиотек разработчиков».

Прелесть операционной системы в том, что ваше НЕ НАПИСАННОЕ программное обеспечение имеет определенные характеристики, оно может:

  • поговорить с постоянным хранилищем
  • поговорить с сетью
  • запустить в командной строке
  • использоваться в партии
  • поговорить с графическим интерфейсом
  • и т. д. и т. д.

После того, как вы перешли на операционную систему - вы не вернетесь к прежнему положению вещей ...

Erlang / OTP (т.е. не Erlang) - это прикладная система, которая работает на двух или более компьютерах.

Прелесть СИСТЕМЫ ПРИЛОЖЕНИЙ в том, что ваше НЕЗАПИСАННОЕ программное обеспечение имеет определенные характеристики, оно может:

  • переключение между двумя машинами
  • работать в кластере
  • и т. д. и т. д.

Угадайте, что, если вы перешли на систему приложений - вы тоже не вернетесь назад ...

Вам не обязательно использовать Erlang / OTP, у Google есть хорошая система приложений в своем движке приложений, поэтому не зацикливайтесь на синтаксисе языка.

Вполне могут быть веские бизнес-причины для построения на стеке Erlang / OTP, а не на Google App Engine - бизнес-разработчики из вашей фирмы сделают это за вас.

person Gordon Guthrie    schedule 12.02.2009
comment
+1 Очень интересный ответ, спасибо. Однако мне кажется, что есть разница между алгоритмическим параллелизмом и распределенной последовательной обработкой, которую, я думаю, представляют такие модели, как GAE. Я еще не совсем решил об этом. - person Simon; 14.02.2009

arrow_upward
1
arrow_downward

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

В настоящее время я разрабатываю облегченную архитектуру, управляемую событиями, на основе Erlang / OTP. Это называется Tideland EAS. Я описываю идеи и принципы здесь: http://code.google.com/p/tideland-eas/wiki/IdeasAndPrinciples. Он не готов, но, возможно, вы поймете, о чем я.

муэ

person themue    schedule 12.02.2009
comment
Это не ограничивается способом общения объектов. Все архитектурные рассуждения должны измениться - так же, как это произошло с ООП - в противном случае у вас будут параллельно спроектированные последовательные приложения, что бессмысленно. Вы правы насчет оборудования; это уже произошло с двухъядерными процессорами, которые мы не используем. - person Simon; 12.02.2009
comment
Ага, это смена парадигмы. Я использовал слово «объекты» только для того, чтобы оно было более знакомым. В некотором смысле процессы Erlang - это особый вид объектов. На акторные системы повлияла передача сообщений Smalltalk, а Erlang во многих отношениях похож на Smalltalk-72. - person themue; 12.02.2009

arrow_upward
0
arrow_downward

Erlang заставляет вас думать о проблеме параллельно. Вы не забудете ни секунды. Через некоторое время вы адаптируетесь. Не большая проблема. Только решения стали параллельны в каждом уголке. Все остальные языки вам придется настроить. Быть параллельным. И это не кажется естественным. Тогда вы в конечном итоге возненавидите свое решение. Не смешно.

Самым большим преимуществом Erlang является отсутствие глобальной сборки мусора. Он никогда не сделает перерыв. Это важно, когда у вас 10000 просмотров страниц в секунду.

person FlinkmanSV    schedule 12.02.2009