プログラムでアルゴリズムがどのくらい速く実行されるかを決めるときは、常にQueryPerformanceFrequency（）と組み合わせてQueryPerformanceCounter（）を使用しましたが、コアi5/7アーキテクチャ？コアi5/7アーキテクチャーでのプログラム実行時間の決定
私のアルゴリズムの途中でターボブーストが突然起きる可能性があります。私の時計の周波数がもはや一定ではないか、これは本当に問題ではないので、突然私のパフォーマンスタイマーは正確でなくなりましたか？それが問題であれば、アルゴリズムを正確に実行するにはどうすればよいでしょうか？
単純に言えば、何かが起こる可能性があります。現代のCPUは単なるプレーンなので、実世界の性能を見積もってやるのは難しいです。これは、最新のIntel x86-64 cpusだけに限定されず、8ビットPICマイクロコントローラにも等しく適用されます。
妥当なことは、もっとテストすることだけです。実際のワークロードに対する実際のハードウェアでの実際の実行時パフォーマンスについての正確な考えを得るには、多くの繰り返しテストを実行する必要があります。
一方、あるハードウェアが同じハードウェア（別のマシン上）上の別のアルゴリズムよりも優れている場合は、他の設定でも同様の比較結果が得られます。
本当に私はCPUサイクルの平均回数を見て、アルゴリズムで処理するのではなく、周波数で割り、ナノ秒単位で時間を取るべきですか？ – Faken
Boost.Date_Time： long total_nanoseconds（） 残りの数字を切り捨てるナノ秒の合計数を取得 – Hank
Faken：実際に測定しているコアユニットについて考える必要があります。タイミング関数がナノ秒を返す場合は、それを考慮する必要があります。彼らは単に有益ではないので、余分な旋回を行っても意味がありません。 – SingleNegationElimination
はここQueryPerformanceCounterのの件名に興味深い記事です：どうやら
http://www.virtualdub.org/blog/pivot/entry.php?id=106
、VirtualDubの男はそれを使用して停止し、現在timeGetTimeを好みます。良い読書。
は私がBoost.Date_Time、特にブースト:: posix_timeのものを使用することをお勧めします。
二つの別々の問題がここに実際にあります任意のタイミング方法の
信頼性がCPUのクロック周波数が変化（なぜなら例えば、省電力やで蹴っ熱管理の例えばターボ・ブーストを経由して増加または減少のいずれか） - これは他の答えのいくつかで対処されています
ベンチマーク測定の信頼性（これは信頼できる時計です） - これはより困難です - 最適化に取り組み、小さな改善を探しているなら、約10％であれば、Turbo Boostのクロック変動の影響によって誤解を生むのは簡単です。可能な解決策は、
2.1です。 Turbo Boostと他のクロック周波数スケーリングを無効にする
2.2。 QPCのためのクロック速度の変動を平均化するために
タイミングソースは、伝統的にクロック周波数に由来していませんでした十分に長い時間のために実行したベンチマーク。マザーボードの製造元は、1ペニーか2ペナルティを削るために、コーナーを削っています。彼らは通常、どこかのチップセットの内部から周波数をピックオフします。私は、2GHzのQPF値を持つ誰かのAMDマシンが、乗算後にCPUクロックに掛かる値に危険なほど近いことを聞いたことがあります。あなたがそのような大きな価値を得るならば、神経質になるだけです。
QPCの絶対値はではありません。はあなたの心配です。これは、コアの品質に大きく依存することになります。 QPC測定を使用して、コードの段階的な改善を探します。
はいいいえ観測:) – basarat