восторг

[yigal_s]

Valgrind is in essence a virtual machine using just-in-time (JIT) compilation techniques, including dynamic recompilation. Nothing from the original program ever gets run directly on the host processor. Instead, Valgrind first translates the program into a temporary, simpler form called Intermediate Representation (IR), which is a processor-neutral, SSA-based form. After the conversion, a tool (see below) is free to do whatever transformations it would like on the IR, before Valgrind translates the IR back into machine code and lets the host processor run it. Even though it could use dynamic translation (that is, the host and target processors are from different architectures), it doesn't. Valgrind recompiles binary code to run on host and target (or simulated) CPUs of the same architecture.

Мне стыдно, что не знал этого раньше. Эти черти перехватывают каждое обращение к памяти, на уровне базовой платформы инструментации (под которую можно писать клиенты-плагины), после чего поиск data-races - вполне решаемая задача, что собственно, уже и имплементировано. О всякой прочей фигне, вроде поиска дедлоков, мемликов и говорить не приходится. До кучи, решаются задачи поиска обращений к непроинициализированной памяти и выхода за пределы памяти проаллоцированной. Вот так. Одним махом.

Еще, правда, не понятно как они делают на этой платформе профайлер, раз уж они пределывают весь код процесса. Неужели же эмулируют конвеер процессора? ))).

Comments

[yigal_s]

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

[igor-abramov.livejournal.com]

Если мы программируем на C/C++ мало чем можем влиять на конвееры, потому, что компилятор весьма агрессивно переупорядочивает код. (За очевидными исключениями, когда мы используем asm директивы, ну и некоторые интринсики могут необосновано смутить кодогенератор).

Улучшенные интелом версии gcc одно время давали выигрыш процентов до 20. Вроде gcc и clang прибавили в последнее время, но я не изучал текущее положение дел.

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

[yigal_s]

Когда нужно ускорить какой-то кусок кода раза в 2-10, можно по ошибке заняться "разгоном" того, что дает не очень существенную нагрузку на процессор.

ИМХО, что дает такую нагрузку, а что нет - в нетривиальных случаях можно определить практически только на реальной архитектуре, а не на грубой модели, не учитывающей конвеерности, в частности. И кэширования, как отметили вы. Т.е. какой-то кусок кода по понятиям "моделирующего" профайлера может давать 70% нагрузки, а реально - лишь 10%.

[igor-abramov.livejournal.com]

Чисто теоретически, да, такая аномалия возможна, особенно на уже изрядно прооптимизированном коде.
Ну на этот случай есть Intel Vtune . Я его очень успешно использовал для оптимизации кода, генерируемого Just-In-Time.

[yigal_s]

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

А с Vtune в общем да, вариант хороший.

[igor-abramov.livejournal.com]

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

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

[yigal_s]

Я не знаю, какие способы оценки времени выполнения команд заложены в valgrind.

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