Определение времени выполнения программы на архитектуре Core i5 / 7 - PullRequest
6 голосов
/ 27 ноября 2010

При точном определении скорости выполнения алгоритма в моих программах я всегда использовал QueryPerformanceCounter () в сочетании с QueryPerformanceFrequency (), однако что происходит, когда я использую архитектуру ядра i5 / 7?

Возможно ли, что турбо-ускорение внезапно пойдет наполовину по моему алгоритму, и вдруг мой таймер производительности перестанет быть точным, потому что частота моих часов больше не постоянна, или это действительно не проблема? Если это проблема, что может быть лучше для точного определения времени алгоритма?

Ответы [ 4 ]

3 голосов
/ 27 ноября 2010

Проще говоря, да, все может случиться. Современные процессоры просто затрудняют оценку производительности в реальном мире. Это не ограничивается только новейшим процессором Intel x86-64, оно в равной степени относится к 8-битным микроконтроллерам PIC и всем, что между ними.

Единственное разумное, что можно с этим сделать, это просто проверить больше. Вам нужно будет выполнить множество повторных тестов, чтобы получить точное представление о реальной производительности во время выполнения на реальном оборудовании для реальных рабочих нагрузок.

С другой стороны, если один алгоритм превосходит другой на том же оборудовании («на моей машине»), то он обычно дает аналогичные сравнительные результаты на других установках, хотя он может изменяться с постоянным коэффициентом.

2 голосов
/ 27 ноября 2010

Вот интересная статья на тему QueryPerformanceCounter :

http://www.virtualdub.org/blog/pivot/entry.php?id=106

Судя по всему, чувак VirtualDub перестал его использовать, и теперь предпочитает timeGetTime.Хорошее чтение.

Я рекомендую использовать Boost.Date_Time , в частности boost :: posix_time .

1 голос
/ 27 ноября 2010

Источник синхронизации для QPC традиционно никогда не получался из тактовой частоты. Производители материнских плат, тем не менее, пытались сбить пенни или два. Обычно они снимают частоту внутри чипсета. Я слышал о чьей-то машине AMD, которая имеет значение QPF 2 ГГц, опасно близкое к значению, которое вы получите для тактовой частоты процессора после умножения. Только нервничай, если получишь большое значение, подобное этому.

Абсолютное значение QPC не должно никогда быть вашей заботой. Это будет сильно зависеть от качества ядра. Используйте измерения QPC только для поиска дополнительных улучшений в вашем коде.

1 голос
/ 27 ноября 2010

Здесь на самом деле есть две отдельные проблемы:

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

  2. надежность эталонного измерения (при наличии надежных часов) - это более проблематично - если вы работаете над оптимизацией и ищете небольшие улучшения, например, около 10%, то легко ввести в заблуждение эффектом изменения тактовой частоты от Turbo Boost на al. Возможные решения:

    2,1. отключить Turbo Boost и другое масштабирование тактовой частоты

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...