20

特定の時点での CPU サイクルを取得したい。その時点でこの関数を使用します：

static __inline__ unsigned long long rdtsc(void)
{
    unsigned long long int x;
    __asm__ volatile (".byte 0x0f, 0x31" : "=A" (x));
    // broken for 64-bit builds; don't copy this code
    return x;
}

(編集者注: "=A"x86-64 では間違っています。RDXまたはRAX を選択します。32 ビット モードでのみ、必要な EDX:EAX 出力が選択されます。C++ から x86_64 で CPU サイクル カウントを取得する方法を参照してください。)

問題は、 (すべての実行で)常に増加する数を返すことです。あたかも絶対時間を参照しているかのようです。

関数の使い方が間違っていませんか?

4

3 に答える 3

32

スレッドが同じ CPU コア上にある限り、RDTSC 命令はラップアラウンドするまで増加する数値を返し続けます。2GHz CPU の場合、これは 292 年後に発生するため、実際の問題ではありません。あなたはおそらくそれが起こるのを見ないでしょう. それほど長く生きると予想される場合は、コンピューターを、たとえば 50 年ごとに再起動するようにしてください。

RDTSC の問題は、古いマルチコア CPU のすべてのコアで同じ時点で開始する保証がなく、古いマルチ CPU ボードのすべての CPU で同じ時点で開始するという保証がないことです。 .
最近のシステムでは通常、このような問題はありませんが、スレッドのアフィニティを 1 つの CPU でのみ実行するように設定することで、古いシステムでも問題を回避できます。これはアプリケーションのパフォーマンスには良くないため、通常は行うべきではありませんが、ティックを測定する場合は問題ありません。

(別の「問題」は、多くの人が時間を測定するために RDTSC を使用していることです。これはそれが行うことではありませんが、CPU サイクルが必要であると書いたので、それで問題ありません。時間を測定するために RDTSC を使用する場合、驚くべきことがあるかもしれません。省電力やハイパーブーストなど、さまざまな周波数変更テクニックが起動します。実際の時間では、clock_gettimesyscall は Linux で驚くほど優れています。)

rdtscステートメントの中に書くasmだけで、私にとってはうまく機能し、あいまいな16進コードよりも読みやすくなります。それが正しい 16 進コードであると仮定すると (また、クラッシュせず、増え続ける数値を返すこともないので、そのように見えます)、コードは適切です。

コードの一部にかかるティック数を測定したい場合、ティック差が必要な場合は、増加し続けるカウンターの 2 つの値を減算するだけです。uint64_t t0 = rdtsc(); ... uint64_t t1 = rdtsc() - t0;
周囲のコードから分離された非常に正確な測定が必要な場合は、呼び出す前にシリアル化、つまりパイプラインを停止する必要があることに注意してくださいrdtsc(またはrdtscp、新しいプロセッサでのみサポートされているものを使用します) 。すべての特権レベルで使用できるシリアル化命令はcpuid.

コメントのさらなる質問に答えて：

コンピューターの電源を入れると、TSC はゼロから始まります (また、BIOS はすべての CPU のすべてのカウンターを同じ値にリセットしますが、数年前の一部の BIOS は確実にそうしませんでした)。

したがって、プログラムの観点からは、カウンターは「過去の未知の時間」を開始し、CPU が確認するすべてのクロックティックで常に増加します。そのため、そのカウンターを返す命令を今すぐ実行し、後で別のプロセスで実行すると、より大きな値が返されます (その間に CPU が中断またはオフにされていない限り)。カウンターが増え続けるため、同じプログラムの異なる実行はより大きな数値を取得します。いつも。

さて、clock_gettime(CLOCK_PROCESS_CPUTIME_ID)それは別の問題です。これは、OS がプロセスに割り当てた CPU 時間です。プロセスが開始されると、ゼロから始まります。新しいプロセスもゼロから始まります。したがって、2 つのプロセスが相互に実行されると、非常に類似した、または同一の数値が得られますが、数値が増加することはありません。

clock_gettime(CLOCK_MONOTONIC_RAW)RDTSC の動作に近い (一部の古いシステムでは RDTSC が実装されています)。増加し続ける値を返します。現在、これは通常、HPET です。ただし、これは実際にはtimeであり、 ticksではありません。コンピュータが低電力状態 (通常の 1/2 の周波数で実行中など) になっても、同じペースで進みます。

于 2011-12-22T10:32:53.690 に答える
22

TSC については、紛らわしい情報や間違った情報がたくさん出回っているので、その一部を整理しようと思いました。

Intel が (オリジナルの Pentium CPU で) TSC を最初に導入したとき、(時間ではなく) サイクルをカウントすることが明確に文書化されていました。ただし、当時の CPU はほとんどが固定周波数で動作していたため、文書化された動作を無視して時間を測定するために使用する人もいました (特に Linux カーネル開発者)。彼らのコードは、（電力管理などのために）固定周波数で実行されない後の CPU で壊れました。その頃、他の CPU メーカー (AMD、Cyrix、Transmeta など) は混乱し、一部はサイクルを測定するために TSC を実装し、一部は時間を測定するために実装し、一部は (MSR を介して) 構成可能にしました。

その後、「マルチチップ」システムがサーバーでより一般的になりました。さらにその後、マルチコアが導入されました。これにより、異なるコアの TSC 値にわずかな違いが生じました (起動時間が異なるため)。しかし、さらに重要なことは、CPU が異なる速度で実行されていることが原因で (電源管理やその他の要因により)、異なる CPU の TSC 値に大きな違いが生じることにもなりました。

最初から間違った使い方をしようとしていた人々 (サイクルではなく時間を測定するために使用していた人々) は多くの不満を漏らし、最終的には CPU メーカーに TSC をサイクルではなく時間を測定するように標準化するよう説得しました。

もちろん、これは混乱でした。たとえば、すべての 80x86 CPU をサポートしている場合、TSC が実際に何を測定するかを判断するだけでも、多くのコードが必要です。また、さまざまな電源管理テクノロジ (SpeedStep などを含むが、スリープ状態なども含む) は、さまざまな CPU でさまざまな方法で TSC に影響を与える可能性があります。そのため、AMD は CPUID に「TSC 不変」フラグを導入して、OS に TSC を使用して時間を正しく測定できることを伝えました。

最近のすべての Intel および AMD CPU は、しばらくの間このようなものでした.TSC は時間をカウントし、サイクルをまったく測定しません. つまり、サイクルを測定する場合は、(モデル固有の) パフォーマンス監視カウンターを使用する必要がありました。残念ながら、パフォーマンス監視カウンターはさらに混乱しています (モデル固有の性質と複雑な構成のため)。

于 2011-12-22T15:24:26.860 に答える