Почему я должен знать параллельное программирование?

Параллельное программирование для меня довольно сложно: даже просмотр базового слайда мне кажется сложным. Это кажется таким абстрактным.

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

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

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

ОК, вы хотите писать настольные приложения? У всего есть двухъядерный процессор. За исключением наименее дорогих машин. И люди с самыми дешевыми машинами, вероятно, не собираются переходить на ваше дорогое программное обеспечение, не так ли?

Может быть, вы хотите заняться мобильной разработкой? Эй, iPhone 4S имеет двухъядерный процессор. Остальное не будет далеко позади.

Видео игры? Xbox 360 - это многопроцессорная система, а Sony PS3 - это многоядерная система.

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

Обновление 2016 года : текущая версия Raspberry Pi за 35 долларов построена вокруг четырехъядерной системы на чипе, предназначенном для мобильных телефонов. Драматические достижения в области искусственного интеллекта были достигнуты отчасти благодаря доступности высококачественных видеокарт в качестве параллельных вычислительных движков.

С 1970 по 2002 год производительность процессоров удваивалась примерно каждые 18 месяцев. Поэтому, как программисту, все, что вам нужно было сделать, это ждать, и ваша программа будет работать быстрее. Проблема в том, что примерно в 2002 году правила изменились. Теперь они не делают большие быстрые процессоры, они делают меньшие более медленные процессоры, а раздают их по группам. Компьютер, на котором я сейчас работаю, имеет 4 ядра, и существуют чипы с 8 ядрами (и 4 потоками на ядро). Достаточно скоро у нас появятся чипы с гораздо большим количеством ядер.

Так что, если вы напишите программу, которая не является одновременно параллельной, вы обнаружите, что вы используете 1 ядро ​​или поток, но остальная часть CPU сидит там и ничего не делает. Так что, если у вас 16 ядер, 1 будет запускать вашу программу, а остальные 15 будут сидеть там!

Проблема с параллелизмом заключается в том, что он недетерминирован. То есть вы не знаете точно, в каком порядке будут работать разные потоки. Традиционно программисты пытались решить эту проблему с помощью блокировок и тому подобного. Это привело к МНОГО боли. Наличие некоторой формы изменчивого состояния, к которому более чем один поток может получить свободный доступ, часто является формулой боли и неприятных ошибок!

В последнее время наблюдается тенденция к переходу на функциональные языки, которые жестко контролируют изменяемое состояние. Есть два основных способа, которыми функциональные языки обрабатывают параллелизм. Первый - с помощью передачи сообщений. Это лучше всего показывает Эрланг. В Erlang вообще нет общего состояния между процессами. Они общаются не разделяя память, а мои мимолетные сообщения. Это должно иметь смысл для вас, поскольку мы делаем это прямо сейчас. Я посылаю вам эту информацию, отправляя вам сообщение, а не вспоминая его из моего мозга! При переключении на передачу сообщений большинство блокирующих ошибок просто исчезают. Кроме того, сообщения могут передаваться как по сети, так и внутри одного узла.

Другим методом является STM, который обозначает программную транскрипционную память, которая присутствует в clojure и Haskell (и других). В STM память разделяется, но изменения могут быть сделаны только через транзакцию. Поскольку люди из базы данных выяснили все эти вещи в 1970-х годах, довольно легко убедиться, что мы правильно поняли.

На самом деле я немного упростила, Clojure и Haskell могут выполнять передачу сообщений, а Erlang может выполнять STM.

Отказ от ответственности Я являюсь автором веб-службы программирования с Erlang , которая будет выпущена в раннем выпуске в ближайшие несколько недель.

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

Первое правило параллельного программирования - «Это сложно». Второе правило параллельного программирования - "Это. Сложно" .. !!

Если серьезно, то есть два общих подхода к параллельному программированию: многопоточность и многопроцессорность. Многопроцессорность легче всего понять, поскольку она просто означает наличие нескольких экземпляров процесса, выполняемого для выполнения задачи. Это довольно легко сделать в системах на основе Unix с помощью вызовов fork / join, но не так просто в системах Windows.

Многопоточность - это, вероятно, тот подход, о котором думают большинство людей, говоря о параллелизме. Нетрудно запустить несколько потоков в приложении, но дьявол кроется в деталях. Вам необходимо координировать обмен данными между потоками (обычно с использованием блокировок), что может привести к взаимоблокировке или данным в недопустимом состоянии. Вы также должны понимать, как общаться между потоками, используя такие понятия, как семафоры, условные переменные и т. Д. И т. Д.

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

Недостатком является то, что вы должны начать думать о том, как вы будете разбивать свое приложение на маленькие части, которые можно запускать в разных потоках. Это намного сложнее, чем кажется. Кроме того, высококонкурентные решения могут быть неудобны для модульного тестирования, поскольку порядок выполнения менее детерминирован.

В наши дни большинство языков поставляются с абстракцией над большинством примитивов, чтобы сделать жизнь немного проще. Например, .NET 4 поставляется с библиотекой параллельных задач, которая немного облегчает жизнь. На земле Java у них есть пакет Concurrency .

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

Работая с PHP, я делал все по-старому, и лучшее время, которое я получил после нескольких часов работы, привело к ~ 120 секундам для запуска определенного теста (много запросов + сетевая задержка + нет асинхронности)

Но этого было недостаточно, по сравнению с тем, что мне было нужно, и после неудачной неудачи с многопроцессорной обработкой PHP я переключился на Python.

Через несколько часов у меня был запущен многопроцессорный скрипт Python, который запускался через 20 секунд, и после небольшого перерыва с таймаутами и нет. из потоков, которые будут использоваться, я получил его до ~ 10 секунд .

Это было для веб-сайта, написанного на 100% на PHP, за исключением одного 100-строчного скрипта Python. И все это работает отлично.

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

Удачи и счастливого кодирования!

PS: я не пытаюсь разбить PHP, но PHP просто не был подходящим инструментом для работы.

PS2: Знание новой технологии или нового способа ведения дел может открыть дверь в целый новый мир возможностей.

Если вы занимаетесь веб-разработкой, в игру вступает параллелизм, по крайней мере, с большинством языков. Например, я использую Spring для веб-разработки, и каждый новый запрос поступает в виде своего собственного потока. Следовательно, если какой-либо запрос заканчивается доступом к общему объекту, где состояние переменной можно изменить, параллелизм является очень важным фактором, и его необходимо принимать во внимание. Если это не так, то данные могут быть отредактированы непредсказуемым образом, что может привести к повреждению данных. Не важно знать каждую мельчайшую деталь о параллелизме, но изучение элементов за раз важно для лучшего понимания программирования веб-приложений, если вы работаете над настольными приложениями, возможно, это не так важно, если вам не нужно запускать несколько потоков

Изучите понимание операционных систем. Чтение исходного кода планировщиков и драйверов устройств поможет; они определенно совпадают.