タグ付けされた質問 「cpu-architecture」

Pentium Pro（P6マイクロアーキテクチャ）から、Intelはマイクロプロセッサを再設計し、古いCISC命令の下で内部RISCコアを使用しました。Pentium Pro以降、すべてのCISC命令は小さな部分（uops）に分割され、RISCコアによって実行されます。 当初、Intelが新しい内部アーキテクチャを非表示にし、プログラマに「CISCシェル」の使用を強制することを決定したことは明らかでした。この決定のおかげで、Intelは互換性を損なうことなくマイクロプロセッサアーキテクチャを完全に再設計することができました。それは合理的です。 しかし、私は1つのことを理解していません。なぜ、Intelは内部RISC命令セットを何年も隠しているのですか？古いx86CISC命令セットを使用するように、プログラマーにRISC命令を使用させないのはなぜですか？ Intelが下位互換性を長期間維持している場合（64ビットモードの隣に仮想8086モードがまだあります）、CISC命令をバイパスして、RISCコアを直接使用するようにプログラムをコンパイルできないのはなぜですか？これにより、x86命令セットをゆっくりと放棄する自然な方法が開かれますが、これは最近非推奨になっています（これが、Intelが内部でRISCコアを使用することを決定した主な理由ですよね？）。 新しいIntelの「Corei」シリーズを見ると、AVX、SSE4などを追加したCISC命令セットのみが拡張されていることがわかります。

89 x86  intel  cpu-architecture 

perf statの結果で、stalled -cycles-frontendとstalled-cycles-backendの意味を知っている人はいますか？インターネットで検索しましたが、答えが見つかりませんでした。ありがとう $ sudo perf stat ls Performance counter stats for 'ls': 0.602144 task-clock # 0.762 CPUs utilized 0 context-switches # 0.000 K/sec 0 CPU-migrations # 0.000 K/sec 236 page-faults # 0.392 M/sec 768956 cycles # 1.277 GHz 962999 stalled-cycles-frontend # 125.23% frontend cycles idle 634360 stalled-cycles-backend # 82.50% …

83 linux  performance  optimization  computer-architecture  cpu-architecture 

CまたはC ++コードをコンパイルするときにCPUアーキテクチャを見つけるための最も信頼できる方法は何ですか？私の知る限り、異なるコンパイラは、（非標準のプリプロセッサの定義の独自のセットを持っている_M_X86MSVSで、__i386__、__arm__GCCで、など）。 構築しているアーキテクチャを検出する標準的な方法はありますか？そうでない場合は、すべてのボイラープレートを含むヘッダーなど、さまざまなコンパイラーのそのような定義の包括的なリストのソースはあり#ifdefますか？

82 c++  c  detection  cpu-architecture  compile-time 

