Как использовать вывод cachegrind для оптимизации приложения
Мне нужно улучшить пропускную способность системы.
обычный цикл оптимизации был сделан, и мы уже достигли 1.5 X лучшей пропускной способности.
теперь я начинаю задаваться вопросом, Могу ли я использовать выход cachegrind для улучшения пропускной способности системы.
может кто-нибудь указать мне, с чего начать?
Я понимаю, что нам нужно обеспечить, чтобы наиболее часто используемые данные были достаточно малыми, чтобы они оставались в L1 кэш и следующий набор данных должны поместиться в L2.
Это правильное направление, в котором я иду?
4 ответов
Это правда, что вывод cachegrind сам по себе не дает слишком много информации о том, как оптимизировать код. Нужно знать, как это интерпретировать, и то, что вы говорите о том, что данные вписываются в L1 и L2, действительно правильное направление.
чтобы полностью понять, как шаблоны доступа к памяти влияют на производительность, я рекомендую прочитать отличную бумаги "Что Каждый Программист Должен Знать О Памяти" Ульрихом Дреппером, сопровождающим GNU libc.
Если у вас возникли проблемы с разбором вывода cachegrind, посмотрите в KCacheGrind (он должен быть доступен в вашем дистрибутиве по выбору). Я использую его и нахожу весьма полезным.
по данным документация Cachegrind, детали, данные вам cachegrind-это количество пропусков кэша для данной части вашего кода. Вам нужно знать о том, как кэши работают на архитектуре, на которую вы нацелены, чтобы вы знали, как исправить код. На практике это означает уменьшение размера данных или изменение шаблона доступа к некоторым данным, чтобы кэшированные данные оставались в кэше. Однако вам нужно понять данные и доступ к данным вашей программы перед вами может действовать по информации. Как говорится в руководстве,
короче говоря, Cachegrind может сказать вам, где некоторые из узких мест в вашем коде, но он не может сказать вам, как их исправить. Ты должен разобраться в этом сам. Но, по крайней мере, у тебя есть информация!
1.5 x-хорошее ускорение. Это означает, что вы нашли что-то, что заняло 33% времени, от которого вы могли избавиться. Держу пари, вы можете сделать больше, даже до того, как вы перейдете к низкоуровневым проблемам, таким как кэш памяти данных. Это пример того, как. в принципе, у вас могут быть дополнительные проблемы с производительностью (и возможности для ускорения), которые не были большими раньше, как говорят 25%. Ну, с ускорением 1.5 x, что 25% теперь 37.5%, так что это "стоит больше", чем было. Часто такая проблема форма вызова функции среднего стека, которая запрашивает работу, которая, как только вы знаете, сколько она стоит, вы можете решить, что это не совсем необходимо. Поскольку kcachegrind на самом деле не указывает их, вы можете не понимать, что это проблема.