Comments 20
участник, пославший один и тот же код два раза, получит совершенно разные результатыТестовый прогон выполнять N раз, с максимальным приоритетом процесса. По среднему времени оценивать.
Насчет работы на линуксе, на виндовсе, на черте-лысом, да, везде будет по разному, поэтому оценочный стенд надо зафиксировать каким-то образом, поверить как средство измерения, или же сравнивать не по времени работы, а в попугаях относительно типовой задачи, которая выполняется за условную единицу времени на этом стенде.
Т.е. в идеальном случае T = t в большинстве случаев, затем T = t + q в меньшем количестве случаев, T = t + 2q в еще меньшем, T = t + 3q еще реже и т.д. Т.е. распределение не нормальное, и усреднять в таком случае бессмысленно.
Очень удобно профайлить в CI и отслеживать изменения от коммита к коммиту. По времени такое не сделать т.к. изменения обычно небольшие, и если измерять на хардваре, то даже если много циклов делать, — зависит от фазы луны и температуры в датацентре. Не говоря уже о том, что в CI сборщик обычно не фиксирован и реального железа архитектур отличных от x86 обычно нет.
Кстати о птичкахQEMU: насколько мне известно, при указании опции -icount (возможно, ещё с какими-то параметрами) — получаете подсчёт инструкций "из коробки" (вроде, там в каждый translation block добавляется соответствующее изменение счётчика выполненных инструкций и, можно надеяться, исключения тоже обрабатываются корректно). Вот только с user-mode эмуляцией никогда на это не смотрел (я вообще на неё особо не смотрел)… Возможно, к этому счётчику можно как-то прицепиться, правда логика там малость запутанная.
Кстати, а Valgrind в режиме cachegrind чего-нибудь подобного не умеет?
qemu: unknown option 'icount'
Да и в любом случае блоки нужны, чтобы показать профайл по функциям, а посчитать блок и самому не так сложно + можно тяжелые инструкции, если что, пропарсить, и им больше клоктиков приписать.
А так мне самому интересно, как это еще сделать менее костыльно, выдача блоков все-таки сильно тормозит QEMU, если влезть в его код можно профайл сильно ускорить. И ничего более путного чем QEMU я не нашел пока для этих целей.
LLVM IR, однако, является платформенно-независимым, так как это только промежуточное представление кода.
Немного позанудствую: разработчики LLVM пишут, что совсем платформенно-независимый код не получится (препроцессор, размеры типов и т.д.)
Кстати, эта задача напомнила мне то, с чем столкнулись разработчики mozilla rr (это time-travelling debugger, основанный на полном воспроизведении недетерминированного поведения) — им потребовалось в точности (или почти?) воспроизводить количество инструкций между некоторыми точками выполнения (вероятно, переключениями потоков/процессов) — в итоге их инструмент работает только на достаточно свежих Интеловских процессорах с достаточно стабильными используемыми ими performance counter-ами (были попытки поддержи Ryzen, но чем закончились, не знаю). Ну, то есть стабильность зависит от микроархитектуры, а не конкретного экземпляре процессора. :) Впрочем, здесь уже никакой платформенно-независимостью и не пахнет, конечно.
Интересный подход, но все же интересно насколько инструкции LLVM IR одинаково легковесны относительно друг друга. Грубо говоря: 1000 инкрементов регистра процессора и 1000 обращений к оперативной памяти совсем не эквиваленты.
и поэтому что-либо типа инструмента PIN не подходит для наших целей.
вот здесь автор как раз упомянул его, но дальше, к сожалению не стал сравнивать.
Хотя на самом деле правильно производительность мерить, не менее простая задача.
P.S. скоро как раз будет статья про Pintool.
Т.к. время выполнения инструкций отличается на порядки, легковесность инструкций для разных архитектур тоже. Даже x32 и x64 будут в реальности давать сильно разные результаты.
Профилирование кода с LLVM