Как использовать выходные данные cachegrind для оптимизации приложения

Question

Мне нужно улучшить пропускную способность системы.

Обычный цикл оптимизации был выполнен, и мы уже добились увеличения пропускной способности в 1,5 раза.

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

Может ли кто-нибудь указать мне, с чего начать?

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

Правильно ли я двигаюсь в этом направлении?

Answer 1

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

Чтобы полностью понять, как шаблоны доступа к памяти влияют на производительность, я рекомендую прочитать отличную статью "Что каждый программист должен знать о памяти" автор: Ульрих Дреппер, сопровождающий GNU libc.

Answer 2

Если у вас возникли проблемы с синтаксическим анализом выходных данных cachegrind, загляните в KCachegrind (он должен быть доступен в выбранном вами дистрибутиве).Я использую его и нахожу весьма полезным.

Answer 3

Согласно документация Cachegrind, данные, предоставленные вам cachegrind, - это количество промахов кэша для данной части вашего кода.Вам нужно знать о том, как работают кэши в выбранной вами архитектуре, чтобы знать, как исправить код.На практике это означает уменьшение размера данных или изменение схемы доступа к некоторым данным таким образом, чтобы кэшированные данные все еще находились в кэше.Однако вам необходимо понимать данные вашей программы и доступ к ним, прежде чем вы сможете действовать на основе этой информации.Как сказано в руководстве,

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

Answer 4

1.5x - это хорошее ускорение.Это означает, что вы нашли что-то, на что ушло 33% времени, от чего вы могли бы избавиться.Держу пари, вы можете сделать больше, даже до того, как перейдете к низкоуровневым проблемам, таким как кэш памяти данных. Это пример того, как это делается. В принципе, у вас могут возникнуть дополнительные проблемы с производительностью (и возможностями для ускорения), которые раньше были невелики, как говорят 25%.Что ж, с ускорением в 1,5 раза эти 25% теперь равны 37,5%, так что это "стоит больше", чем было.Часто такая проблема возникает в виде вызова какой-либо функции среднего стека, запрашивающей работу, которая, как только вы узнаете, сколько это стоит, вы можете решить, что в ней нет полной необходимости.Поскольку kcachegrind на самом деле не определяет их точно, вы можете не осознавать, что это проблема.