質問が愚かに聞こえる場合は申し訳ありません。私はデータ アライメントの問題を漠然としか認識しておらず、64 ビット プログラミングを行ったことはありません。現在、32ビットのx86コードに取り組んでいます。int の配列に頻繁にアクセスします。1 つの 32 ビット整数が読み取られる場合があります。場合によっては 2 つ以上読み取られることもあります。ある時点で、コードを 64 ビットにしたいと考えています。intこの int 配列をorとして宣言する必要があるかどうかはわかりませんlong int。整数の幅を同じに保ちたいので、違いを心配する必要はありません。自然な単語に揃えられていないアドレスの読み取り/書き込みが遅くなる可能性があるのではないかと心配しています。
質問する
620 次
4 に答える
8
ミスアライメント ペナルティは、ロードまたはストアがアライメント境界を超える場合にのみ発生します。境界は通常、次のうち小さい方です。
- ハードウェアの自然なワード サイズ。(32 ビットまたは 64 ビット*)
- データ型のサイズ。
64 ビット (8 バイト) アーキテクチャで 4 バイト ワードをロードする場合。8 バイトでアラインする必要はありません。4 バイトでアラインする必要があるだけです。
同様に、任意のマシンで 1 バイトの char をロードしている場合、アラインする必要はまったくありません。
*SIMD ベクトルは、より大きな自然なワード サイズを意味する可能性があることに注意してください。たとえば、16 バイトの SSE には、x86 と x64 の両方で 16 バイトのアライメントが必要です。(明示的なミスアラインのロード/ストアを除く)
つまり、データの配置について心配する必要はありません。言語とコンパイラは、ユーザーが心配する必要がないようにかなり懸命に努力します。
したがって、自分にとって最も意味のあるデータ型に固執してください。
于 2012-09-16T21:00:06.607 に答える
3
64 ビット x86 CPU は、32 ビット値を効率的に操作できるように、依然として大幅に最適化されています。64 ビット オペレーティング システムでも、32 ビット値へのアクセスは、少なくとも 64 ビット値へのアクセスと同じくらい高速です。実際には、消費されるキャッシュ領域とメモリ帯域幅が少なくなるため、実際には高速になります。
于 2012-09-16T20:59:00.133 に答える
1
ここで利用できる多くの良い情報があります: パフォーマンス 32 ビット対 64 ビット演算
さらに詳しい情報はhttps://superuser.com/questions/56540/32-bit-vs-64-bit-systemsで、5% で最悪の速度低下が見られたと答えています (個々の操作ではなく、アプリケーションの観点から) ）。
短い答えはノーです。パフォーマンスに影響はありません。
于 2012-09-16T20:56:37.790 に答える
1
任意のメモリ位置にアクセスするたびに、キャッシュ ライン全体が L1 キャッシュに読み込まれ、そのライン内のあらゆるものへの後続のアクセスは可能な限り高速になります。32 ビット アクセスがキャッシュ ラインをまたがらない限り (32 ビット アライメントの場合はそうなりません)、64 ビット アクセスと同じくらい高速になります。
于 2012-09-16T21:02:36.693 に答える