問題タブ [rdtsc]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
c - 最初のprintfに時間がかかるのはなぜですか?
私は高精度タイマーで遊んでいましたが、最初のテストの1つは、rdtscを使用してprintfを測定することでした。以下は私のテストプログラムとその出力です。私が気付いたのは、printfを初めて実行すると、最初の印刷では、後続の印刷よりも一貫して約25倍の時間がかかるということです。何故ですか?
そして出力:
(参考までに、これはOSXでgccを使用してコンパイルされました)
hardware - 最新のプロセッサで RDTSC が仮想化された命令であるのはなぜですか?
私は RDTSC を研究しており、VirtualBox や VMWare などの仮想マシンのために RDTSC を仮想化する方法について学んでいます。Intel/AMD がこの命令の仮想化に苦労したのはなぜですか?
トラップを使用して簡単にシミュレートできるように感じますが、非常に一般的な命令ではありません (テストしたところ、ハードウェア RDTSC 仮想化が無効になっている仮想マシンでの一般的な使用では、顕著な速度低下はありません)。
ただし、非常に高速に実行できることが重要でない限り、Intel/AMD がこの命令を仮想化ハードウェアに追加するのに苦労することはなかったことを私は知っています。
誰かが理由を知っていますか?
c - rdtsc、サイクルが多すぎます
このコードは、-O0 -O1-O2-O3最適化を使用してgccでコンパイルしました。そして、私は常に2000-2500サイクルを取得します。誰かがこの出力の理由を説明できますか?これらのサイクルをどのように過ごすのですか?
最初の関数「ティック」が間違っています。これは正しいです。
関数「ティック」の別のバージョン
これは-O3のアセンブリコードです
これはCPUです
linux - RDTSC を使用して CPU サイクルを取得する - RDTSC の値が常に増加するのはなぜですか?
特定の時点での CPU サイクルを取得したい。その時点でこの関数を使用します:
(編集者注: "=A"
x86-64 では間違っています。RDXまたはRAX を選択します。32 ビット モードでのみ、必要な EDX:EAX 出力が選択されます。C++ から x86_64 で CPU サイクル カウントを取得する方法を参照してください。)
問題は、 (すべての実行で)常に増加する数を返すことです。あたかも絶対時間を参照しているかのようです。
関数の使い方が間違っていませんか?
c++ - cpp linux:rdtscについて
コードで次の関数を使用しています。
この関数は、前回の起動以降のティック数を返しますか?この関数に関するドキュメントはどこにありますか?
ubuntu - Ubuntuの/sys/ kernel / debug/tracingからの時間の調整
プログラムのパフォーマンスについて、Ubuntu10.10マシン上の複数のソースからプログラムでデータを収集しようとしています。他のすべてのソースについては、RDTSC x86命令を使用してそれらを収集し、gettimeofdayを使用してそれらをスケーリングして、絶対時間の秒に変換することができました。ただし、これらのデータソースを/ sys / kernel / debug / traceingでsched_switchトレースを実行する出力と調整しようとすると、問題が発生します。これは、表示されている出力が不明な時間から数秒とマイクロ秒であるためです。
すでに行った手順:
1。Linuxカーネルも内部でRDTSCを使用していると判断しましたが、収集したオフセットを追加しましたが、取得する機能がないようです。これはコアごとにも行われます。つまり、4つのコアすべてを試して、最適なコアを決定する必要があります。これは、この問題の解決策としては不十分なようです。
2.ロギングをオンにしてRDTSC時間を変換して、少なくとも変換自体が一貫しているかどうか(つまり、一定のオフセットがあるかどうか)を確認しましたが、実行中はスケールが一定に保たれていないようです。
3. clock_gettime(CLOCK_MONOTONIC、...)は非常によく似た値を持っているように見えますが、常に例外のない量(約0.5秒)ずれており、完全に一貫しているようにも見えません。
他のデータソースが時間を収集する方法を必要なものに変更できる場合(パフォーマンスを重視しない場合)、トレースの時間と収集する時間の間で調整するために、どのように時間を収集する必要がありますか?出力をRDTSCに変更する何らかの方法があるので、それを使用できますか、それとも、トレースに出力されているものと同じ時間を取得するために実行できるシステムコールがありますか?助けてくれてありがとう。
python - Python で rdtsc を読む
Python で x86 CPU のタイムスタンプ カウンターを読み取る方法はありますか?
rdtscp
使うことは悪いことであり、使うことはさらに悪いことだと私は知っていrdtsc
ます。しかし、その値、または少なくともその値の近似値が本当に必要であることを信じてください。
何か案は?
c++ - GCC x86でRDTSCを使用してクロックサイクルをカウントする方法は?
Visual Studioを使用すると、以下に示すように、プロセッサからクロックサイクルカウントを読み取ることができます。GCCで同じことを行うにはどうすればよいですか?
x86 - rdtscの戻り値は、AtomN450では_always_mod 10==0です。
私のE8200ボックスではこれは発生しませんが、Atom N450ネットブック(両方ともOpenSuse 11.2を実行)では、CPUのTSCを読み取るたびに、戻り値はmod 10 == 0
、つまり、余りが10で割り切れない状態です。RDTSCを使用しています興味深いコードがかかる時間を測定するための値ですが、デモンストレーションの目的で、この小さなプログラムを作成しました。
(私は通常、変換に独自のルーチンを使用しますが、読者がエラーが存在する可能性があることを示唆しないようにするために、ここではprintf()を使用しています。)
上記のコードでは、出力は(たとえば)次のようになります。
簡単にわかるように、デルタは妥当な量で変化します。しかし、目立つのは(共謀しているとは言えませんが;-)、最下位の10進数が常に0であるということです。
私はこの現象を2年以上観察してきましたが、StackOverflowはこの問題を公開する最初のアドレスではありません。しかし、私はまだどこにも合理的な答えを得ることができませんでした。私たち(私や他の人々)が思いついたアイデアは、
- TSCは10サイクルごとにのみインクリメントされますが、その後10ずつインクリメントされます。
- TSCは内部で正しく更新されますが、10サイクルごとにのみ外部に反映されます。
- TSCはサイクルごとに10ずつ増加します。
ただし、これらの点はどれも実際には意味がありません。E8200(現在は故障しています)でそのようなプログラムを実際に実行して、デルタの大きさのオーダーが上記の出力のオーダーと同じか、それとも10分の1にすぎないかを確認する必要があります。(ボランティアはいますか?)
グーグルは役に立たなかった、インテルのマニュアルも役に立たなかった。
他の人と話し合うとき、同じ行動を経験した人は他にいませんでした。カーネルと関係がある場合、少なくとも3つのバージョンが影響を受けましたが、カーネルはそれと何の関係がありますか?
ネットブックも稼働していて、新しいマザーボードが戻ってきました。これは、新しいCPUを意味するため、N450の少なくとも2つの個別のエンティティが影響を受ける必要があります。
また、クロック周波数の変化に対する対策を講じ(クロックを固定した周波数に関係なく、値は予想される範囲でのみ変化しました(図と同じ))、HTをオフにしましたが、これらは実際にそれらを防ぐのではなく、他のいくつかの最下位桁。しかし、念のために。
さて、誰かが自分のマシンでプログラムを実行したい場合、コマンドラインは次のとおりです(ソースをファイルに保存する場合rdtsc.s
):
gccフロントエンドでビルドするには、つまり
_start:
ラベルを追加(またはラベルを置き換える)しmain:
て、グローバルにする必要があります。
[更新(2012-09-15〜21:15 UTC):実際には以前にもこれを行うことができました:の前後にTSCを取得させるだけでsleep(1)
、1,666,000,000をわずかに超えるデルタが得られます。上記のリストのポイントが間違っています。しかし、それでも私は完全な精度が得られない理由がわかりません。/アップデート]
c++ - rdtscp、rdtscの違い:メモリとcpuid / rdtsc?
パフォーマンスの監視にtscを使用しようとしており、命令の並べ替えを防止したいとします。
これらは私たちのオプションです:
1: rdtscp
シリアル化呼び出しです。rdtscpへの呼び出しの前後の並べ替えを防ぎます。
ただし、rdtscp
新しいCPUでのみ使用できます。したがって、この場合はを使用する必要がありますrdtsc
。ただしrdtsc
、シリアル化されていないため、単独で使用してもCPUによる並べ替えが妨げられることはありません。
したがって、次の2つのオプションのいずれかを使用して、並べ替えを防ぐことができます。
2:cpuid
これはとの呼び出しrdtsc
です。cpuid
シリアル化呼び出しです。
3:これはclobberリスト内のrdtsc
withの呼び出しであり、並べ替えを防ぎますmemory
3番目のオプションについての私の理解は次のとおりです。
呼び出しを行うと__volatile__
、オプティマイザがasmを削除したり、asmの結果を必要とする(または入力を変更する)可能性のある命令間で移動したりするのを防ぎます。ただし、関係のない操作に関しては移動する可能性があります。だから__volatile__
十分ではありません。
コンパイラのメモリが破壊されていることを通知します: "memory")
。"memory"
clobberは、GCCがasm全体でメモリの内容が同じままであるという仮定を立てることができないため、その周りで並べ替えられないことを意味します。
だから私の質問は:
- 1:私の理解
__volatile__
と"memory"
正しいですか? - 2:次の2つの呼び出しは同じことをしますか?
- 3:使用
"memory"
は、別のシリアル化命令を使用するよりもはるかに簡単に見えます。なぜ誰かが2番目のオプションよりも3番目のオプションを使用するのでしょうか?