問題タブ [memory-access]

メモリから、データはアーキテクチャの自然なワードサイズでのみ読み取ることができます。たとえば、32ビットシステムでは、データは4バイトのチャンクでメモリから読み取られます。2バイトまたは1バイトの値がメモリに追加された場合でも、それらの読み取りには4バイトのワードにアクセスする必要があります。（2バイト値の場合、値がワード境界に格納されていれば、2つの4バイトアクセスが必要になることがあります。）

したがって、個々の値へのアクセスは、単一の単語にアクセスする必要がある場合に最速であり、最小限の追加作業（マスキングなど）が必要です。私が正しければ、これが仮想マシン（JVMやAndroidのDalvikObjectなど）がインスタンスの4バイト境界にメンバー変数を配置する理由です。

もう1つの概念は、キャッシュの使いやすさ、つまりローカリティ（L1、L2など）です。多くの値を次々にトラバース/処理する必要がある場合は、それらを互いに近くに（理想的には連続したブロックに）格納することが有益です。これは空間的な局所性です。これが不可能な場合は、少なくとも同じ値に対する操作を同じ期間に実行する必要があります（一時的な局所性-つまり、操作が実行されている間、値がキャッシュに保持される可能性が高くなります）。

私が見る限り、上記の2つの概念は「矛盾する」場合があり、どちらを選択するかは使用シナリオによって異なります。たとえば、連続するデータの量が少ないほど、量が多い（些細な）よりもキャッシュに適していますが、一部のデータでランダムアクセスが一般的に必要な場合は、単語に合わせた（ただしサイズが大きい）構造が有益な場合があります。構造全体がキャッシュに収まります。したがって、局所性（〜arrays）とアライメントの利点のどちらを優先するかは、値の操作方法に依存すると思います。

私にとって興味深いシナリオがあります。入力グラフ（およびその他の補助構造）を配列として受け取るパスファインディングアルゴリズムを想定しましょう。（その入力配列のほとんどは、32767未満の値を格納します。）

パスファインディングアルゴリズムは、配列に対して非常に多くのランダムアクセスを実行します（いくつかのループで）。この意味で、int[]（Android / ARMの）入力データには、アクセス時に値が単語の境界にあるため、が望ましい場合があります。（一方、シーケンシャルトラバーサルが必要な場合は、キャッシュに適している可能性が高いため、特に大きなアレイの場合は、より小さなデータ型が推奨されます。）

ただし、（ランダムにアクセスされる）入力データがとして指定された場合はL1 / L2に適合しshort[]、として指定された場合は適合しない場合はどうなりますint[]か？このような場合、int[]ランダムアクセスの4バイトアラインメントの利点は、キャッシュの使いやすさよりも重要short[]ですか？

もちろん、具体的なアプリケーションでは、比較のために測定を行います。ただし、それは必ずしも上記の質問に答えるとは限りません。

以下は、オペレーティング システム (Gate 2003 OS) の MMU の説明です。

プロセッサは、仮想アドレスから物理アドレスへの変換に 2 レベルのページ テーブルを使用します。両方のレベルのページ テーブルがメイン メモリに格納されます。仮想アドレスと物理アドレスはどちらも 32 ビット幅です。メモリはバイトアドレス指定可能です。仮想アドレスから物理アドレスへの変換では、仮想アドレスの上位 10 ビットが第 1 レベルのページ テーブルへのインデックスとして使用され、次の 10 ビットが第 2 レベルのページ テーブルへのインデックスとして使用されます。仮想アドレスの最下位 12 ビットは、ページ内のオフセットとして使用されます。ページ テーブルの両方のレベルのページ テーブル エントリが 4 a バイト幅であると仮定します。さらに、プロセッサには変換ルックアサイド バッファ (TLB) があり、ヒット率は 96% です。TLB キャッシュは最近、仮想ページ番号と対応する物理ページ番号を使用しました。プロセッサには、ヒット率 90% の物理アドレス キャッシュもあります。メインメモリアクセス時間は10ns、キャッシュアクセス時間は1ns、TLBアクセス時間も1nsです。

質問は:

ヒット率90%のキャッシュとヒット率96%のTLBの関係は？OS が最初にチェックする場所: データまたは命令?

私はEclipseでJavaクローラープログラムを実行しています。デバッガーを有効にしていません。

クロールが完了した後、いくつかの変数を出力しています。しかし、クローラーが完了するまでに時間がかかるため、これらの変数がいつ出力されるかわかりません。

クローラーの実行中にこれらの変数にアクセスしたいのですが、すでにしばらく実行されているため停止したくありません。これらの変数にアクセスするにはどうすればよいですか? ありがとう

私自身の開発 (Mac、iOS) でよくあるデバッグ エラーの 1 つは、EXC_BAD_ACCESS です。その一般性にもかかわらず、その起源と正確な意味は謎のままです。Google はエラーの多くの発生をリストしていますが、私が見つけた唯一の説明は非公式で不完全です.

