Библиотеки, реализующие стандарт MPI (Message Passing Interface) — наиболее популярный механизм организации вычислений на кластере. MPI позволяет передавать сообщения между узлами (серверами), но никто не мешает запускать несколько MPI процессов и на одном узле, реализуя потенциал нескольких ядер. Так часто и пишутся HPC приложения, так проще. И пока количество ядер на одном узле было мало, никаких проблем с «чистым MPI» подходом не было. Но сегодня количество ядер идёт на десятки, а то и на сотни для со-процессоров Intel Xeon-Phi. И в такой ситуации запуск десятков процессов на одной машине становится не совсем эффективным.

Дело в том, что MPI процессы общаются через сетевой интерфейс (хоть и реализованный через общую память на одной машине). Это влечет за собой избыточные копирования данных через множество буферов и увеличенный расход памяти.

Для параллельных вычислений внутри одной машины с общей памятью гораздо лучше подходят потоки и распределение задач между ними. Здесь наибольшей популярностью в мире HPC пользуется стандарт OpenMP.

Казалось бы – ладно, используем OpenMP внутри узла, и MPI для меж-узловых коммуникаций. Но не всё так просто. Использование двух фреймворков (MPI и OpenMP) вместо одного не только несёт дополнительную сложность программирования, но и не всегда даёт желаемый прирост производительности – по крайней мере, не сразу. Нужно ещё решить, как распределить вычисления между MPI и OpenMP, и, возможно, решить проблемы, специфичные для каждого уровня.

В этой статье я не буду описывать создание гибридных приложений – информацию найти не сложно. Мы рассмотрим, как можно анализировать гибридные приложения с помощью инструментов Intel Parallel Studio, выбирая оптимальную конфигурацию и устраняя узкие места на разных уровнях.

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

Сам термин «Алгоритмическая торговля» сейчас настолько на слуху, что некоторые нерадивые авторы пользуются этим и втискивают его в название своих книг, чтобы привлечь читательское внимание.

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

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

Предыстория

Хотелось создать своего робота, а так же автоматизировать управление светом и климатом дома. С этой целью начал изучать имеющиеся возможности. Для себя я разделил все решения на две группы: системы в которых код на контроллере выполняется в одном главном цикле (arduino, lego и т.п.) и системы состоящие из параллельно работающих процессов обменивающихся между собой сообщениями.
Интуитивно выбрал вторую группу, так как хотелось найти максимально простое решение с дружественным пользовательским интерфейсом. Из наиболее популярных представителей этого «семейства» очень понравились Microsoft Robotics Studio и ROS. Но к сожалению, на текущий момент, привязать их к конкретному железу весьма не просто, да и разобраться в них с нуля так же весьма не тривиальная задача. В итоге принял решение писать сам, но «кодить» на C очень не хотелось, Душа просила чего-нибудь попроще и полегче. В итоге выбрал Python. А учитывая, что по мимо робота и «умного дома» в голову начало лезть куча других идей, то решил сразу сделать небольшой фреймворк, в котором основной упор был бы сделан на простоту разработки.

Концепция

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



Сеть процессов строится на базе стандартного Python модуля multiprocessing. Система обмена сообщениями и разделяемая память реализованы при помощи Redis.

Каждый Bubot имеет встроенный веб-сервер веб-сервер Tornado, который позволяет контролировать состояние, управлять роботом, на ходу менять параметры (калибровать) робота, а также закладывается возможность обмена данными между роботами.
Bubot не является системой реального времени, хотя Bubot возможно интегрировать с кодом реального времени.

Привет. Меня зовут Степан Кольцов. Недавно я выступал на Java Party в киевском офисе Яндекса с докладом про язык Rust, который несёт в себе очень много для будущего программирования. Некоторые коллеги утверждают, что я всегда говорю про Rust, когда у меня есть такая возможность. Сегодня я хочу поделиться этим рассказом с вами и объяснить, почему мне это кажется важным.



Для начала пара слов о том, что такое Rust. Последние 15 лет между разработчиками на Java и на C++ ведётся спор о том, какой язык программирования хуже — Java или C++. Программы на C++ глючат, падают, и в них утекает память. Программы на Java тормозят и требуют слишком много памяти.

Rust — новый современный язык программирования, разрабатываемый компанией Mozilla — решает проблемы Java и C++: программы, написанные на Rust, одновременно быстрые и безопасные. Rust является таким же низкоуровневым (в смысле close-to-metal) языком программирования, как и C++, однако в язык встроены конструкции, позволяющие на этапе компиляции доказывать, что в программе не случатся ошибки работы с памятью, как то обращение после использования, двойное удаление, использование неинициализированной памяти и т.п. В Rust для этого используется механизм borrowed pointers. Большая часть моего рассказа была посвящена описанию этого механизма.

Полтора месяца назад я рассказывал о том, как Бен Краснов (Ben Krasnow) собрал самодельный рентгеновский сканер. Бен не прекратил свои эксперименты с рентгеном и теперь представляет полноценный компьютерный томограф (авторское описание).

Пример работы томографа показан ниже. Сможете угадать, что (или кто) это?

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

В результате стандартный консервативный аллокатор выстраивает все запросы в очередь на pthread_mutex / critical section. И наш многоядерный процессор медленно и печально едет на первой передаче.

И что с этим делать? Познакомимся поближе с деталями реализации метода Scalable Lock-Free Dynamic Memory Allocation. Maged M. Michael. IBM Thomas J. Watson Research Center.

Самый простой код что я сумел найти — написан под LGPL камрадами Scott Schneider и Christos Antonopoulos. Его и рассмотрим.