Приветствую Хабр!

Наша команда FlyElephant продолжает проведение вебинаров и я хочу пригласить всех 28 сентября в 17.00 на вебинар, на котором мы рассмотрим основы распараллеливания С/С++ программ при помощи OpenMP, познакомимся с функционалом FlyElephant и освоим на примерах принципы работы с платформой. Поговорим о программе бета-тестирования и новом функционале, который будет доступен в ближайшее время.

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

Зарегистрироваться на вебинар можно здесь.

Недавно вышло большое обновление Intel® Parallel Studio XE 2016, и вместе с ним Intel® Threading Building Blocks 4.4. В новой версии появилось несколько интересных дополнений:

• Глобальный контроль для управления ресурсами, в первую очередь, количеством рабочих потоков.
• Новые типы узлов Flow Graph: composite_node и async_node. Кроме того, во Flow Graph была улучшена функциональность сброса (reset).
• Больше фишек из С++11 для лучшей производительности.

Тихо и незаметно (с), вышел Python версии 3.5! И, безусловно, одно из самых интересных нововведений релиза является новый синтаксис определения сопрограмм с помощью ключевых слов async/await, далее в статье об этом.

Поверхностный просмотр «PEP 0492 — Coroutines with async and await syntax» поначалу оставил у меня вопрос «Зачем это надо». Сопрограммы удовлетворительно реализуются на расширенных генераторах и на первый взгляд может показаться, что все свелось к замене yield from на await, а декоратора, создающего сопрограмму на async. Сюда можно добавить и возникающее ощущение, что все это сделано исключительно для использования с модулем asyncio.

Но это, конечно же, не так, тема глубже и интереснее.

Предисловие

Данная статья выросла из проблемы, которую мне относительно недавно пришлось решить: скорость кода, предназначенного для работы одновременно в нескольких потоках, резко упала после очередного расширения функционала, но только на Windows XP/2003. С помощью Process Explorer я выяснил, что в большинство моментов времени исполняется только 1 поток, остальные находятся в ожидании, причём TID активного потока постоянно меняется. На лицо явная конкуренция за ресурс, и этим ресурсом оказалась куча по умолчанию (default heap). Новый код активно использует динамическое выделение/высвобождение памяти (копирование строк, копирование/модификация STL контейнеров большого размера), что собственно и привело к возникновению данной проблемы.

Немного теории

Как известно, аллокатор по умолчанию (default allocator) для STL контейнеров и std::basic_string (std::allocator) выделяет память из кучи по умолчанию, а операции выделения/высвобождения памяти в ней являются блокирующими (косвенное подтверждение). Исходя из этого, при частых вызовах HeapAlloc/HeapFree мы рискуем намертво заблокировать кучу для других потоков. Собственно это и произошло в моём случае.

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

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

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

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

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

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

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

Это может быть сделано несколькими способами, но мы будем говорить только о двух из них: хэндлы (handles) и встроенные счётчики ссылок (intrusive reference counters).

Добрый день, уважаемые хабровчане.

Сегодня я хотел бы поговорить о таких нетривиальных вещах, как асинхронные (параллельные) расчеты в языке PHP.
Сам по себе PHP — это скриптовый язык, который никогда и не претендовал на многопоточность. Но чем дальше в лес, тем более серьезные задачи стоят перед разработчиками, и тем больше приходится «извращаться» с пыхом, потому что мигрировать на более приспособленный под эти задачи язык программирования многие компании попросту боятся и не хотят. Следовательно, приходится работать с тем, что дают.
Подробности под катом…

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

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

Сегодня мы хотели поговорить с вами на тему «все новое — это хорошо забытое старое» и вспомнить об акторах, описанных Карлом Хьюиттом еще в начале 70-х. А все дело в том, что недавно вышла вот такая книга:



Она довольно объемная — в переводе должна получиться более 500 страниц.

Несмотря на подчеркнутую элитарность книги (Akka и Scala), ее автор Вон Вернон (крупнейший специалист по DDD) уверен, что архитектурные паттерны, описанные в этой работе, вполне реализуемы на .NET и C#, о чем рассказывает в приложении. Мы же размещаем под катом перевод статьи, автор которой допускает перенос акторной парадигмы на язык Java. Поскольку рейтинг книги на Amazon стабильно высок, а тема универсальна, просим поделиться вашими мнениями как о ней, так и об акторной архитектуре в принципе.

Приветствую Хабр!
Пока наша команда разработчиков активно трудится над новым релизом FlyElephant, я решил устроить вебинар. На нем я расскажу об истории создания проекта, о функционале, который уже доступен и который появится в ближайшее время. Познакомлю с нашей программой бета-тестирования, а также продемонстрирую работу сервиса. В конце вебинара с радостью отвечу на все вопросы.
Приглашаю на него всех, кто связан с научными и высокопроизводительными вычислениями. Вебинар состоится 13 августа в 16.00. Регистрация на него здесь.

