LINUX.ORG.RU

Как найти медленные функции после инлайна?

 , ,


0

5

В очередной раз столкнулся со старой проблемой: valgrind позволяет найти медленные функции до тех пор, пока они не инлайнятся. Можно это как-то обойти? У меня пару десятков функций, которые в релизе превращаются в одну. Как найти причину тормозов - не ясно.

Может есть какой-то профилировщик, который выплюнет asm и покажет какие куски дольше всего выполнялись? Типа flame graph.

PS: интересует софт только под линь.

★★★★★

Последнее исправление: RazrFalcon (всего исправлений: 1)

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

provaton ★★★★★
()
Последнее исправление: provaton (всего исправлений: 1)

Можно это как-то обойти?

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

alysnix ★★★
()
Ответ на: комментарий от RazrFalcon

Я не очень понял, если Вы хотите замер производительности заинлайниной ф-ии, то наверное Вы хотите просто узнать время работы соотв.фрагмента кода?

Насколько сильная разница будет между таким замером для инлайн-фрагмента и для тела той же функции?

AntonI ★★★★
()

Во-первых gprof, там можно даже line-by-line profiling делать https://sourceware.org/binutils/docs/gprof/Line_002dby_002dline.html

Во-вторых есть вот такая штука https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html

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

void __cyg_profile_func_enter (void *this_fn,
                               void *call_site);
void __cyg_profile_func_exit  (void *this_fn,
                               void *call_site);

Еще есть проприетарный Vtune от Intel и опенсорсный CodeXL от AMD но я ими не пользовался.

SZT ★★★★★
()
Ответ на: комментарий от RazrFalcon

Разница во времени работы кода с инлайном и без инлайна огромна. Теперь берем какую то функцию

void f(){
   double t0 = omp_get_wtime();
   ...
   double t1 = omp_get_wtime();   
}

насколько сильно будут различаться t1-t0 в случае если f() заинлайнена и если нет?

AntonI ★★★★
()
Ответ на: комментарий от RazrFalcon

Ок, а если гипотетически?

Я согласен с @provaton, поиск узкого места и замер общей производительности это разные задачи.

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

Вам то что именно нужно, найти узкое место в коде или точно замерить сколько времени занимает какая то функция?

AntonI ★★★★
()
Ответ на: комментарий от SZT

проприетарный Vtune от Intel

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

ZERG ★★★★★
()
Ответ на: комментарий от SZT

Ну gcc не вариант, ибо rust.

CodeXL не осилил собрать. Он использует scons и ему походу нужен python2. Какие-то левые ошибки сыпет. Завтра попробую снова.

RazrFalcon ★★★★★
() автор топика
Ответ на: комментарий от RazrFalcon

PS: CodeXL - типичный корпоративный комбайн:

2.7 GiB (2,941,504,224)
17,657 files, 2,821 sub-folders

И это только сорцы.

RazrFalcon ★★★★★
() автор топика
Ответ на: комментарий от RazrFalcon

А найти какая функция тормозит без инлайна это не вариант? Скорее всего она и тормознутый кусок асма порождает?

AntonI ★★★★
()
Ответ на: комментарий от AntonI

Насколько сильная разница будет между таким замером для инлайн-фрагмента и для тела той же функции?

Меньше, чем плата за использование профилировщика

SR_team ★★★★★
()
Ответ на: комментарий от SR_team

Да, я кстати никогда не юзал valgrind в таком качестве. Насколько он как профилировщик тормозит? Потому что когда память им чекаешь это адский ад…

AntonI ★★★★
()
Ответ на: комментарий от AntonI

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

SR_team ★★★★★
()
Ответ на: комментарий от AntonI

Судя по наблюдениям, инлайн позволяет очень сильно перекроить код, из-за чего данные собранные до инлайна становятся бесполезными.

RazrFalcon ★★★★★
() автор топика
Ответ на: комментарий от RazrFalcon

Э… я конечно не знаю что у Вас за задача, и на расте никогда не писал, но все же (идеологически) данные по неинлайновым функциям ИМНО вполне релевантны для поиска узких мест.

Более того, при инлайне и оптимизации код может быть изуродован как Богом черепаха, и вопрос «сколько уходит на выполнение инлайн функции» может быть просто лишен смысла - там может оказаться несколько функций в перемешку (я не специалист, могу ошибаться).

Обычно, при профилировании числодробилок, больше всего помогает даже не профилировщик а общие замеры производительности и здравый смысл. Но числодробилки относительно простые…

AntonI ★★★★
()
Ответ на: комментарий от WitcherGeralt

Да. Добавление директивы inline может давать 20-30% прирост.

RazrFalcon ★★★★★
() автор топика
Ответ на: комментарий от RazrFalcon

Мне казалось он крутит код на какой то вирт. машине?

AntonI ★★★★
()

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

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

dave ★★★★★
()
Ответ на: комментарий от AntonI

Может быть и наоборот. У меня был случай, когда одна функция вызывалась овер миллион раз, тк ее нужно было к каждому элементу массива применить. Сделал передачу массива в функцию (вместо элемента) и вуаля - разница в несколько десятков процентов по производительности.

Norgat ★★★★★
()

Там в соседней теме аноним советует perf annotate, который очень похож на то, что я хочу. Но он увы не работает.

UPD: оно таки работает, но не нужно указывать путь к бинарю, как в инструкции.

RazrFalcon ★★★★★
() автор топика
Последнее исправление: RazrFalcon (всего исправлений: 1)

В общем ничего проще и удобнее чем отключить глобально inline и прогнать прогу через valgrind в Qt Creator так и не нашлось.

RazrFalcon ★★★★★
() автор топика
Ответ на: комментарий от AntonI

Дык я и до этого этот метод использовал. Так что никак. Для меня основная польза valgrind - это счётчик вызовов функций. Ну и call graph.

RazrFalcon ★★★★★
() автор топика
Ответ на: комментарий от annulen

Да, эта инфа хранится. Но у меня тот же perf annotate у 99% ассемблерных команд пишет 0. Так что толку от него мало. А часто используемые функции я и без валгринда знаю.

RazrFalcon ★★★★★
() автор топика

AMD CodeXL (бесплатно), Intel Vtune (за много денег).

nikitos ★★★
()
Ответ на: комментарий от RazrFalcon

Но у меня тот же perf annotate у 99% ассемблерных команд пишет 0. Так что толку от него мало. А часто используемые функции я и без валгринда знаю.

Смешались в кучу кони, люди… perf и callgrind - совсем разные инструменты. callgrind показывает количество инструкций в каждой выполненной функции, что позволяет получить более-менее воспроизводимые результаты между запусками. Да и аннотации к сорсам он тоже умеет.

annulen ★★★★★
()
Ответ на: комментарий от RazrFalcon

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

annulen ★★★★★
()
Последнее исправление: annulen (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.