Параллельное программирование и будущее

При подготовке моего выступления для LL2 я пытался придумать способ объяснить, что мы делали с Erlangом в течение последних 15 лет. При этом я придумал фразу «параллельное программирование» - тогда я думал об аналогии с объектно-ориентированным программированием. Что касается ОО-программирования, я придерживался мнения, что:

· Язык ОО характеризуется неопределенным набором правил.

· Никто не согласен с этими правилами.

· Все узнают ОО-язык, когда видят его.

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

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

Основные идеи в COP:

· Системы состоят из процессов.

· Процесс ничем не делиться.

· Процессы взаимодействуют посредством асинхронной передачи сообщений.

· Процессы изолированы.

 

По этим критериям PLEX и Erlang могут быть описаны как языки, ориентированные на параллелизм.

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

Объяснения того, чем был Erlang, со временем изменились:

1. 1986 - Erlang - декларативный язык с дополнительным параллелизмом.

2. 1995 - Erlang - функциональный язык с дополнительным параллелизмом.

3. 2005 - Erlang - это параллельный язык, состоящий из взаимодействующих компонентов, где компоненты написаны на функциональном языке. Интересно, что это отражает более раннюю работу в EriPascal, где компоненты были написаны на Pascal.

 

Теперь 3) намного лучше соответствует реальности, чем когда-либо 1) или 2). Хотя функциональное сообщество всегда с радостью указывало на Erlang как на хороший пример функционального языка, статус Erlang как полноправного члена функциональной семьи сомнителен. Программы Erlang не являются ссылочно прозрачными, и нет системы для статического анализа типов программ Erlang. Это не реляционный язык. Последовательный Erlang имеет чисто функциональное подмножество, но никто не может заставить программиста использовать это подмножество; действительно, часто есть веские причины не использовать его.

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

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

Если язык внутри черных ящиков имеет второстепенное значение, то что имеет первостепенное значение? Я подозреваю, что важным фактором являются пути взаимосвязи между черными ящиками и протоколами, наблюдаемыми на каналах между черными ящиками. Что касается будущего развития Erlang, я могу только догадываться. Плодотворная область исследований должна заключаться в формализации межпроцессных протоколов, которые используются и соблюдаются. Это можно сделать с помощью синхронных исчислений, таких как CSP, но меня больше привлекает идея проверки протокола при условии согласованного контракта. Такая система, как UBF [6], позволяет компонентам обмениваться сообщениями в соответствии с согласованным контрактом. Контракт проверяется динамически, хотя я подозреваю, что подход, аналогичный тому, который использовался в Dialyzer, мог бы быть использован для удаления некоторых проверок.

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

Я считаю, что я не одинок в этом убеждении. Пол Моррисон [23] написал книгу в 1992 году, предполагая, что программирование на основе потоков является идеальным способом построения программных систем. В его системе, которая во многих отношениях очень похожа на Erlang, межпроцессные каналы между процессами являются первоклассными объектами с бесконечной емкостью памяти. Трубы можно включать и выключать, а концы соединять с различными процессами. Этот взгляд на мир концентрируется на потоке данных между процессами и гораздо больше напоминает программирование в индустрии управления процессами, чем обычное алгоритмическое программирование. Упор делается на данные и то, как они проходят через систему.

Erlang в наши дни

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

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

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

Обычная стратегия выживания в Ericsson в этот период времени заключалась в том, чтобы называть Erlang чем-то другим. Erlang был забанен, а OTP - нет. Некоторое время новые проекты, использующие Erlang, не запускались, но было нормально использовать OTP. Затем были заданы вопросы об OTP: «Разве OTP - это не просто загрузка библиотек Erlang? » - так он стал «Engine» и так далее.

После 2002 года некоторые из выживших членов Bluetail, которые переехали в Nortel, ушли и основали ряд компаний 2-го поколения, в том числе Tail-F, Kreditor и Synapse. Все базируются в Стокгольмском регионе и процветают.

