Пауза — временное молчание, перерыв в звучании музыкального произведения в целом или какой-либо его части или отдельного голоса.
[Википедия]

Удивительно, но иногда так бывает, чтобы что-то сделать в целом быстрее, надо это делать медленнее или вообще с паузами. Например, при имплементации активного ожидания spin-wait в многопотоковом коде рекомендуется использовать инструкцию pause, которая, как утверждает Intel Instruction Set Reference, делает это ожидание наиболее эффективным. «Какая чушь!» — скажете вы. Как может быть ожидание эффективным? Разработчики микропроцессоров утверждают, что при активном ожидании с инструкцией pause чип потребляет намного меньше энегии еще со времен Pentium 4. В чем еще может быть эффективность ожидания? Поговорим об этом ниже.

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

Мы все «немного читали» об оптимизации работы с памятью, и у нас отложилось, что полезно, когда «кэш остается горячим», то есть данные, к которым часто обращаются потоки, должны быть компактными и находиться в ближайшем к процессорному ядру кэше. Все так, но когда дело доходит до того, чтобы делиться доступом, потоки становятся злейшими врагами [производительности], а кэш не просто горячий, он аж «горит адским огнем» – такая во круг него разворачивается борьба.

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

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

Второй тул, к сожалению, не столь широко известнен. Он уже упоминался на Хабре в контексте оптимизации AVX кода, но область его применения несколько шире.

Иногда после того, как Vtune нашел самый главный хотспот (а зачастую, разработчик и так его знает), возникает потребность приложить некоторые усилия для уменьшения числа тактов, которые тратятся на его исполнение. Уже почти три года я использую для анализа производительности таких небольших, но критичных участков кода Intel Architecture Code Analyzer.

Пользоваться им просто, вот рекурсивный алгоритм всего лишь из 6 шагов:
1. В соответствующем .c/.cpp файле включается
#include «iacaMarks.h»,
2. dll/so библиотеки IACA кладутся в доступное системе место,
3. в исходник добавляются макросы
IACA_START, IACA_END
соответственно, перед началом и после окончания оптимизируемого кода. Например,

13 сентября, хоть и не пятница, но все равно отличный день, чтобы представить новую версию уже хорошо известного многим продукта Intel Parallel Studio, имеющую отношение к числу «13» — Parallel Studio XE 2013. В этом сообщении мы расскажем вам кратко о составе и функционале Parallel Studio XE 2013, а также его отличиях от предыдущих версий.

Один из методов улучшения эффективности распараллеливания алгоритмов определенного класса – конвейеризация фаз исполнения, как последовательных, так и параллельных. Библиотека Intel TBB может помочь сократить усилия и время, необходимые на реализацию конвейеризированных алгоритмов, беря на себя заботу об управлении задачами и распределении нагрузки между потоками в системе. Однако, формулирование и формирование задач, составляющих фазы алгоритма, может быть нетривиальной проблемой в зависимости от сложности алгоритма, что в реальных приложениях чаще всего и бывает. Контролировать выполнение задач может оказаться еще сложнее, если сам алгоритм не содержит средства для контроля. Инструментарий анализа вычислительных задач в Intel VTune Amplifier помогает разработчикам представлять структуру исполнения в многопоточной среде в удобном графическом виде, увеличивая эффективность анализа и значительно сокращая время разработки приложений. В данной статье мы рассмотрим простой пример конвейеризированной задачи, и шаг за шагом распараллелим ее, используя конвейерный класс TBB, проанализируем с помощью VTune Amplifier и улучшим производительность реализации на основе результатов анализа.

В этой статье я расскажу о том, как загруженность шины данных влияет на масштабируемость (scalability) приложений. Под масштабируемостью мы будем понимать не только способность многопоточного приложения сокращать свое время выполнения по мере увеличения числа потоков. Мы также добавим сюда и способность однопоточного приложения, запущенного одновременно в несколько копий (instances), выполняться за тот же самый промежуток времени, что и одна копия. Хотя последний пример было бы правильнее охарактеризовать таким свойством как пропускная способность (throughput), так как он относится к «серверному» режиму запуска приложений. Т.е. это такой режим, при котором на сервере запускается однопоточное приложение, каждый раз когда к нему подключается новый клиент. Главная задача при разработке таких приложений — это снижение их зависимости от общих ресурсов, одним из которых может являться шина данных.

В нашем блоге мы много пишем о продуктах и решениях Intel. И те, и другие не стоят на месте – в них исправляются недостатки, добавляется новый функционал. Получается, что через некоторое время информация в блоге устаревает, а новая не появляется – не находится повода. Такое положение кажется нам неправильным; чтобы исправить ситуацию мы решили периодически публиковать дайджесты обновлений – чего нового произошло в той или иной области с момента публикации последнего поста о ней. В советских газетах такой формат назывался «возвращаясь к напечатанному». В этот же дайджест будем добавлять короткие статьи на различные новостные темы.
В этом выпуске: «работа над ошибками» в коммуникаторе Mint, новый процессор для микросерверов, обновление VTune Amplifier и технологии WiDi, уход Intel с рынка материнских плат для ПК.

Недавно в нашем блоге появилась статья о NUMA-системах, и я хотел бы продолжить тему, поделившись своим опытом работы в Linux. Сегодня я расскажу о том, что бывает, если неправильно использовать память в NUMA и как диагностировать такую проблему с помощью счётчиков производительности.

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

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

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

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

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

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

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

Все проблемы в области Computer Science могут быть решены введением дополнительного уровня косвенности. За исключением одной: слишком большого числа уровней косвенности.
All problems in computer science can be solved by another level of indirection, except for the problem of too many layers of indirection.

Программные интерпретаторы известны своей невысокой скоростью работы. В этой статье я расскажу, как их можно ускорить.
Я давно уже хотел поподробней остановиться на создании интерпретаторов. Прямо таки обещал, в том числе самому себе. Однако серьёзный подход требовал использования более-менее реалистичного кода для примеров, а также проведения измерений производительности, подтверждающих (а иногда и опровергающих) мои аргументы. Но наконец-то я готов представить почтенной публике результаты, причём даже чуть более интересные, чем собирался.
В данной статье будет описано семь способов построения программной ВМ для одной гостевой системы. От самых медленных мы проследуем к более быстрым, поочерёдно избавляясь от различных «неэффективностей» в коде, и в конце сравним их работу на примере одной программы.
Тех, кто не боится ассемблерных листингов, испещрённого макросами кода на Си, обильно удобренного адресной арифметикой, goto и даже longjmp, а также программ, использующих копипаст во имя скорости или даже создающих куски самих себя, прошу пожаловать под кат.

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