OpenMP.ru

Эффективная параллелизация с учетом NUMA

by on Авг.23, 2015, under Новости

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

(continue reading…)

Leave a Comment more...

Shared или private, три простых правила

by on Ноя.16, 2014, under Распараллеливание

В Openmp параллелизация подкупает своей простотой. Добавил прагму к циклу и хоп — я знаю кунг-фу. Тем не менее такое отношение частенько приводит к разнообразным ошибкам обращения к одной и той же переменной.
В OpenMP есть два основных класса переменных — shared и private. Shared переменная общая между потоками, хранится в обычной памяти процесса (стек или хип) и ничего не стоит. Private переменная для каждого OpenMP потока своя и хранится в TLS — специальном месте, уникальном для каждого потока (thread), есть дополнительные расходы на копирование.
Как их отличать между собой.
1. По умолчанию все переменные внутри parallel секции считаются shared за исключением п.2.
2. Все локальные переменные (объявленные внутри parallel секции) и итераторы будут private.
3. Все нелокальные переменные (объявленные ранее parallel) в которые что-то пишется (lvalue) должны быть явно указаны как private.
(continue reading…)

Leave a Comment more...

Когда shared переменная внезапно становится private

by on Дек.25, 2013, under Распараллеливание

Был замечен сайд-эффект от типов хранилища переменных.

По умолчанию считается что все переменные в OpenMP секции являются shared. Допустим мы явно объявляем какой то int как shared:
(continue reading…)

Leave a Comment more...

Вопросы миграции процессов

by on Сен.27, 2012, under Оптимизация

С точки зрения производительности параллельной программы пиннинг (привязка процесса к ядру процесса) очень важен.

Во первых не прикрепленный (pinned) процесс постоянно вынужден мигрировать по ядрам и даже сокетам, что приводит к частой инвалидации содержимого кэша и как следствие — увеличение количества кэшмиссов. В Numa системах это плохо еще и тем что можно «потерять» свою память.

Как правило Linux имеет некую стандартную политику распределения процессов по ядрам. Обычно она выглядит так: есть несколько процессов. Мы начинаем раскладывать с 0-го ядра в системе (см /proc/cpuinfo — нумерация ядер в системе будет аналогична), следующий процесс будет занимать другой пакет и другой сокет. Т.е. происходит неявное чередование (очевидно для размазывания загрузки по разным _физически_ процессорам).

Непосредственно для привязки процессов к CPU мы можем использовать:

(continue reading…)

Leave a Comment more...

Тренинг по оптимизации ПО

by on Май.25, 2011, under Оптимизация

В МГУ прошла первая часть тренинга по оптимизации ПО. Пользователи кластеров МГУ (Чебышев и Ломоносов) приносили свои исходные коды, а инструкторы компании Intel рассказывали об инструментах для оптимизации и на живом примере показывали как они работают.

http://msu-intel.parallel.ru/?q=node/81

Работа была построена скорее как практика, на которой обучаемые с помощью подсказок инструктора находили узкие места своих программ.
Первая часть была посвящена MPI-ной производительности и оптимизации с помощью Intel Trace Collector/Analyzer.
Во второй части внимание было уделено производительности последовательных частей кода. На IPTU собирался профиль и дальнейший анализ производился на нем же.

Как показала практика — в коде всегда есть место для оптимизации, результатом тренинга стало ускорение работы научных программ в широком диапазоне — от 4х до 5%.

В конце июня планируется продолжение тренинга в суперкомпьютерном центре МГУ. Если есть заинтересованность — пишите, возможно и для вас найдется место.

Leave a Comment more...

Развитие стандарта MPI

by on Сен.09, 2009, under Новости

Не так давно (4 сентября 2009г) была принята новая версия стандарта MPI-2.2. В основном содержащий косметические изменения по сравнению с предыдущим вариантом (уточнения различных моментов, введение новых типов данных).

Полный вариант стандарта  (и всех предыдущих) в формате pdf можно скачать тут:
http://www.mpi-forum.org/docs/docs.html

