Для получения триального ключа
заполните форму ниже
Team License (базовая версия)
Enterprise License (расширенная версия)
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

** На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Запросите информацию о ценах
Новая лицензия
Продление лицензии
--Выберите валюту--
USD
EUR
GBP
RUB
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

** На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Для получения лицензии для вашего открытого
проекта заполните, пожалуйста, эту форму
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

** На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Для получения лицензии для вашего открытого
проекта заполните, пожалуйста, эту форму
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

** На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Мне интересно попробовать плагин на:
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

** На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Ваше сообщение отправлено.

Мы ответим вам на


Если вы так и не получили ответ, пожалуйста, проверьте папку
Spam/Junk и нажмите на письме кнопку "Не спам".
Так Вы не пропустите ответы от нашей команды.

>
>
Intel VTune Amplifier XE 2011 beta под …

Intel VTune Amplifier XE 2011 beta под строгим взглядом программиста

15 Сен 2010

Решил посмотреть на новый Intel VTune Amplifier XE 2011 beta и написать статью о примере использования. Правда, в процессе написания акцент частично сместился от использования Amplifier к его тестированию. Но это тоже хорошо, надеюсь, разработчики в Intel учтут пожелания и внесут изменения в следующую версию инструмента. И вообще буду критиковать и себя, и всех :).

0078_Intel_VTune_beta_ru/image1.png

Начну немного издалека, иначе возникнут вопросы, зачем мне понадобился код, который мне пришлось оптимизировать. В ходе разработки статического анализатора кода для Си++ мне приходится сталкиваться с весьма экзотическими фрагментами программ. Чего только программисты не придумывают. И даже такие компиляторы, как Visual C++ или Intel C++ нет, нет, да и упадут на очередной "загогулине".

В нашем статическом анализаторе PVS-Studio есть одно не очень хорошее место, связанное с определением типа объектов. Есть, например, конструкция:

typedef int A;
typedef A B;
B myValue;

и необходимо "вычислить" тип B, чтобы узнать, что это не что иное, как int. С подобными примерами, конечно, никаких сложностей нет и все работает. Однако бывают очень запутанные ситуации. Приведу пример кода, демонстрирующего откуда начинают появляться разные сложности:

0078_Intel_VTune_beta_ru/image2.png

При попытке узнать тип переменной X мы посмотрим ее тип в namespace B и не найдем его там. Тогда мы увидим, что надо посмотреть в namespace C. И тоже там не найдем. Теперь надо посмотреть и в namespace B... Вечный цикл. Конечно, это простой случай и с ним тоже никаких проблем нет. Но добавьте сюда typedef, шаблоны, наследуемые классы. Иногда получаются удивительно сложные вещи, причем не специально. Особенно это проявляется в коде с шаблонами.

К сожалению, инструмент PVS-Studio иногда входил в вечный цикл на особенно "удачных конструкциях" и делал самоубийство через 5 минут, чтобы было возможно продолжить обработку других файлов. Очень редкая ситуация, но неприятная. Ошибки, конечно, правятся и правятся, но находятся все новые ситуации. Причем не всегда есть возможность узнать, что же это за код такой у пользователя. Было принято решение не полностью обрывать работу анализатора по таймеру, а отказаться от получения типа какого-то объекта, если возникает зацикливание. Лучше пропустить одну переменную, чем весь файл.

Здесь проявляет очень интересный момент несовместимости теории и практики. Теоретически надо написать так, чтобы ошибок не было. Даже пожурить нас можно. Разработчики статического анализатора, писатели статей как писать без ошибок, а сами не могут сделать верный разбор типа переменных. А вот получается, что не можем. И не только мы. Задачи, связанные с компиляцией Си++ кода крайне сложные. И приходится от рассуждений о высоком и прекрасном переходить к созданию заплаток на всякий случай.

Был создан простой, но эффективный механизм остановки. Если при получении типа объекта мы получаем указатель на закодированный тип, с которым уже работали до этого, то стоп. Для начала был создан просто класс, содержащий множество указателей в std::set<const void*> *m_pGuardPointers. Если в множестве уже есть указатель, то значит пора остановиться.