За пределами Швеции распространение Erlang было одинаково захватывающим. В Великобритании мой бывший студент основал Erlang Consulting, которая нанимает консультантов Erlang для промышленности. Во Франции Process-one производит оборудование для веб-стресс-тестирования и решения для обмена мгновенными сообщениями. В Южной Африке Erlang Financial Systems производит банковское программное обеспечение. Все эти внешние события были спонтанными. Заинтересованные пользователи обнаружили Erlang, установили релиз с открытым исходным кодом и начали программировать. Большая часть этого сообщества объединена списком рассылки Erlang, который насчитывает тысячи участников и очень активен. В Стокгольме проводится ежегодная конференция, на которой всегда много посетителей.

 

В последнее время серверы Erlang начали находить широкое применение в интернет-приложениях. Jabber.org использует сервер обмена мгновенными сообщениями ejabberd, написанный на Erlang и поддерживаемый Process-one.

Пожалуй, самая захватывающая современная разработка - это Erlang для многоядерных процессоров. В августе 2006 года группа OTP выпустила Erlang для SMP. В большинстве других сообществ программистов задача многоядерного процессора состоит в том, чтобы ответить на вопрос: «Как я могу распараллелить мою программу? » Программисты Erlang не задают таких вопросов; их программы уже параллельны. Они задают другие вопросы, такие как «Как я могу увеличить параллелизм в уже параллельной программе? » Или «Как я могу найти узкие места в моей параллельной программе? », Но проблема распараллеливания уже решена.

Решения «не делай ничего, что делятся сообщениями», которые мы приняли в 1980-х годах, создают код, который прекрасно работает на многоядерном процессоре. Большинство наших программ работают быстрее, когда мы запускаем их на многоядерном процессоре. В попытке еще больше увеличить параллелизм в уже параллельной программе, я недавно написал параллельную версию map (pmap), которая отображает функцию поверх списка параллельно. Выполнение этого на восьмиъядерном процессоре Sun Fire T2000 Server с четырьмя потоками на ядро ​ ​ позволило моей программе работать в 18 раз быстрее.

Ошибки и извлеченные уроки

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

Сначала общие уроки:

Разработка Erlang была основана на прототипе

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

Сначала мы написали код, затем мы написали документацию. Часто пользователи указывают, что код не выполняет то, что сказано в документации. На этом этапе разработки мы сказали им: «Если код и документация не совпадают, значит, код верный, а документация неправильная». Мы добавили новые вещи в язык и улучшили код, а когда все стабилизировалось, мы обновили документацию. согласиться с кодом.

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

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

Параллельные процессы легко объединять (связывать)

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

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

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

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

Людей не убедишь теорией -, только практикой

Мы часто говорили, что что-то можно сделать (что они теоретически возможны), но на самом деле не делали этого. Часто наши оценки того, как быстро мы могли что-то сделать, были намного короче, чем обычно считалось возможным. Это создало своего рода пробел в кредитоспособности, когда мы что-то не реализовали, потому что думали, что это действительно легко, а руководство полагало, что мы не знаем, о чем мы говорим, потому что мы на самом деле ничего не реализовали. На самом деле, обе стороны, вероятно, ошибались, мы часто недооценивали сложность реализации, а руководство переоценивало сложность.

Язык не был запланирован для изменения с самого начала

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

Язык имеет фиксированные пределы и границы

Почти каждое решение использовать структуру данных фиксированного размера было неправильным. Первоначально Pids (идентификаторы процессов) были 32-битными объектами стека - это было сделано по «соображениям эффективности». В конце концов мы не смогли объединить все, что мы хотели описать, в 32-битные, поэтому мы перешли к объектам и указателям большего размера. Ссылки должны были быть глобально уникальными, но мы знали, что это не так. Была очень малая вероятность того, что могут быть сгенерированы две идентичные ссылки, что, конечно же, и произошло. Теперь для конкретных уроков: Есть еще ряд областей, где Erlang должен быть улучшен. Вот краткий список:

⇐ Предыдущая123456

Поделиться: