![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
yigal_sValgrind 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 - вполне решаемая задача, что собственно, уже и имплементировано. О всякой прочей фигне, вроде поиска дедлоков, мемликов и говорить не приходится. До кучи, решаются задачи поиска обращений к непроинициализированной памяти и выхода за пределы памяти проаллоцированной. Вот так. Одним махом.
Еще, правда, не понятно как они делают на этой платформе профайлер, раз уж они пределывают весь код процесса. Неужели же эмулируют конвеер процессора? ))).
Мне стыдно, что не знал этого раньше. Эти черти перехватывают каждое обращение к памяти, на уровне базовой платформы инструментации (под которую можно писать клиенты-плагины), после чего поиск data-races - вполне решаемая задача, что собственно, уже и имплементировано. О всякой прочей фигне, вроде поиска дедлоков, мемликов и говорить не приходится. До кучи, решаются задачи поиска обращений к непроинициализированной памяти и выхода за пределы памяти проаллоцированной. Вот так. Одним махом.
Еще, правда, не понятно как они делают на этой платформе профайлер, раз уж они пределывают весь код процесса. Неужели же эмулируют конвеер процессора? ))).
no subject
Date: 2013-08-03 01:54 am (UTC)no subject
Date: 2013-08-03 02:14 am (UTC)Здорово!
no subject
Date: 2013-08-03 02:50 am (UTC)no subject
Date: 2013-08-03 02:58 am (UTC)равно как и не нужен JIT - достаточно просто бежать по исходным байтам команд и их интерпретировать.
А вот то, что nulgrind бежит всего-то раз в 5 медленнее аппликции, равно как то, что на Google детектор мультитредных багов еще несколько подразогнали по сравнению с helgrind - это как раз область интересов не разработчиков процессоров, а программеров, мне кажется.
no subject
Date: 2013-08-03 03:08 am (UTC)no subject
Date: 2013-08-03 03:23 am (UTC)Если всерьез моделировать внутреннюю функциональность, то мне кажется, о JIT можно забыть, нет?
no subject
Date: 2013-08-03 03:35 am (UTC)no subject
Date: 2013-08-03 03:42 am (UTC)Впрочем, ну о чем мы спорим, скажите мне, что для моделирования процессоров разработчики процессоров действительно применяют JIT, а не интерпретатор - и мне останется лишь согласиться.
no subject
Date: 2013-08-03 03:52 am (UTC)no subject
Date: 2013-08-03 03:56 am (UTC)no subject
Date: 2013-08-03 01:57 am (UTC)no subject
Date: 2013-08-03 02:13 am (UTC)Это, по идее, для x86 никак не подходит.
no subject
Date: 2013-08-03 02:51 am (UTC)no subject
Date: 2013-08-03 03:01 am (UTC)no subject
Date: 2013-08-04 08:28 am (UTC)Дело в том, что платформы для исполнения постоянно меняются и у каждой свои тонкие особенности. Отражать эти вещи на уровне исходного кода дело неблагодарное, все очень непостоянно, и, более того, на практике часто надо поддерживать несколько платформ одновременно (разные функции порождать? генерировать их темплейтами или препроцессором? Уж очень все громоздко и неэлегантно).
А вот оптимизировать для некоторой единой абстрактной машины, не так уж далеко ушедшей от реального железа, но существенно более гладкой --- пожалуй разумный компромисс. Эта машина будет соответствовать некому образу процессора, имеющемуся в голове озабоченного микроэффективностью С/С++ программиста.
Ну о оптимизации на уровне исходного кода для таких вещей имеют обычно более благообразный вид.
no subject
Date: 2013-08-04 04:09 pm (UTC)no subject
Date: 2013-08-04 04:40 pm (UTC)Улучшенные интелом версии gcc одно время давали выигрыш процентов до 20. Вроде gcc и clang прибавили в последнее время, но я не изучал текущее положение дел.
Вот за чем можно следить, так это за локальностью и порядком обращений к памяти. Правильно разложенные (и выровненные) поля в структурах данных, возможно, даже поля следующие в порядке обращения к ним в самом типичном случае.
no subject
Date: 2013-08-04 05:03 pm (UTC)ИМХО, что дает такую нагрузку, а что нет - в нетривиальных случаях можно определить практически только на реальной архитектуре, а не на грубой модели, не учитывающей конвеерности, в частности. И кэширования, как отметили вы. Т.е. какой-то кусок кода по понятиям "моделирующего" профайлера может давать 70% нагрузки, а реально - лишь 10%.
no subject
Date: 2013-08-04 05:15 pm (UTC)Ну на этот случай есть Intel Vtune . Я его очень успешно использовал для оптимизации кода, генерируемого Just-In-Time.
no subject
Date: 2013-08-04 09:20 pm (UTC)А с Vtune в общем да, вариант хороший.
no subject
Date: 2013-08-04 09:29 pm (UTC)И вот в ситуации, когда мне нужно профильнуть код относительно многих процессорных семейств, в том числе и не вышедших, штука типа Valgrind может оказаться более полезной.
no subject
Date: 2013-08-04 09:33 pm (UTC)Но только это может определить в конечном итоге, пригоден ли он для грубой усредненной оценки по семейству процессоров, или даже хороший профалинг под конкретный процессор дает лучший результат и на семейство.