問題タブ [nehalem]

WinXP または Win2003 で 32 ビット コードを実行する必要があります。Nehalem Xeons (5500 シリーズ) が最速のはずですが、メモリ配置がどうなるかはわかりません。私は2つの部分について確信が持てません：

1. 最高速度のメモリ セットアップを取得するには、少なくとも 6 GB の RAM をインストールする必要があります (各 CPU に 3 スティックを動作させるため)。32 ビット OS (WinXP または 2003) で最大のパフォーマンスが得られるようにメモリがインターリーブされていますか? (数 GB の RAM を浪費しても問題ありません)。
2. Win2003 の NUMA サポートは Xeon 5500 で動作しますか? (もしそうなら、WinXP ではなく Win2003 を使うべきだと思いますか?)

Intel の Nehalem マイクロアーキテクチャに基づくデュアル プロセッサとトリプル チャネル RAM を搭載したワークステーションで 32 ビット Windows XP を実行する予定です。XP の RAM は 4 GB に制限されていますが、4 GB 以上をインストールしても機能しますが、公開されるのは 4 GB (またはわずかに少ない) だけであると理解しています。

私の質問は次のとおりです。6 GB の RAM が 6 つの 1 GB モジュールにインストールされていると仮定すると、Windows が実際にそのアドレス空間にマップする物理的な 4 GB はどれですか?

特に：

• すべてのメモリ チャネルを利用して、6 つの 1 GB モジュールすべてを使用しますか? (私の推測ではそうです。グループ内の個々のモジュールへのマッピングはハードウェアで行われると思います。)

• 2 つの NUMA ノードのそれぞれに 2 GB のアドレス空間をマップするか (各プロセッサには独自のメモリ インターフェイスがあるため)、または一方のプロセッサが 3 GB の RAM に高速アクセスし、もう一方のプロセッサには 1 GB しかありませんか?

ありがとう！

Nehalem プロセッサで実行されるマルチスレッド Java アプリケーションを作成しています。ただし、4 つのスレッドから開始すると、アプリケーションのスピードアップがほとんど見られないという問題があります。

私はいくつかの簡単なテストを行いました。大きな配列を割り当て、配列内のランダムなエントリにアクセスするだけのスレッドを作成しました。そのため、スレッド数を実行しても、実行時間は変化しません (使用可能な CPU コアの数を超えていないと仮定します)。しかし、私が観察したところ、1 つまたは 2 つのスレッドを実行するとほぼ同じ時間がかかりますが、4 つまたは 8 つのスレッドを実行すると大幅に遅くなります。したがって、アプリケーションでアルゴリズムと同期の問題を解決しようとする前に、達成できる最大の可能な並列化を見つけたいと思います。

JVM オプションを使用-XX:+UseNUMAしたので、対応するスレッドの近くのメモリに配列を割り当てる必要があります。

PS スレッドが単純な数学的計算を行っている場合、4 スレッドでも 8 スレッドでも時間の低下はなかったので、スレッドがメモリにアクセスしているときに問題があると結論付けました。

助けやアイデアをいただければ幸いです。

編集

返信ありがとうございます。私は自分自身を十分に説明していないことがわかりました。

アプリケーションで同期の問題を解消する前に、実現可能な最適な並列化をチェックする簡単なテストを行いました。コードは次のとおりです。

ご覧のとおり、このミニテストでは同期がまったく行われず、配列の割り当てもスレッド内にあるため、すばやくアクセスできるメモリのチャンクに配置する必要があります。また、このコードにはメモリ競合はありません。それでも 4 スレッドの場合、実行時間は 30% 低下し、8 スレッドでは実行速度が 2 倍遅くなります。コードからのように、すべてのスレッドが作業を完了するまで待ちます。スレッドの作業は独立しているため、スレッドの数は実行にかかる合計時間に影響しません。

マシンには 2 つのクアッドコア ハイパースレッド Nehalem プロセッサ (合計 16 個の CPU) がインストールされているため、8 つのスレッドでそれぞれがその CPU を排他的にキャッチできます。

より小さな配列 (20K エントリ) でこのテストを実行しようとしたとき、4 スレッドの実行時間の低下は 7% で、8 スレッドでは 14% であり、満足のいくものでした。しかし、大きな配列（40M エントリ）でランダム アクセスを実行しようとすると実行時間が劇的に増加するため、メモリの大きなチャンク（キャッシュ メモリに収まらないため？）が非アクセスでアクセスされるという問題があると思います。 -効率的な方法。

これを修正する方法はありますか？

これにより、質問がより明確になることを願っています。ありがとうございます。

12 GB の RAM (6x2GB) を搭載した 2 プロセッサの Nehalem Xeon サーバーの場合、メモリ アドレスは物理メモリ モジュールにどのようにマップされますか?

3 つの同一のメモリ モジュールを備えた単一のプロセッサ Nehalem では、メモリ帯域幅を向上させるためにアドレス空間がモジュール全体にストライプ化されると想像できます。しかし、どのようなストライプサイズでしょうか? そして、2 番目のプロセッサ (+ メモリ) はその状況をどのように変えるのでしょうか?

cacti インターフェイスの「Number of Banks」という用語に出くわしたとき、さまざまなキャッシュ構成のアクセス時間を調べていました。

バンク数は、キャッシュ内のインターリーブされたモジュールの数であり、キャッシュの帯域幅とキャッシュへの並列アクセスの数を増加させます。

このコンテキストでは、Nehalem アーキテクチャのキャッシュ内のバンクの数を見つけたいと考えていました。私はこのことをグーグルで検索しましたが、有用なものは見つかりませんでした。

ここでの私の推論は次のとおりです。

1. L1 データと命令キャッシュには単一のバンクが必要です。アクセス粒度は、ここでの単語です。
2. L2 キャッシュは、L1 データと命令キャッシュのミスをサポートします。したがって、2 つのバンクをサポートする必要があります。
3. 通常、L3 キャッシュはシステム内のすべてのコアで共有されるため、多数 (32) のバンクが必要です。

私の直感は正しいですか?? さらに、バンクの数によって、データ/プログラムの構造が変わりますか (理想的にはそうすべきではありませんが、それでも ...)??

NUMA マルチコア アーキテクチャでコア間通信を削減する方法を強調できる人はいますか。ケース スタディ Intel NEHALEM マイクロ アーキテクチャ。

私の理解では、ハードウェアのプリフェッチは決してページの境界を越えることはありません。ソフトウェア プリフェッチに同じ制限があるかどうか、つまり、将来の TLB ミスを回避するためにソフトウェア プリフェッチを使用できるかどうか疑問に思っています。調べてみると可能のようですが、ドキュメントに決定的なものが見つからなかったので、参考にしてください。

Nehalem、Sandy Bridge、Westmere に特に興味があります。

PAPI 高レベル API を使用して、配列をループする単純なプログラムで TLB ミスをチェックしていますが、予想よりも大きな数が表示されます。

他の単純なテスト ケースでは、結果は非常に合理的であるように見えます。そのため、結果は本物であり、余分なミスはハードウェアのプリフェッチなどによるものだと思います。

誰かが数値を説明したり、PAPI の使用におけるエラーを指摘したりできますか?

印刷された数値は 32 の範囲、または少なくともその倍数であると予想しましたが、一貫して 93 以上の結果が得られます (一貫して 96 を超えるとは限りません。つまり、反復ごとに単純に 3 ミスするわけではありません)。他に何もないコアに固定して実行しています（タイマー割り込みを除く）。

私は Nehalem を使用しており、巨大なページを使用していないため、DTLB には 64 のエントリ (L2 には 512) があります。