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

Здравствуйте, уважаемые читатели.

Хочу написать здесь об одном из своих проектов -- языке Planning C (v2.0). Он является расширением C++, дополняющим базовый язык рядом новых конструкций. В настоящее время проект доступен в репозитории (исходный код прототипного транслятора-препроцессора, множество примеров, конвертер простых программ MPI->Planning C). От других языков Planning C отличается тем, что многие его новые конструкции построены на базе так называемых процедур с планированием повторного входа, которые в первую очередь удобны для программирования некоторых алгоритмов, использующих стек, дек или очередь (но могут использоваться и для программирования произвольных алгоритмов). Язык содержит различные средства алгоритмизации и распараллеливания, более-менее унифицированные и для обычных в наше время компьютеров с многоядерными процессорами, и для видеокарт, и для кластерных систем. Во второй версии языка были введены стандартные средства расширения языка новыми конструкциями, «интеллектуальная» мемоизация и еще некоторые возможности. Надеюсь, кому-нибудь данный язык покажется интересным, может быть даже перспективным для применения и/или развития. Сам я иногда им пользуюсь для быстрого написания некоторых расчетных параллельных программ.

В этой статье напишу лишь о самых базовых возможностях языка, преимущественно на примерах. Если тема вызовет интерес, то, возможно, впоследствии напишу еще одну-две статьи о «продвинутых»/необычных возможностях.

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

 Возможности и ограничения

Требуется видеокарта NVidia с computational capability > 2.2. Программа основана на численном интегрировании уравнений движения скоростным алгоритмом Верле. Опции:

+ периодические граничные условия и только в форме прямоугольного параллелепипеда;

+ парные потенциалы: 6 обычных и 1 температуро-зависимый;

+ 3 способа учета электростатики: наивный, суммирование по Эвальду и метод Феннеля и Гецельтера;

+ 2 термостата: Нозе-Гувера и излучательный;

+ валентные связи;

+ валентны углы;

+ внешнее электрическое поле с постоянным градиентом;

+ возможность динамического образования/удаления валентных связей (включая водородные) и валентных углов;

Рецепт параллельных вычислений Fork/Join или Map/Reduce:
- разбить задачу на куски;
- посчитать куски по-отдельности;
- склеить вместе.

Неотрицательная сумма (a, b) -> max(0, a + b) неассоциативна и результат зависит от порядка склейки. Она сломает Fork/Join и результат будет некорректен. Магией моноида починить на Java, SQL и Haskell за 5 минут, но

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

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

Если опустить первое и самое главное предубеждение относительно питонячьей многопоточности у большинства программистов — что её не существует из-за GIL, — то остается другое, и, наверное, вполне достоверное: что многопоточность — это сложно, и нам этого, пожалуйста, не надо. И знаете что? Так оно и есть. Многопоточность — это сложно, особенно когда выбираешься за пределы стандартных руководств и попадаешь со своей многопоточной поделкой в реальный мир. И, возможно, вам не нужно. Ни здесь, ни далее я не буду обсуждать целесообразность написания многопоточного кода на Python и сразу перейду к тому, как это делать.

Когда я предложил перевести на русский мою последнюю статью Easy Concurrency with Python Shared Objects на английском, поступило предложение "написать в несколько раз короче и понятнее". Просьба более чем обоснована. Поскольку я уже порядка десяти лет пишу многопоточку и БД, то описываемые мной логические связи выглядели самоочевидно, и я ошибочно расчитывал на аудиторию из трех с половиной человек, которые сидят сейчас где-то в яндексе или гугле. Судя по всему, они там и сидят, но тема им не интересна, поскольку в питоне нет настоящих потоков, а значит для этих людей такого языка программирования не существует. Потому я немножко снижаю планку и делаю общий обзор проблематики параллельных вычислений для людей, которые в них разбираются, но не являются экспертами в области.

Из-за чего весь сыр-бор?

Здравствуйте, меня зовут Дмитрий Карловский. А вы на канале Core Dump, где мы берём различные темы из компьютерной науки и раскладываем их по полочкам.

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

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

MPIRE комбинирует функции, подобные map из multiprocessing.Pool, с преимуществами копирования при записи общих объектов multiprocessing.Process. В пакете также есть простые в работе функции состояния рабочего процесса, информирования о нём и индикатора выполнения. Сокращённым переводом документации делимся к старту курса по Fullstack-разработке на Python.