Я не удивился, когда производительность программы после такого изменения упала во много раз. Я ожидал подобного эффекта. Не стал даже мерить скорость, и так видно, что очень медленно и причина понятна. Обычно глубина "вывода" типа не велика, и использовать тяжелую артиллерию для подобных случаев просто глупо:

typedef long LONG;
LONG x;

Сразу был написан класс следующего вида (приводится в сокращенном виде):

class CPointerDuplacateGuard
{
  static const size_t QuickMaxSize = 10;
  const void *m_ptrs[QuickMaxSize];
  size_t m_index;
  std::set<const void*> *m_pGuardPointers;
public:
  CPointerDuplacateGuard();
  CPointerDuplacateGuard(const CPointerDuplacateGuard *parent);
  ...
};

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

И вот здесь то я и решил, что пришло время посмотреть на Intel VTune Amplifier XE 2011 beta. Очень хороший повод. Здесь профилировщик как нельзя кстати. Он поможет ответить на вопрос, связано падение производительности только с использованием std::set или замедление вносит само использование постоянных проверок указателя. Если основное падение производительности связано с std::set, то нужно увеличивать значение QuickMaxSize. Это отложит использование std::set на самый крайний случай. Если замедляет сам алгоритм, то думать дальше.

Сразу скажу, что как следует поработать с Intel VTune Amplifier XE 2011 beta у меня не хватило терпения. Он вводит невообразимое торможение в работу. Хотя у меня достаточно мощная система (4 ядра, 8 Гбайт памяти), если открыто окно Intel VTune Amplifier XE 2011 beta, то даже простое перемещение по коду делается с натугой и рывками. Причем сам Intel VTune Amplifier XE 2011 ничего не делает. Вернее процессор он нагружает, но не пишет, чем занимается. Чтобы не быть голословным приведу демонстрационные скриншоты.

Для большей наглядности, я прикрепил devenv.exe к 4-тому ядру.

0078_Intel_VTune_beta_ru/image3.png

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

0078_Intel_VTune_beta_ru/image4.png

Теперь я просто запускаю Intel VTune Amplifier XE 2011. Подчерку, что только запускаю! Я не выполняю анализ проекта и вообще ничего не делаю. Но четвертое ядро уже занято полностью:

0078_Intel_VTune_beta_ru/image6.png

Работать становится сразу как-то некомфортно. Среда начинает тормозить везде, где только можно. Если закрыть окно Intel VTune Amplifier XE 2011 то торможение тут же пропадает и загрузка ядра снова становится близка к нулю. Возможно, запущенный Intel VTune Amplifier XE 2011 делает какую-то полезную работу. Но какую непонятно. Если делает - то надо как минимум показать это. У меня сложилось ощущение о какой-то ошибке.

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

0078_Intel_VTune_beta_ru/image8.png

Анализ выполнился без неожиданностей:

0078_Intel_VTune_beta_ru/image9.png

И я получил полезный результат:

0078_Intel_VTune_beta_ru/image10.png

Большинство времени тратится в std::_Tree, в функциях выделения и освобождения памяти. Программисту сразу станет понятно, что основное замедление связано именно с использованием std::set.

Если запустить Amplifier в режиме Hotspot, то проблемное место станет гораздо очевиднее:

0078_Intel_VTune_beta_ru/image12.png

После этого запуска стало возможным просмотреть стек вызовов. Правда, первый мой запуск в этом режиме закончился неудачей. Меня предупреждали, что с включенной галочкой "Collect accurate CPU time" все будет медленнее. Но получилось как-то слишком медленно. Когда я нажал на кнопку раскрытия стека для первой функции, то так и не дождался результата (ждал 15 минут).

Запуск уже без галочки показал нужную мне информацию. Но и здесь не могу не добавить ложку дегтя. Функционально инструмент замечателен, но интерфейс безобразен. Все время что-то разъезжается, не перерисовывается, что-то смазывается. Пользоваться неудобно и неприятно:

0078_Intel_VTune_beta_ru/image13.png

Впрочем, подводил не только внешний вид. Иногда почему-то перебрасывает на не тот участок кода, который необходимо.

Однако нужный результат я все-таки достиг. Оказалось, что если установить значение массива в 64, то производительность возвращается приблизительно на прежний уровень. Новая подсистема практически не вносит замедления в работу. Исправление:

static const size_t QuickMaxSize = 64;

Это подтверждается и Amplifier. Теперь на первый план вышли совсем другие функции, такие как strncmp:

0078_Intel_VTune_beta_ru/image15.png

Выводы

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

Пост получился несколько критичный по отношению к инструменту Intel VTune Amplifier. Видимо это у меня как у разработчика наболело. Предлагают попробовать очередную программу, которая улучшит мир, а как начинаешь с ней работать, то понимаешь, что больше потратили на маркетинг или красивые картинки, чем на контроль качества. Ну что это за профайлер, который сам тормозит? Сапожник без сапог. :)

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

Популярные статьи по теме
Главный вопрос программирования, рефакторинга и всего такого

Дата: 14 Апр 2016

Автор: Андрей Карпов

Вы угадали, ответ - "42". Здесь приводится 42 рекомендации по программированию, которые помогут избежать множества ошибок, сэкономить время и нервы. Автором рекомендаций выступает Андрей Карпов - тех…
Зло живёт в функциях сравнения

Дата: 19 Май 2017

Автор: Андрей Карпов

Возможно, читатели помнят мою статью под названием "Эффект последней строки". В ней идёт речь о замеченной мной закономерности: ошибка чаще всего допускается в последней строке однотипных блоков текс…
Как PVS-Studio оказался внимательнее, чем три с половиной программиста

Дата: 22 Окт 2018

Автор: Андрей Карпов

PVS-Studio, как и другие статические анализаторы кода, часто выдаёт ложные срабатывания. Но не стоит спешить считать странные срабатывания ложными. Это короткая история о том, как PVS-Studio вновь ок…
Как и почему статические анализаторы борются с ложными срабатываниями

Дата: 20 Мар 2017

Автор: Андрей Карпов

В своей предыдущей статье я писал, что мне не нравится подход, при котором статические анализаторы кода оцениваются с помощью синтетических тестов. В статье приводился пример, воспринимаемый анализат…
PVS-Studio для Java

Дата: 17 Янв 2019

Автор: Андрей Карпов

В седьмой версии статического анализатора PVS-Studio мы добавили поддержку языка Java. Пришло время немного рассказать, как мы начинали делать поддержку языка Java, что у нас получилось и какие дальн…
Характеристики анализатора PVS-Studio на примере EFL Core Libraries, 10-15% ложных срабатываний

Дата: 31 Июл 2017

Автор: Андрей Карпов

После большой статьи про проверку операционной системы Tizen мне было задано много вопросов о проценте ложных срабатываний и о плотности ошибок (сколько ошибок PVS-Studio выявляет на 1000 строк кода)…
Эффект последней строки

Дата: 31 Май 2014

Автор: Андрей Карпов

Я изучил множество ошибок, возникающих в результате копирования кода. И утверждаю, что чаще всего ошибки допускают в последнем фрагменте однотипного кода. Ранее я не встречал в книгах описания этого …
PVS-Studio ROI

Дата: 30 Янв 2019

Автор: Андрей Карпов

Время от времени нам задают вопрос, какую пользу в денежном эквиваленте получит компания от использования анализатора PVS-Studio. Мы решили оформить ответ в виде статьи и привести таблицы, которые по…
Любите статический анализ кода!

Дата: 16 Окт 2017

Автор: Андрей Карпов

Я в шоке от возможностей статического анализа кода, хотя сам участвую в разработке инструмента PVS-Studio. На днях я был искренне удивлён тому, что анализатор оказался умнее и внимательнее меня.
Бесплатный PVS-Studio для тех, кто развивает открытые проекты

Дата: 22 Дек 2018

Автор: Андрей Карпов

В канун празднования нового 2019 года команда PVS-Studio решила сделать приятный подарок всем контрибьюторам open-source проектов, хостящихся на GitHub, GitLab или Bitbucket. Им предоставляется возмо…

Комментарии (0)

Следующие комментарии

На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Этот сайт использует куки и другие технологии, чтобы предоставить вам более персонализированный опыт. Продолжая просмотр страниц нашего веб-сайта, вы принимаете условия использования этих файлов. Если вы не хотите, чтобы ваши данные обрабатывались, пожалуйста, покиньте данный сайт. Подробнее →
Принять