Параллельное программирование *

На Хабре крайне мало информации о таком языке программирования как Squeak. Я попытаюсь рассказать о нем в контексте моделирования систем массового обслуживания. Покажу как написать простой класс, расскажу его структуру и использую его в программе, которая будет обслуживать заявки посредством нескольких каналов.

Пару слов о Squeak

Squeak это открытая, кросс-платформенная реализация языка программирования Smalltalk-80 c динамической типизацией и сборщиком мусора. Интерфейс довольно специфический, но вполне удобный для отладки и анализа. Squeak полностью отвечает концепции ООП. Все состоит из объектов, даже конструкции if-then-else, for, while реализованы с их помощью. Весь синтаксис сводится к посылке объекту сообщения в виде:

<объект> <сообщение>

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

Я искал, с чем бы сравнить программирование на С++ и я вспомнил фильм 1990 года режиссера Тима Бертона — «Эдвард руки-ножницы»

От переводчика: Это вторая статья из цикла о Node.js от команды Mozilla Identity, которая занимается проектом Persona. Эта статья написана по мотивам выступления Ллойда Хилайеля на конференции Node Philly 2012 в Филадельфии.

Все статьи цикла:

1. "Охотимся за утечками памяти в Node.js"
2. "Нагружаем Node под завязку"
3. "Храним сессии на клиенте, чтобы упростить масштабирование приложения"
4. "Производительность фронтэнда. Часть 1 — конкатенация, компрессия, кэширование"
5. "Пишем сервер, который не падает под нагрузкой"
6. "Производительность фронтэнда. Часть 2 — кешируем динамический контент с помощью etagify"
7. "Приручаем конфигурации веб-приложений с помощью node-convict"
8. "Производительность фронтенда. Часть 3 — оптимизация шрифтов"
9. "Локализация приложений Node.js. Часть 1"
10. "Локализация приложений Node.js. Часть 2: инструментарий и процесс"
11. "Локализация приложений Node.js. Часть 3: локализация в действии"
12. "Awsbox — PaaS-инфраструктура для развёртывания приложений Node.js в облаке Amazon"

---

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

Кроме того, мы представим модуль compute-cluster — маленькую библиотеку, которая облегчает управление коллекцией процессов для выполнения распределённых вычислений.

Постановка задачи

Для Persona нам было необходимо создать сервер, который справился бы с обработкой множества запросов со смешанными характеристиками. Мы выбрали для этой цели Node.js. Нам надо было обрабатывать два основных типа запросов: «интерактивные», которые не требовали сложных вычислений и должны были выполняться быстро, чтобы интерфейс приложения был отзывчивым, и «пакетные», которые отнимали примерно пол-секунды процессорного времени и могли быть ненадолго отложены без ущерба для удобства пользователя.

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

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

Вооружившись этими требованиями, мы можем осмысленно сравнивать разные подходы.

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

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

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

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

Пакет Intel Parallel Studio XE давно известен разработчикам, в том числе и по публикациям в блоге Intel на Хабре. Недавно вышло обновление - Intel Parallel Studio XE 2013 Service Pack 1 (SP1), имеющее ряд интересных новшеств. Становится проще программировать для со-процессоров и встроенной графики, во многом благодаря поддержке стандарта OpenMP 4.0 (частичной). Поиск ошибок стал гибче, утечки памяти теперь обнаруживаются до завершения процесса, т.е. их можно искать в долгоиграющих сервисах и «падающих» приложениях. Найти узкие места в производительности будет легче благодаря новому представлению дерева вызовов, оценке накладных расходов и детальной информации о параллельных конструкциях.

Уважаемые хабровчане! Приглашаем вас принять участие в ежегодной конференции Intel Software Conference 2013, которая состоится 17 сентября в Иркутске и 19 сентября в Москве.
Вашему вниманию будут предложены доклады, посвященные двум флагманским программным продуктам Intel для разработчиков — Intel Parallel Studio XE и Intel Cluster Studio XE. Специалистов, занимающихся разработкой программных решений для встроенных систем на платформах Intel, также заинтересует обзор нового специализированного набора инструментов Intel System Studio. Разработчикам вычислительно-интенсивных и облачных решений предназначены доклады о портировании приложений на платформу Intel Xeon Phi.
В течение дня будет организована демозона, в которой ведущие специалисты Intel покажут возможности новейших средств разработки, включая инструменты для создания и отладки многопоточных программ и возможности нового вычислительного сопроцессора Intel Xeon Phi.
Зарегистрироваться на конференцию.