Давным давно уже уже была написана статья о том что такое GVL (или GIL, кому как привычнее) и как он работает, однако с того времени некоторые вещи поменялись (к примеру, , а так же в Ruby 3.0 завезли Ractor'ы - новую абстракцию для реальной параллельной работы тредов. Мне стало интересно узнать что поменялось в планировщике ruby для реализации множества GVL. В этой статье я попытаюсь понять алгоритм, по которому GVL передается от одного треда к другому, как блокирующее IO позволяет продолжить работать другим тредам, а так же выяснить до сих пор ли операция добавления элемента в массив является атомарной операцией

Через неделю будет выставка ChipEXPO, на которой для начинающих будет школа проектирования железа с упражнениями на FPGA платах, а для более продвинутых - конференция Микроархитектура, верификация и физическое проектирование микросхем.

И на части для школьников, и на части для взрослых будут выступать проектировщики RISC-V процессора из Syntacore / Yadro Станислав Жельнио и Никита Поляков. Сегодня Коммерсант сравнил этот проект с полетом на Луну.

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

Далее мы расскажем про новые упражнения в школе этого года - распознавание и генерацию музыки с помощью FPGA и приведем забавные сведения из советской физматшкольной книжки 1963 года как Бах изменил гаммы.

В конце поста мы покажем, как эта деятельность поможет получить в будущем интересные и высокооплачиваемые работы в Apple, Intel, SpaceX, как и самом в модном в этом сезоне российском микроэлектронном проекте - Syntacore / Yadro (в конце поста скриншоты их объявлений).

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

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

• Конференция объединяет IT-индустрию и академический мир: среди спикеров есть и авторы научных статей, и те, у кого результаты этих статей используются в продакшне.
• В этот раз, кроме докладов, в программе три продолжительных воркшопа. Так что будут не только рассуждения со слайдами, но и наглядная практическая работа.
• В программе есть и про distributed, и про concurrency, но перевес в сторону распределённого. Зато все воркшопы актуальны для тех, кто ближе к параллельному программированию.
• Конференция в целом англоязычная, на русском будет только один доклад.
• Такая конференция неизбежно хардкорная, но несколько докладов будут в формате «введения» и не требуют предварительной подготовки. Впрочем, немногие готовы вникать в эти темы даже на поверхностном уровне. Так что это, скажем так, «введение в хардкор»!

Как при распараллеливании кода не мучиться из-за блокировок? На Хабре уже писали о транзакционной памяти, но когда о ней говорит Морис Херлихи, это особый случай. В 1993-м и Хабра никакого не было, и многоядерные процессоры ещё не заявили о себе — а Морис уже стал соавтором основополагающей работы о транзакционной памяти. Так что он главный в мире авторитет по этому вопросу, и если вам нужно введение в тему, логично слушать его.

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

Мы уже третий год проводим конференцию о параллельных и распределённых вычислениях. Hydra 2021 пройдёт в онлайне, и вот что интересно: онлайн-конференция ведь и сама является распределённой системой. У неё есть множество компонентов (это и люди, и оборудование), разбросанных по планете и действующих параллельно (у конференции сразу несколько треков).

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

Например, «избыточность» — это не только когда реплики данных пишутся в три дата-центра. Это ещё и когда у конференции есть одновременно спикеры, эксперты и ведущие. Такая схема с тремя ролями означает, что если связь с кем-то временно пропадёт, двое других заполнят паузу в эфире, не оставляя зрителей наедине с пустотой.

В общем, от «Гидры» можно ожидать неплохой отказоустойчивости (подробнее можно почитать здесь). А чего ещё ждать? Расписали под катом — и заодно приложили ссылку на доклады предыдущей Hydra.

Близится новый JPoint, и мы готовы подробно рассказать о его программе. В этом посте мы разделили доклады по тематическим блокам: можно и быстро понять «что вообще будет», и узнать конкретику. А во вступлении упомянем отдельные моменты:

• Пришла весна, то есть самое время поговорить о Spring. О нём будет четыре доклада, в том числе большое двухчастное выступление Евгения Борисова. Для него мы даже продлили JPoint на пятый день — получился специальный «день Борисова» :)
• Онлайн-формату подходят воркшопы. Поэтому в отдельных случаях можно будет не просто любоваться слайдами: спикер будет выполнять конкретные задачи на практике, объясняя всё происходящее и отвечая на вопросы зрителей.
• Есть доклады не строго про Java, а про то, как успешно разрабатывать «на длинной дистанции» (чтобы всё радовало не только на стадии прототипа, а годы спустя): как делать проекты поддерживаемыми, не плодить «велосипеды», работать с легаси.
• Ну и никуда не девается привычное. Знакомые темы: «что у Java внутри», тулинг/фреймворки, языковые фичи, JVM-языки. Спикеры, посвятившие теме годы жизни: от технического лида Project Loom Рона Пресслера до главного Spring-адвоката Джоша Лонга. Возможность как следует расспросить спикера после доклада. И уточки для «отладки методом утёнка»!

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

В основном используют 2 типа оптимизации, либо их смесь: Векторизация и распараллеливание вычислений. Чем же они отличаются?

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

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

Далее вы узнаете, что такое параллелизация и как пользоваться MPI на практике.

Реактивное программирование — один из самых актуальных трендов современности. Обучение ему — сложный процесс, особенно если нет подходящих материалов. В качестве своеобразного дайджеста может выступить эта статья. На конференции РИТ++ 2020 эксперт и тренер Luxoft Training Владимир Сонькин рассказал о фишках управления асинхронными потоками данных и подходах к ним, а также показал на примерах, в каких ситуациях нужна реактивность, и что она может дать.

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