Если бы это была запись для твиттера, то она была бы следующей: «Программисты на Caché ObjectScript! Используйте $Sequence вместо $Increment для генерации Id». Но тут Хабр, поэтому придётся развернуть мысль – добро пожаловать под кат.

В прошлой статье было описано знакомство с сопроцессором Intel Xeon Phi используя offload – основной код работает на хосте, а отдельные блоки выгружаются на сопроцессор. В данной заметке рассмотрим компиляцию и использование «родного» кода, с целью выяснить, что это дает и чем грозит. В завершении поста будут четыре предложения касательно использования Fortran и примеры программ.

От переводчика: Джефф Прешинг (Jeff Preshing) — канадский разработчик программного обеспечения, последние 12 лет работающий в Ubisoft Montreal. Он приложил руку к созданию таких известных франшиз как Rainbow Six, Child of Light и Assassin’s Creed. У себя в блоге он часто пишет об интересных аспектах параллельного программирования, особенно применительно к Game Dev. Сегодня я бы хотел представить на суд общественности перевод одной из статей Джеффа.

Поток должен ждать. Ждать до тех пор, пока не удастся получить эксклюзивный доступ к ресурсу или пока не появятся задачи для исполнения. Один из механизмов ожидания, при котором поток не ставится на исполнение планировщиком ядра ОС, реализуется при помощи семафора.

Раньше я думал, что семафоры давно устарели. В 1960‑х, когда еще мало кто писал многопоточные программы, или любые другие программы, Эдсгер Дейкстра предложил идею нового механизма синхронизации — семафор. Я знал, что при помощи семафоров можно вести учет числа доступных ресурсов или создать неуклюжий аналог мьютекса, но этим, как я считал, область их применения ограничивается.

О чем речь

В данном посте я бы хотел описать часть системы времени выполнения (RTS — RunTime System в дальнейшем) компилятора DVMH. Рассматриваемая часть, как видно из заголовка, относится к обработке пользовательских массивов на GPU, а именно, их автоматическая трансформация или реорганизация в памяти ускорителя. Данные преобразования делаются для эффективного доступа к памяти GPU в вычислительных циклах. Что такое DVMH, как можно подстраиваться под вычисления и почему это делается автоматически — описано далее.

Желание познакомиться с сопроцессором Xeon Phi возникло давно, но то все не было возможности, то времени. В конце концов чудо свершилось и добрался до предмета вожделения. К сожалению, в руки попала далеко не самая последняя модель – 5110P, но для первого знакомства сойдет. Имея опыт работы с CUDA, меня очень интересовал вопрос отличий между программированием для GPU и сопроцессора. Вторым вопросом был: «А что (кроме дополнительной головной боли) я буду иметь используя сей девайс вместо GPU или CPU?».

Введение

Решение задачи поиска минимальных остовных деревьев ( MST — minimum spanning tree) является распространенной задачей в различных областях исследований: распознавание различных объектов, компьютерное зрение, анализ и построение сетей (например, телефонных, электрических, компьютерных, дорожных и т.д.), химия и биология и многие другие. Существует по крайней мере три известных алгоритма, решающих данную задачу: Борувки, Крускала и Прима. Обработка больших графов (занимающих несколько ГБ) является достаточно трудоемкой задачей для центрального процессора (CPU) и является востребованной в данное время. Все более широкое распространение получают графические ускорители (GPU), способные показывать намного большую производительность, чем CPU. Но задача MST, как и многие задачи по обработке графов, плохо ложатся на архитектуру GPU. В данной статье будет рассмотрена реализация данного алгоритма на GPU. Также будет показано, как можно использовать CPU для построения гибридной реализации данного алгоритма на общей памяти одного узла (состоящего из GPU и нескольких CPU).

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

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

1. Именуйте критические секции

В очередь, сукины дети, в очередь! //М. А. Булгаков «Собачье сердце»

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

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

Этой обзорной статьёй я открываю серию статей, посвящённых языку Активный Оберон и операционной системе A2, написанной на этом языке.

Итак, встречайте — Активный Оберон

Первая публикация по Активному Оберону появилась в 1997 году, но понятно, что язык и его реализация появились несколько раньше. За эти годы произошло много изменений в языке, переработана среда времени выполнения, написана операционная система A2…

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

Для процессоров, работающих с векторами, накладные расходы ниже. Количество циклов уменьшается в N раз, где N — количество одновременно обрабатываемых элементов массива. Однако, проблему это не снимает. Да ещё добавим расходы на границу массива, если число элементов не укладывается целое число раз в вектор процессора.

Мы недавно уже писали о новом Vectorization Advisor. О том, что это такое и зачем нужно, читайте в первой статье. Этот же пост посвящён разбору конкретного примера оптимизации приложения с помощью этого инструмента.

Приложение взято из примеров библиотеки Intel Threading Building Blocks (Intel TBB). Оно рисует фрактал Мандельброта и распараллелено по потокам с помощью Intel TBB. Т.е. преимущества многоядерного процессора оно использует — посмотрим, как обстоят дела с векторными инструкциями.