この例外 (それが適切な用語である場合) は、コードが読み取りおよび/または書き込み権限を持たないアドレス (たとえば、null アドレス、または外部のアドレス) にアクセスしようとしたことを意味します。プロセスのアドレス空間。しかし、これは仮想メモリと保護されたメモリ システムに関する私の以前の経験に基づいた直感的な解釈です。私は EXC_BAD_ACCESS がどこにも文書化されているのを見たことがありません。実際、「誰」がこの例外を私に送っているのかわからない - CPU、Mac OS、UNIX、ランタイム、デバッガー?どのクラスのドキュメントを参照するか)。たとえば、例外とともにリストされている「コード」が何を意味するのか知りたいです。または別の例: 同様の例外の他のクラス (おそらく "EXC_" もタグ付けされています)

EXC_BAD_ACCESS、そのコード、および一般的なセマンティクスの説明は、信頼できる情報源からどこで見つけることができますか? 実際に例外を検出してスローしているのは誰か?

確かにあまり成功していませんが、メモリの配置について学習しようとしています。IBM のこの記事を使用しています。

ダブルバイトメモリアクセスの粒度セクションからのこの抜粋が何を意味するのか、誰か説明してもらえますか?

ただし、アドレス 1 から読み取るとどうなるか注意してください。アドレスがプロセッサのメモリ アクセス境界に均等に収まらないため、プロセッサは余分な作業を行う必要があります。このようなアドレスは、アラインされていないアドレスと呼ばれます。アドレス 1 はアラインされていないため、2 バイトの粒度を持つプロセッサは余分なメモリ アクセスを実行する必要があり、操作が遅くなります。

別のメモリアクセスが順番に行われるのはなぜですか? メモリアクセス境界とはどういう意味で、メモリアクセス境界上にあるのですか?

上位レベルのプログラミング (Objective-C および C++) しか扱っていないため、CPU に関する知識は非常に限られています。どんな助けでも大歓迎です！

ありがとう！

私は何時間もこれを理解しようとしてきましたが、少し頭がおかしくなりました。プログラムを実行するとセグメンテーション違反が発生し続けます。どうすれば修正できますか? 「異なるサイズの整数からポインターを試行しています」という警告も表示されますが、キャスト (int *) を使用すると、まだ警告が表示されます。助けてください...コードは次のとおりです。

私はopenglを学習し、GL.DrawElements（）で使用されるカラー配列、頂点配列、法線配列、およびインデックス配列で構成されるVBOの例を使用しています。構造は次のようになります（ドットは次の要素/アイテムを意味します）：

次のように使用する必要があります。

私はopenclカーネルのバッファのデータをcl-gl-interopとして使用しており、最初のタイプの構造はメインメモリアクセスのパフォーマンスを低下させるストライドメモリアクセスを行うため、「x」のみなどの各要素/アイテムの1つのコンポーネントのみを使用しているため「r」のみ。しかし、2 番目のタイプの構造は、すべてのメモリ バンクを均等に使用しており、私のニーズに適合しています。この種の構造は、opengl 描画操作に使用可能/適していますか?

この質問のタイトルを決めるのに本当に苦労しましたが、うまくできたとは思いません。もし誰かがより良いアイデアを持っているなら、編集ボタンはあなたのものです.

メモリ操作のコストが絶対的に最適なシナリオで 3 ～ 4 サイクル、潜在的にそれ以上であること、およびメモリ バスよりも「狭い」データの読み取りが最適ではないことを考慮すると、現在生成されているアセンブリ言語の構造は最適ではありません。それも？

登録操作にかかる時間は大幅に短縮されます。そのため、式の前に式を評価して迅速に実行するために必要なすべてのデータをアセンブリがフェッチしないのはなぜでしょうか。これにより、スレッドの切り替えが減り、プロセッサが他のスレッドを実行できるようになります。

最終的に、15 サイクルの CPU 使用があります。

11 サイクルが使用され、これは 25% の改善です。また、メモリは専用のオンチップ ハードウェア コントローラによってフェッチされ、はるかに長い時間アイドル状態になるため、実際の CPU は 3 サイクルだけビジーになります。

最初の「例」でもデータを待っている間にCPUが他のコードの実行をスケジュールできると思いますが、ウィンドウがはるかに短く、コンテキストを切り替えるためのサイクルペナルティがあれば、ほとんど価値がないと思います.2番目の例このアプローチは、より多くのレジスターを消費しますが、全体的な CPU パフォーマンスが向上するはずです。結局のところ、最新のプロセッサにはすべて少なくとも 16 個のレジスタがあり、現在の世代の新しいモバイル デバイス ARM チップでさえ 32 個のレジスタがあります。では、なぜ保守的なのでしょうか。おそらく、コンパイラは 8 レジスタ マシンの時代にまだ残っているのでしょうか?

この仮定は当てはまりますか、それとも現在の CPU アーキテクチャはそのようなメカニズムを利用するように設計されていないのでしょうか? CPU がデータを待機している間、他のコードを実行できると仮定します。特に最新のプロセッサのほとんどが順不同であることを考慮すると、最終的に最悪のシナリオでは、データの取得に同じ時間を無駄にしますが、すべてのデータがあれば、コード フラグメントをより高速に実行できるため、プロセッサが停止する時間が短くなります。