Времена, сообщенные профилировщиком, против истинных времен - почему расхождение?

Question

У меня есть два куска кода, которые выполняют одну и ту же операцию.Один кусок написан мной, другой написан третьей стороной.Они оба скомпилированы в один исполняемый файл.Сторонний код, похоже, способен выполнять свою работу намного быстрее, чем мой.Он может выполнять 1500 операций в секунду по сравнению с моими 500. Затем я запустил исполняемый файл в VTune, используя опцию профилирования callgraph, надеясь, что это покажет, где я тратил время.К сожалению, диагностика VTune, которая показывает количество микросекунд, которые, по ее мнению, занимает каждая функция, утверждает, что и моя функция, и функция стороннего производителя занимают около 0,002 секунды на вызов.Это похоже на мой код, но полностью расходится с моим (ручным) измерением скорости стороннего кода.

Как это может произойти?

РЕДАКТИРОВАТЬ: обе части кодаони большие и вызывают свои собственные сложные деревья подфункций.

РЕДАКТИРОВАТЬ: я должен отметить, что сторонний код является чистым C ++, тогда как мой код по сути является C-кодом, который был только что скомпилирован в компиляторе C ++.

РЕДАКТИРОВАТЬ: VTune - очень сложный пакет с множеством параметров конфигурации, которые я не понимаю.Могут ли быть какие-то настройки для игры, которые могут уменьшить эту неточность?

Answer 1

Ваше определение «истинного времени» может нуждаться в пересмотре.Вы не можете утверждать, что профилировщик неверен при сравнении яблок и груш.

Профилировщики могут использоваться для относительного времени;используйте профилировщик, чтобы найти «горячую точку» в вашем коде, а затем используйте информацию для оптимизации этой области.

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

(PS Также читайте о Schrodinger / Heisenberg )

Answer 2

Если вы используете время на стене (т.е. прошедшие секунды вместо счетчиков ЦП), вам также необходимо учитывать время, затрачиваемое на блокировку системных вызовов. Например, предполагая, что вы не делаете много файлового ввода-вывода, вы, вероятно, тратите много времени на вывод информации на консоль. Консольный ввод / вывод не будет отображаться как процессорное время, так как большую часть этого времени просто ожидает обновления консоли.

Вы можете использовать GetThreadTimes(...), чтобы определить, сколько времени вы тратите в своем коде против системного кода. Я использовал это и выборку системных вызовов, чтобы уменьшить переключение контекста (и в конечном итоге увеличить общую производительность).

Answer 3

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

Вы пытались использовать высокопроизводительные часы (gethrtime в Solaris или QueryPerformanceCounter в Windows) и измерять общее время функций в качестве проверки работоспособности?

Ваши операции звучат очень медленно, чтобы быть привязанными к процессору - они связаны с вводом / выводом? Ваш код ввода / вывода менее оптимизирован, чем код библиотеки? Это не обязательно будет отображаться в отчете профиля процессора вообще.