未回答とさせていただきます。申し訳ありませんが、私の知る限り、これに対する良い答えはありません。RDTSC非常に特定の条件下で特定のCPUでのみ動作し、オペレーティングシステムの助けなしでは解釈が困難で不可能な値を返します。 Intel コンパイラ)。
長い話は次のとおりです。
このRDTSC命令には、アプリケーションで追跡するのが非常に難しいセマンティックな変更の長い歴史があります。古い Intel および AMD CPU では、TSC が内部サイクルをカウントするだけでした。つまり、可変周波数 (省電力モードなど) では、アプリケーションへの通知なしに周波数が変更される可能性がありました。2 つのタイムスタンプ間で頻度が複数回変更される可能性があり、これが発生したことを知る方法がありませんでした。
一部の CPU または BIOS のバージョンでは、システム管理モードで TSC を一時停止できましたが、そうでないバージョンもありました。最初の動作は、TSC が壁時計の時間には役に立たないことを意味し、もう 1 つの動作は、TSC がベンチマークに役に立たないことを意味しました。前回これを見たときは、別の時計と比較して大きなジャンプを探す以外に、これを検出する方法がありませんでした。
一部の CPU では、システム内の複数の CPU 間で TSC やその周波数が同期されていませんでした。つまり、オペレーティング システムがプロセスを CPU 間で移動する場合、読み取った TSC 値は、最良の場合にはまったく役に立たず、最悪の場合には微妙に誤解を招くものになります。
最近の傾向と安定性の約束は、同期されたタイマーと同期された静的周波数を持つことでした (クロックは温度に敏感であるため達成できませんが、それは別の話です)。やっとRDTSCを問題なく安定して使えるようになりました。
RDTSCしかしその後、Intel は、それがもはやシリアル化命令ではないと突然判断して、別のカーブボールを投げました(おそらく意識的な決定ではない可能性が高く、Intel が「シリアル化することが文書化されていない」と言って逃げようとしているのはおそらく間違いです)。これは、コードでタイマーを 2 回読み取ると、2 番目の値が最初の値よりも低くなる可能性があることを意味します。さらに悪いことに、ベンチマークしているコードのほとんどは実際には実行されていません。新しいRDTSCP命令はこの問題を「解決」しますが、どの CPU が実際にそれを実装しているか、どの CPURDTSCが使用できる十分な信頼性を備えているか、どの CPU をあきらめてより良いタイム ソースを使用する必要があるかを把握する必要があります。
これに加えて、2 つの呼び出しの間でコードが実際に実行されているRDTSCかどうか、またはコンテキストが切り替えられているかどうかはわかりません。したがって、オペレーティング システムが提供するタイミング機能に固執し、プロセスの実行時間を測定することをお勧めします。これらのタイミング機能は遅くなりますが、オペレーティング システムはこれらの問題をすべて、あなたが理解できるよりもはるかにうまく解決している可能性が高いです。おまけとして、NTP やその他の時刻同期メカニズムを使用している場合は、クロック周波数が実際の秒にはるかに近くなります。これは、アプリケーションとして認識できない長期および短期の周波数ドリフトも追跡するためです。