7.3.2 データ型の選択が性能に与える影響 |
 |
データ型の選択が与えるもう1つ影響としてデータ・アラインメントがあります。アラインメントとは，メモリ内の位置についてのデータの属性です。 VAXシステムのアプリケーションでは多くの場合，データ構造体定義や静的データ領域でバイト・サイズ，ワード・サイズ，およびそれ以上のサイズのデータ型が混在していますが，この結果，自然な境界にアラインされないデータが発生します (アドレスがサイズ(バイト数)の整数倍である場合には，データは自然にアラインされます)。
VAXシステムでもAlphaシステムでも，アラインされていないデータをアクセスすると，アラインされているデータをアクセスする場合より多くのオーバーヘッドが発生します。しかし，VAXシステムでは，アラインされていないデータを使用したときの性能に対する影響を最低限に抑えるためにマイクロコードを使用しています。 Alphaシステムではこのようなハードウェアの支援はありません。したがって，アラインされていないデータを参照すると，フォルトが発生し，システムのPALcodeによって処理しなければならなくなります。フォルトを処理している間，命令パイプラインは停止しなければなりません。したがって，アラインされていないデータを参照したときの性能の低下は， Alphaシステムではきわめて大きくなります。
Alphaシステムのコンパイラが，アラインされていないデータに対する参照をコンパイル時に認識できる場合には，特殊な命令シーケンスを生成することにより，性能の低下を最低限に抑えようとします。この結果，実行時にアラインメント・フォルトが発生するのを防止できます。実行時にアラインされていないデータに対する参照が発生した場合には，アラインメント・フォルトとして処理しなければなりません。
対処方法
データ型の選択がコード・サイズと性能に与える影響を考慮した後，バイトとワードのアクセスのために必要な余分な命令を排除し，アラインメントを改善するために，バイト・サイズとワード・サイズのすべてのデータ宣言をロングワードに変更することを考慮しなければなりません。しかし，データ宣言の変更を考慮する前に，次の要素を考慮してください。
-
アクセスの頻度と繰り返し回数---バイト・サイズまたはワード・サイズのデータが何度も参照される場合には，それをロングワードに変更することにより，参照時に必要となる余分な命令を排除し，アプリケーション・サイズを大幅に削減できます。しかし，バイト・サイズまたはワード・サイズのある特定のデータが何度も参照されるわけではなく，大量のバイト・サイズまたはワード・サイズのデータが存在する場合 (たとえば，データ構造体に同じ属性のデータが何度も繰り返される場合)，このようなデータのデータ型をロングワードに変更すると，大量のメモリが必要となり，これは，各参照で必要となる追加命令の問題より大きな問題になる可能性があります。ロングワードに変更した結果，3バイトが余分に必要になり，そのデータを数千回繰り返すと必要な仮想メモリは大幅に拡大します。したがって，データ宣言を変更する前に，データの使用方法を考慮し，性能を向上するためにどれだけの仮想メモリ(および物理メモリ)を使用できるかを判断しなければなりません。このようなサイズと性能のどちらを重視するかの判断は，設計段階で何度も考慮しなければなりません。
-
相互操作性の必要性---データ・オブジェクトをトランスレートされた構成イメージまたはネイティブなVAX構成イメージと共有する場合には，他の構成要素がデータのバイナリ・レイアウトに依存するため，レイアウトを改善するような変更は不可能です。この場合，コンパイラ(およびVESTユーティリティ)は生成するコード内にアラインされていないデータに対する参照の命令シーケンスを含めることにより，性能に与える影響を最低限に抑えようとします。
データ型の選択を確認する場合には，これらの要因を考慮した上で，次のガイドラインに従ってください。
- 頻繁に参照されるが，何度も繰り返されることのないデータに対しては，バイト・サイズとワード・サイズのフィールドをロングワードに変更してください。特に，性能が重要なフィールドに対しては，このような変更が必要です。
- 頻繁に参照されないが，何度も繰り返されるデータの場合には，変更は望ましくありません。
- 頻繁に参照され，何度も繰り返されるデータの場合には，コード・サイズと性能を注意深く調べた後，判断を下さなければなりません。
- 静的データの場合には，常にバイトのかわりにロングワードを使用してください。この場合，3バイトのメモリが必要になりますが，ロングワードに変更しなければ， 1回の参照で3つの命令(各命令はロングワードで表現されます)が余分に必要となります。
- Alphaシステムのコンパイラの機能を使用して，自然な境界にアラインされていないデータを検出してください。多くのAlphaシステムのコンパイラ (Digital Fortran など) は/WARNING=ALIGNMENT修飾子をサポートします。この修飾子は，自然な境界にアラインされていないデータを確認します。
- 実行時解析ツールであるProgram Coverage and Analyzer (PCA)とOpenVMS Debuggerの機能を利用して，自然な境界にアラインされていないデータを実行時に検出してください。詳しくは，『Guide to Performance and Coverage Analyzer for VMS Systems』と『HP OpenVMS デバッガ説明書』を参照してください。
- 相互操作性の問題がない場合には，Alphaシステムのコンパイラが準備している自然なアラインメントを利用してください。Alphaシステムでは，コンパイラは省略時設定で可能な限りデータを自然な境界にアラインします。VAXシステムでは，コンパイラはバイト・アラインメントを使用します。
Alphaシステムのコンパイラは，VAXシステムと同様のバイト・アラインメントの使用を要求することを許可する修飾子や言語プログラムをサポートしています。たとえば， DEC C for OpenVMS Alphaシステムのコンパイラは/NOMEMBER_ALIGNMENT修飾子をサポートし，また，それに対応した，データ・アラインメントの制御を許可するプラグマもサポートします。詳しくは，DEC C のコンパイラ解説書を参照してください。
例 7-1 で定義したデータ構造体は，これらのデータ型の選択に関する問題を示しています。mystructという構造体定義は，次に示すようにバイト・サイズ，ワード・サイズ，およびロングワード・サイズのデータで構成されます。
struct{
char small;
short medium;
long large;
} mystruct ;
|
VAX Cを使用してコンパイルした場合には，この構造体は 図 7-1 に示すようにメモリにレイアウトされます。
図 7-1 VAX Cの使用による mystructのアラインメント
DEC C for OpenVMS Alphaシステムのコンパイラを使用してコンパイルした場合には， 図 7-2 に示すように，自然なアラインメントを実現するために構造体にパッドが挿入されます。最初のフィールド(small)の後に1バイトのパッドを追加することにより，その後の構造体メンバはどちらもアラインされます。
図 7-2 DEC C for OpenVMS Alphaシステムの使用による mystructのアラインメント
データ構造体の中でバイト・サイズとワード・サイズのフィールドは，アクセスのために複数の命令のシーケンスを必要とします。smallフィールドとmediumフィールドが頻繁に参照され，構造体全体が何度も繰り返されることがない場合には，ロングワード・データ型を使用するようにデータ構造体を再定義することを考慮してください。しかし，フィールドが頻繁に参照されない場合や，データ構造体が何度も繰り返される場合には，バイト参照やワード参照によって発生する性能の低下とメモリ・サイズの拡大のどちらが重要かを判断しなければなりません。
印刷用画面へ
