Неэффективный доступ к памяти, пожалуй, одна из наиболее частых проблем производительности программ. Скорость загрузки данных из памяти традиционно отстаёт от скорости их обработки процессором. Для уменьшения времени доступа к данным в современных процессорах реализуются специальные блоки и многоуровневые системы кэшей, позволяющие сократить время простоя процессора при загрузке данных, однако, в некоторых случаях, процессорная логика работает не эффективно. В этом посте поговорим о том, как можно исследовать работу с памятью вашего приложения с помощью нового профиля Memory Access в VTune Amplifier XE.

Мы уже писали про Vectorization Advisor и примеры его применения на простых сэмплах. Сегодня поделимся информацией том, как инженеры Intel совместно с исследователями из STFC Daresbury Laboratory в Великобритании оптимизировали пакет DL_MESO.



DL_MESO – научный пакет для симуляции конденсированных сред на мезоскопическом уровне (да простят меня химики и физики, если не совсем корректно перевёл). Пакет разработан в лаборатории Дарсбери и широко применяется как в исследовательском сообществе, так и в индустрии (компаниями Unilever, Syngenta, Infineum). С помощью этого ПО ищутся оптимальные формулы для шампуней, удобрений и топливных присадок. Этот процесс называют “Computer Aided Formulation” (CAF) – я перевёл как «САПР в области разработки химических формул».

Симуляция CAF – очень ресурсоёмкие вычисления, поэтому разработчики были сразу заинтересованы в максимально производительном дизайне. И DL_MESO был выбран одним из совместных проектов в “Intel Parallel Computing Center” (IPCC) между Intel и Hartree.
Разработчики DL_MESO хотели воспользоваться аппаратными возможностями векторного параллелизма, ведь грядущие технологии вроде AVX-512 потенциально могут сделать код в 8 раз быстрее на числах с двойной точностью (по сравнению с не векторизованным кодом).

В этом посте мы расскажем, как учёные из Дарсбери использовали Vectorization Advisor для анализа кода Lattice Boltzmann Equation в DL_MESO, какие конкретно проблемы они нашли, и как исправили свой код, чтобы разогнать его в 2.5 раза.

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

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

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

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

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

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

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

Многим нравится представление структуры программы в виде call graph, «графа вызовов функций». Особенно интересно, если этот граф отражает профиль производительности, наиболее «горячие» ветки кода.

Граф вызовов можно получить с помощью Intel VTune Amplifier XE, но для этого нам понадобится ещё пара утилит.

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

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

Большое обновление пакета Intel® Parallel Studio XE вышло на этой неделе. Версия 2016 включает три совершенно новых продукта:

1. Intel® Data Analytics Acceleration Library (Intel® DAAL) – C++ и Java решение для аналитики данных (статистика, машинное обучение и другое).
2. Новый Vectorization Advisor в составе Intel® Advisor XE 2016 Beta для оптимизации кода под SIMD инструкции, т.е. векторизации.
3. MPI Performance Snapshot для быстрой общей оценки производительности MPI программ.

Бета-версия доступна публично и бесплатно, программа длится до 23 июня, но лицензии будут работать вплоть до 25 сентября 2015 г. Для получения Бета-версии нужно зарегистрироваться здесь.
Эта статья посвящена обзору нового функционала, более детально отдельные продукты постараемся осветить в последующих блогах – пишите в комментариях, к чему есть интерес.