Но более интересным представляется MPI-3,  предложения, обсуждаемые комитетом, можно увидеть здесь: http://meetings.mpi-forum.org/MPI_3.0_main_page.php

Для меня наиболее интересным расширением оказались так называемые Persistent Operations, позволяющие закэшировать соединения для коллективной операции и исключить оверхед при повторном использовании.

Leave a Comment more...

Проверка кластерной сети

by on Апр.14, 2009, under Новости, Программы

Одна из основных проблем крупных кластеров — это поддержка работоспособного состояния сетевой системы. Кроме терминального состояния «коннект отпал» возможны так же промежуточные варианты — падения скорости или возникновение задержек. Ситуация усугубляется тем что сложная фабрика может реагировать на битый кабель неочевидно — скорость может упасть в каком-то сегменте, при определенной передаче между определенными нодами. Поэтому иногда стоит устраивать прогоны-тесты сетевой подсистемы с нагрузкой Point-To-Point перебирая все возможные варианты. Это долго, и объемно по анализу, но спокойствие пользователей кластера того стоит.

(continue reading…)

Leave a Comment : more...

Вышел обновленный FFTW-3.2alpha

by on Янв.18, 2009, under Алгоритмы

Наконец-то дождались. Судя по сайту fftw.org казалось автор совершенно забросил свое творение, и тут новая версия. В нем анонсирована поддержка MPI FFT преобразования. Теперь можно потихоньку начинать переезжать с 2.1.5. Поскольку это еще альфа, документации пока нет. Но вообщем то по примерам и хидерам можно понять что к чему. Вместо fftw_mpi_create_plan(…) стало fftw_plan(…), вместо fftw_one(…) стало fftw_exec(…). Немного поменялись параметры функций, внимание: требуется инициализация FFTW после MPI_Init() и финализация в конце программы.

В общем работает быстрее 2.1.5 где-то на 20-30%, точные цифры опубликовать к сожалению не могу.

Leave a Comment more...

Архитектура современных суперкомпьютеров

by on Сен.12, 2008, under Распараллеливание

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

Есть два подхода при построении современных суперкомпьютеров — системы с общей памятью и так называемые кластеры. Каждый подход не исключает другого, у каждого подхода есть свои достоиинства и недостатки. Плюс систем с общей памятью — универсальность модели параллельного ПО, не требующей какого либо дополнительного кода, или не требующей значительных изменений кода. Плюс кластерных систем — отказоустойчивость и более лучшая масштабируемость. Системы с общей памятью плохо масштабируются при росте числа вычислительных процессоров, кластеры же масштабируются плохо из-за возрастающей сложности сети при добавлении узлов, но это происходит значительно позднее, когда число процессоров измеряется сотнями и даже тысячами. Рассмотрим подробнее оба этих подхода
(continue reading…)

4 Comments :, , more...

Обзор способов параллельного программирования

by on Мар.10, 2008, under Распараллеливание

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

  1. Threads / Processes
  2. OpenMP
  3. MPI

Исторически сложилось так, что наиболее часто применяемый способ — это Threads в их различных реинкарнациях. Способ хорош тем что не требует дополнительных библиотек. Чтобы использовать этот вариант, достаточно имеющихся возможностей OC. Обычно используется для скрытия от пользователя различных продолжительных операций, чтобы не терять возможность отрисовки GUI в момент ожидания операции. Основное достоинство — потоки разделяют адресное пространства и принадлежат одному процессу. Поэтому все передачи данных между потоками выполняются максимально быстро. Чаще всего достаточно передать указатель. Синхронизация потоков не затратна и не требует системных вызовов (Syscall) — долгих операций с переключением контекста. Сюда же можно отнести и многопроцессные программы в самом простейшем виде — использующие fork() или что-то подобное из системных функций для порождения нового процесса, но применяющее для синхронизации и обмена данными системное API.
(continue reading…)

5 Comments more...

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!