То, что происходит внутри программы очень похоже на деятельность команды из нескольких человек. У каждого члена команды есть своя задача и, скорее всего, своё «рабочее место» к которому никто кроме него не должен прикасаться. Коллеги могут давать друг другу поручения и передавать какую-нибудь информацию о рабочем процессе. Они могут просить друг у друга помощи и могут оказывать её. Как и у любой команды у них есть начальник, в задачу которого входит взаимодействие с пользователем и координация действий внутри команды.

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

Исходные коды плеера, на который я когда-то потратил кучу времени, уже давно пылятся на жестком диске. Я писал это приложение в течении года когда появлялось настроение. В конце концов у меня иссяк энтузиазм и плеер был забыт. И вот недавно мне в голову пришла идея архитектуры, которая, как оказалось, отлично к нему подходит — о ней далее и пойдет речь. Я выделю «работников» в приложении, и распределю роли так, чтобы у каждого работника была чёткая, максимально простая, и понятная задача.

Rust — новый язык программирования, разрабатываемый корпорацией Mozilla. Главная цель разработчиков — создание безопасного практичного языка для параллельных вычислений. Первая версия языка была написана Грэйдоном Хором в 2006 году, а в 2009 году к разработке подключилась Mozilla. С тех пор изменения претерпел и сам компилятор, изначально написанный на OCaml: он был успешно переписан на Rust с использованием LLVM в качестве back-end.

Основным продуктом, разрабатываемым на Rust, является новый веб-движок Servo, разработка которого также ведется Mozilla. В 2013 году к разработке Rust и Servo присоединилась корпорация Samsung Electronics, при активном участии которой код движка Servo был портирован на ARM архитектуру. Поддержка языка столь серьезными игроками IT индустрии не может не радовать и дает надежду на его дальнейшее активное развитие и совершенствование.

Язык Rust просто не может не понравится системным и сетевым разработчикам, тем, кому по работе приходится писать много кода, производительность которого критична, на C и C++, потому что:

1. Rust ориентирован на разработку безопасных приложений. Сюда входит безопасная работа с памятью: отсутствие null-указателей, контроль за использованием не инициализированных и деинициализированных переменных; невозможность совместного использования разделяемых состояний несколькими задачами; статический анализ времени жизни указателей.
2. Rust ориентирован на разработку параллельных приложений. В нем реализована поддержка легких (зеленых) потоков, асинхронного обмена сообщениями без копирования пересылаемых данных, возможность выбора размещения объектов на стеке, в локальной куче задачи или куче, разделяемой между задачами.
3. Rust ориентирован на разработку эффективных по скорости и памяти приложений. Использование LLVM в качестве back-end позволяет производить компиляцию приложения в нативный код, а простой интерфейс взаимодействия с C кодом – легко использовать уже имеющиеся высокопроизводительные библиотеки.
4. Rust ориентирован на разработку кросс-платформенных приложений. Компилятор официально поддерживается на платформах Windows, Linux и Mac OS X, при этом существуют порты на другие *NIX платформы, такие как FreeBSD. Также поддерживается и несколько архитектур процессоров: i386, x64 и ARM.
5. Rust позволяет писать в разных стилях: объектно-ориентированном, функциональном, actor-based, императивном.
6. Rust поддерживает уже существующие отладочные инструменты: GDB, Valgrind, Instruments.

Скоро первое сентября. Кто-то собирается в школу, кто-то — в институт. А мы предлагаем начать новые проекты с компилятором clang, который теперь поддерживает OpenMP!

Проект доступен здесь. Сейчас в его основе лежит clang 3.3. Небыстрый процесс ревью уже идет, и скоро код будет залит в транк clang'а, а значит войдет в его новые релизы.

Реализована полная поддержка стандарта OpenMP версии 3.1. Успешно проходятся следующие тесты: набор для валидации OpenMP от OpenUH Research Compiler, SPEC OMP2012 и внутренние тесты Intel. Исполняемый код c OpenMP, собранный clang'ом, демонстрирует производительность, сравнимую с другими компиляторами, поддерживающими OpenMP.
В качестве библиотеки времени выполнения использована библиотека Intel OpenMP Runtime Library, также доступная под свободной лицензией.

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

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

В предыдущей серии

После первой части остались два вопроса:

1. Делает ли GIL array << nil атомарной операцией?
2. Делает ли GIL код на Ruby потокобезопасным?

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

Пять из четырех разработчиков признают, что многопоточное программирование понять непросто.

Большую часть времени, что я провел в Ruby-сообществе, печально известная GIL оставалась для меня темной лошадкой. В этой статье я расскажу о том, как наконец познакомился с GIL поближе.

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