OpenMP* — довольно популярная модель параллельного программирования, особенно для высокопроизводительных вычислений. Но чтобы этой высокой производительности достичь, OpenMP конструкции частенько приходится «настраивать». И здесь не обойтись без хорошего профилировщика. Большинство профилировщиков выдают данные о производительности, ассоциированные с функциями или циклами, но не дают картины по конкретным OpenMP регионам. В результате программист теряет контекст. А без OpenMP-контекста диагностика дисбалансов или накладных расходов становится весьма затруднительной.
Intel VTune Amplifier XE умеет профилировать OpenMP регионы. Свежая версия 2015 Update 2 делает анализ гораздо более простым и понятным, благодаря представлению данных в «OpenMP терминах». Инструмент показывает время параллельных и последовательных регионов, разницу между фактическим и идеализированным временем исполнения региона, разбивку по параллельным циклам и загрузку ЦПУ по каждому региону в отдельности.
Пользователь может легче понять, куда вкладывать усилия в первую очередь, благодаря метрике «potential gain». Классификация накладных расходов помогает определить причину неэффективности – например, ожидание из-за дисбаланса нагрузки или на «замке» из-за синхронизации.
Статья описывает некоторые типы OpenMP проблем, определяемых VTune Amplifier, как их нужно понимать и устранять.

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

Распараллеливают вычисления на OpenMP ради производительности, о чём, собственно, и статья. Точнее, об измерении производительности с помощью Intel VTune Amplifier XE. А именно, как получить информацию о:

• Получении профиля всего OpenMP приложения
• Профиле отдельных параллельных регионов OpenMP (время CPU, горячие функции и т.д.)
• Балансе работы внутри отдельного параллельного региона OpenMP
• Балансе параллельного/последовательного кода
• Уровне гранулярности параллельных задач
• Объектах синхронизации, времени ожидания и передачах управления между потоками

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

VTune Amplifier XE давно известен пользователям своими возможностями глубокого анализа производительности ПО, как на уровне приложения, так и на микроархитектурном уровне.

Инструмент не стоит на месте и активно развивается, улучшаясь и обрастая новым функционалом. В этом посте приведён краткий обзор новых «фич», появившихся как в вышедшем в сентябре VTune Amplifier XE 2013, так и совсем недавно, в последующих обновлениях:

• Анализ циклов
• Текстовый поиск
• Анализ энергоэффективности
• EBS анализ со стеками
• Профилировка Java приложений
• API для пользовательских задач
• Улучшения командного интерфейса

Есть приложения, которые хорошо реализуются как системы передачи сообщений. Сообщениями в широком смысле может быть что угодно – блоки данных, управляющие «сигналы» и т.д. Логика же состоит из узлов, обрабатывающих сообщения, и связей между ними. Такая структура естественно представляется графом, по рёбрам которого «текут» сообщения, обрабатываемые в узлах. Наиболее устоявшееся название такой модели – вычислительный граф.

С помощью вычислительного графа можно установить зависимости между задачами и в какой-то мере программно реализовать «dataflow архитектуру».

В этом посте я опишу, как реализовать такую модель на С++, используя библиотеку Intel Threading Building Blocks (Intel TBB), а именно класс tbb::flow::graph.

Тестирование и поиск ошибок – неотъемлемая и не самая интересная часть процесса разработки ПО. Для избавления себя от рутины этот процесс все стараются автоматизировать. И если для проверки функционала приложения создаются специализированные самодельные тесты, то поиск ошибок общего типа далеко не всегда ими покрывается. Проверяется ли, например, ваше приложение на наличие утечек памяти или гонок данных? В этой статье рассмотрим, как использовать обновлённый Inspector XE 2013 в двух ипостасях:

• Для регулярного автоматического тестирования (regression testing)
• Для ручного поиска причин проблемы в паре с отладчиком

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

Новый инструмент Intel Advisor XE поможет вам распараллелить приложение, потратив на это минимум сил и времени.

Advisor XE вышел в свет в сентябре этого года в составе пакета для разработчиков Intel Parallel Studio XE 2013. Дословный перевод названия – «советчик» — довольно ёмко описывает его предназначение. Инструмент помогает программисту проанализировать возможности распараллеливания кода: найти наиболее подходящие для этого участки и оценить предполагаемый полезный эффект – а стоит ли вообще за это браться? Кроме того, Advisor XE подскажет, где могут возникнуть ошибки, такие как гонки данных. И всё этого без реальной модификации программы! Но обо всём по порядку.