Как использовать вывод cachegrind для оптимизации приложения
Для Linux: Google Perftools
- Быстрее, чем valgrind (все же, не настолько мелкомодульный)
- не нужна отладка кода
- , Хороший вывод графических данных (-> kcachegrind)
- Делает профилирование памяти, профилирование CPU, проверку утечки
4 ответа
Верно, что вывод cachegrind сам по себе не дает слишком много информации о том, как проводить оптимизацию кода. Нужно знать, как это интерпретировать, и то, что вы говорите о подгонке данных в L1 и L2, действительно является правильным направлением.
Чтобы полностью понять, как шаблоны доступа к памяти влияют на производительность, я рекомендую прочитать отличную статью «Что должен знать каждый программист о памяти» Ульриха Дреппера, сопровождающего GNU libc.
Если у вас возникли проблемы с синтаксическим анализом вывода cachegrind, загляните в KCacheGrind (он должен быть доступен в выбранном вами дистрибутиве). Я использую его и считаю очень полезным.
Согласно документации Cachegrind , данные, предоставленные вам cachegrind, представляют собой количество промахов кеша для данной части вашего кода. Вам нужно знать, как кеши работают в целевой архитектуре, чтобы знать, как исправить код. На практике это означает уменьшение размера данных или изменение схемы доступа к некоторым данным, чтобы кэшированные данные все еще оставались в кеше. Однако вам необходимо понять данные вашей программы и доступ к данным, прежде чем вы сможете действовать в соответствии с информацией. Как говорится в руководстве,
Короче говоря, Cachegrind может сказать вам, где находятся некоторые узкие места в вашем коде, но не может сказать вам, как их исправить. Вы должны решить это сами. Но, по крайней мере, у вас есть информация!
1,5x - хорошее ускорение. Это означает, что вы нашли то, от чего можно было избавиться в 33% случаев. Бьюсь об заклад, ты можешь сделать больше, еще до того, как вы перейдете к низкоуровневым проблемам, таким как кэш памяти данных. Это пример того, как. В принципе, у вас могут быть дополнительные проблемы с производительностью (и возможности для ускорения), которые раньше были небольшими, например, 25%. Что ж, с 1,5-кратным ускорением эти 25% теперь составляют 37,5%, так что это «стоит больше», чем было. Часто такая проблема возникает в форме вызова некоторой функции среднего стека, которая запрашивает работу, которая, как только вы узнаете, сколько она стоит, вы можете решить, что она не является полностью необходимой. Поскольку kcachegrind на самом деле не определяет их, вы можете не осознавать, что это проблема.
эти 25% сейчас 37,5%, так что они «стоят больше», чем были. Часто такая проблема возникает в форме вызова некоторой функции среднего стека, которая запрашивает работу, которая, как только вы узнаете, сколько она стоит, вы можете решить, что она не является полностью необходимой. Поскольку kcachegrind на самом деле не определяет их, вы можете не осознавать, что это проблема. эти 25% сейчас 37,5%, так что они «стоят больше», чем были. Часто такая проблема возникает в форме вызова некоторой функции среднего стека, которая запрашивает работу, которая, как только вы узнаете, сколько она стоит, вы можете решить, что она не является полностью необходимой. Поскольку kcachegrind на самом деле не определяет их, вы можете не осознавать, что это проблема.