コードの一部に対して非常に一貫性のあるランタイムを取得するためにいくつかの実験を行っています。私が現在計時しているコードは、かなり恣意的なCPUバウンドのワークロードです。 int cpu_workload_external_O3(){ int x = 0; for(int ind = 0; ind < 12349560; ind++){ x = ((x ^ 0x123) + x * 3) % 123456; } return x; } 割り込みを無効にし、上記の関数の10回の試行を実行するカーネルモジュールを作成しました。各試行のタイミングは、前後のクロックサイクルカウンターの差をとることによって計っています。その他の注意事項： マシンはARM Cortex-A72であり、それぞれ4コアの4ソケット（それぞれに独自のL1キャッシュがある） クロック周波数スケーリングはオフです ハイパースレッディングはサポートされていません マシンは、一部の最低限のシステムプロセスを除いて、実質的に何も実行していません 言い換えると、システム変動のほとんど/すべての原因が説明されていると私は信じています。特に、割り込みを無効にしてカーネルモジュールとして実行した場合spin_lock_irqsave()、コードは実行間でほぼ同じパフォーマンスを達成するはずです（たぶん小さなパフォーマンスヒット）最初の実行では、いくつかの命令が最初にキャッシュにプルされますが、それだけです）。 実際、ベンチマークされたコードがでコンパイルされた場合、-O3平均で〜135,845,192のうち最大で200サイクルの範囲があり、ほとんどの試行でまったく同じ時間がかかりました。ただし、を使用してコンパイルする-O0と、範囲は262,710,916のうち158,386サイクルまで増加します。範囲とは、最長実行時間と最短実行時間の差を意味します。さらに、-O0コードでは、どの試行が最も遅い/最も速いかについて一貫性があまりありません-直感的には、ある場合には、最も速いものが最初であり、最も遅いものが直後のものでした！ それで、-O0コードの変動性のこの高い上限を引き起こしている可能性があるものは何ですか？アセンブリを見ると、-O3コードはすべて（？）をレジスタに格納しているようですが、-O0コードにはたくさんの参照spがあるため、メモリにアクセスしているようです。しかし、それでも、すべてがL1キャッシュに取り込まれ、かなり確定的なアクセス時間でそこに座っていることが期待されます。 コード ベンチマーク対象のコードは上記のスニペットにあります。組み立ては下にあります。とgcc 7.4.0以外はフラグなしでコンパイルされました。-O0-O3 -O0 0000000000000000 <cpu_workload_external_O0>: 0: d10043ff sub sp, sp, …

9 performance  assembly  arm  cpu-architecture  performancecounter 

Linux上の現在のCPUのデータキャッシュ階層の正確な説明を取得しようとしています。個々のL1 / L2 / L3（およびおそらくL4）データキャッシュのサイズだけでなく、それらが分割または共有される方法もコア。 たとえば、私のCPU（AMD Ryzen Threadripper 3970X）では、各コアには独自の32 KBのL1データキャッシュと512 KBのL2キャッシュがありますが、L3キャッシュはコアコンプレックス（CCX）内のコア間で共有されます。つまり、それぞれ16 MBの8つの異なるL3キャッシュがあります。 このWindows上のCPU-Zのスクリーンショットの「キャッシュ」セクションは、基本的に私が探しているものです。 Windowsでこれらの情報を取得しても問題ありませんGetLogicalProcessorInformation()。 ただし、Linuxでは、sysconf()L1およびL2データキャッシュのコアごとのキャッシュサイズ（_SC_LEVEL1_DCACHE_SIZEおよび_SC_LEVEL2_DCACHE_SIZE）、またはL3キャッシュの合計サイズ（_SC_LEVEL3_CACHE_SIZE）のどちらかしか表示されないようです。 編集：VMWareでの lstopoの出力。仮想マシンには8つのコアがあります。L1およびL2キャッシュ情報は問題ありませんが、L3キャッシュサイズが正しくないようです。

9 c++  c  linux  cpu-architecture  cpu-cache 

まあ上でインテル固有のガイドには、「sqrtsd」と呼ばれる命令は18サイクルのレイテンシーを持っていることが述べられています。 私はそれを自分のプログラムでテストしました。たとえば、0.15を入力として受け取った場合は正しいです。しかし、256（または任意の2 ^ x）の数をとると、レイテンシはわずか13になります。なぜですか？ 私が持っていた1つの理論は、13は「sqrtss」のレイテンシであり、「sqrtsd」と同じですが32ビット浮動小数点で行われるため、プロセッサは256ビットが32ビットに適合し、そのバージョンを使用することを理解するのに十分スマートであるということです一方、0.15は有限の方法で表現できないため、完全な64ビットが必要です。 私はインラインアセンブリを使用してそれをやっています、これはgcc -O3と-fno-tree-vectorizeでコンパイルされた関連部分です。 static double sqrtsd (double x) { double r; __asm__ ("sqrtsd %1, %0" : "=x" (r) : "x" (x)); return r; }

9 c  performance  assembly  intel  cpu-architecture