Когда подпрограмму необходимо сравнить, сравнительно легко создать для нее рабочую нагрузку, а затем просто выполнить цикл по этой рабочей нагрузке для извлечения статистики. Он предоставит достаточно информации для измерения производительности подпрограммы.
По крайней мере, в теории. Однако на практике я нахожу эквивалентность сценариям реального мира не такой простой.
В тесте подпрограмма «ядро и центр» будет повторяться снова и снова, чтобы ее можно было измерить. В течение этого периода он, по сути, обладает монополией на кэши данных и инструкций. Это может привести к проектным решениям, которые заметно улучшат показатели тестов, хотя и за счет завышенных бюджетов кэширования инструкций и данных.
После интеграции в большую систему целевая подпрограмма теперь вызывается время от времени, зажатая между несколькими другими подпрограммами. Он больше не одинок, что означает, что раздутый бюджет теперь будет играть против него, сбрасывая кэш, используемый другими подпрограммами.
Я в порядке измерения и укрощения воздействия кэша данных. Но для кеша инструкций это совсем другая проблема.
Это воздействие, по-видимому, невозможно измерить в синтетическом тесте, где подпрограмма одна. Тем не менее, из-за этой разницы это приводит к неверным выводам. Это большая проблема, из-за которой тесты по сути бесполезны или просто вводят в заблуждение.
Я не нашел решения этой проблемы, кроме измерения производительности всей системы. Но когда подпрограмма предназначена для повторного использования, неясно, является ли измерение ее вклада в одном случае использования репрезентативным для любого другого варианта использования.
Кроме того, когда подпрограмма является лишь небольшим вкладчиком в систему, сложнее извлечь ее влияние с достаточной точностью (сама система может иметь больше шума, чем вклад подпрограммы).
Существует ли какая-либо "хорошая практика", которая позволяет измерять производительность подпрограммы, учитывая ее влияние на (общий) кэш команд?