Я хотел знать, как работает GIL с технической точки зрения. На GIL нет ни спецификации, ни документации. По сути, это особенность MRI (Matz's Ruby Implementation). Команда разработчиков MRI ничего не говорит по поводу того, как GIL работает и что гарантирует.

Впрочем, я забегаю вперед.

Оригинальный pdf (на английском)
Переведённый pdf (на русском)

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

Было:

class Service {
  public void longJob(Object arg) {...}
}
...
Service s=new Service();
...

s.longJob(arg);

Стало:

class Service {
  public void longJob(Object arg) {...}
}
class ServiceWrapper extends Service {
...
}
...
Service s=new ServiceWrapper() ;
...

s.longJob(arg);

JRE позволяет абстрагироваться от конкретной платформы, делая написание кросс-платформенного кода намного проще. Конечно до идеала Write once, run anywhere не дотягивает, но жизнь облегчает существенно.

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

Подавляющее большинство современных процессоров имеют кэш-память для хранения часто используемых данных. Кэш-память делится на блоки (Сache line). Механизмы реализующие Cache coherence обеспечивают синхронизацию кэш-памяти между ядрами процессора(ов) в компьютерной системе.

Термин false sharing означает доступ к разным объектам в программе, разделяющим один и тот же блок кэш-памяти. False sharing в многопотоковом приложении, когда в одном блоке оказываются переменные модифицируемые из разных потоков, ведет к снижению производительности и увеличению нагрузки на Cache coherence механизмы. Подробно о том как это происходит, можно прочесть в статье на эту тему.

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

Обработка завершилась с ошибкой, что делать дальше? Вполне возможно, что потеряна связь с одним из узлов кластера или временно недоступна база данных. В этом случае, нельзя с уверенностью сказать, какие операции выполнились успешно, а какие — нет. Если все операции в цепочке повторно применимы (идемпотентны), например установка флага, то можно просто перезапустить обработку. Если нет, то на помощь приходят механизмы транзакций Storm.

В первой части рассматривались базовые понятия Storm.

Разные классы задач предъявляют различные требования к надежности. Одно дело пропустить пару записей при подсчете статистики посещений, где счет идет на сотни тысяч и особая точность не нужна. И совсем другое — потерять, например, информацию о платеже клиента.

Далее рассмотрим о механизмы защиты от потери данных, которые реализованы в Storm.

ИМХО (Имею Мнение Хрен Оспоришь)

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

В 2011 году Twitter открыл, под лицензией Eclipse Public License, проект распределенных вычислений Storm. Storm был создан в компании BackType и перешел к Twitter после покупки.

Storm это система ориентированная на распределенную обработку больших потоков данных, аналогичная Apache Hadoop, но в реальном времени.

Ключевые особенности Storm:

• Масштабируемость. Задачи обработки распределяются по узлам кластера и потокам на каждом узле.
• Гарантированная защита от потери данных.
• Простота развертывания и спровождения.
• Восстановление после сбоев. Если какой либо из обработчиков отказывает, задачи переадресуются на другие обработчики.
• Возможность написания компонентов не только на Java. Простой Multilang protocol с использованием JSON объектов. Есть готовые адаптеры для языков Python, Ruby и Fancy.

В первой части рассматриваются базовые понятия и основы создания приложения c использованием Storm версии 0.8.2.

Обычно в таких статьях делают заголовок вида «аналог await/async для C++», а их содержимое сводится к описанию ещё одной библиотеки, выложенной где-то в интернете. Но в данном случае нам не требуется ничего подобного и заголовок точно отражает суть статьи. Почему так смотрите ниже.

Постановка задачи

Один из алгоритмов, который я реализовывал, имел интересные особенности при работе с памятью:

• Могло выделяться огромное количество, до десятков и сотен миллионов небольших объектов одного типа.
• Объекты представляли собой POD- типы.
  
  POD

  A Plain Old Data Structure in C++ is an aggregate class that contains only PODS as members, has no user-defined destructor, no user-defined copy assignment operator, and no nonstatic members of pointer-to-member type.
• Заранее было неизвестно какое количество объектов понадобится, могло так случится, что потребуется сотня, а может и сто миллионов.
• Объекты никогда не удаляются по одному, в какой-то момент они становятся не нужны все сразу.
• Алгоритм хорошо распараллеливается, по этому выделением объектов занимается одновременно несколько потоков, по количеству ядер процессора(ов).

Использование в таких условиях стандартного new – delete приводит к очень большим потерям времени на удаление объектов. Если без отладчика удаление происходило хотя бы за несколько секунд, то в присутствии отладчика освобождение памяти замедляется примерно в 100(!) раз, и отладка проекта становится просто невозможной. Кроме того из-за большого количества выделенных объектов достаточно ощутимым становился перерасход памяти на внутренние данные распределителя памяти.
Для решения задачи выделения огромного количества объектов одного типа, и их пакетного удаления, был сделан lock-free контейнер MassAllocator. Код компилируется Visual Studio 2012. Полный код проекта выложен на github.