アライメント
通常の業務ソフトや軽いソフトなどは別に気にする必要性はあまりありませんが、
ＣＰＵを最大限に活かしたいゲームなど、高速処理が売りのソフトなどは
気にしながら作成しないと、痛い目を見ます。
ですが、VCの場合だと勝手にアライメントを整えてくれているように見えるのですが･･･*1
そもそもアライメントとは、ＣＰＵが一回の処理で引っ張ってこれるデータサイズです。
アライメントがずれるとは、
１６バイトアライメントのＣＰＵに１７バイトの構造体を定義してアクセルすると
１６バイト＋１バイトを取得するため合計で２回アクセルすることになります。
まあ２回アクセルする事自体は問題ないです。
問題なのは、次のデータが２バイト目からスタートすることが問題になります。
■＝１バイトメモリ
とした場合
■■■■■■■■■■■■■■■■
データサイズが１６バイトぴったりだと、一回のアクセスで終わり。
■■■■■■■■■■■■■■■■
■○
データサイズが１７バイトだと２回のアクセスで終わり。
で、次のデータ位置は○の場所。
もし次のデータサイズが１５バイトだと、問題ありませんが、
１６バイト以上だと、２回アクセスする必要があります。
元々１回で、済むものが２回に増えます。
しかも一度ずれるとその後がずれっぱなしなので、
アライメントと同じサイズでも２回アクセスしてしまいます。
アライメントを跨いだデータを取得する場合、
全てのデータを取得するまで、ＣＰＵ側で保持する必要性が出てきて、
無駄にクロック数を奪われてしまいます。
ちなみにアライメント以下の場合でも
ＣＰＵはアライメントサイズでしか、データを取得できません。
アライメントが１６バイトの場合８バイトと１６バイトのアクセス速度は変わりません。
これはVCで適当に８バイトと１６バイトの構造体を定義して、アクセス速度を比較したら分かります。*2
アライメントの復讐
アライメントを意識せずにプログラムを作成すると痛い仕打ちを食らうケースがあります。
暗号化(Crypt)
DESやAESなどの暗号方式の暗号アルゴリズムは、ビットレベルで適当にスクランブルを行い暗号処理を行います。*3
その時にアライメントを気にしていないと、
その空白領域にゴミが入ってしまい複合処理に失敗してしまう場合があります。
struct DATA { int a; int b; int c; //<- 残り４バイト暗黙的に領域確保されます。(VCだと) }; struct DATA2 { int a; int b; int c; int pad; //<- 明示的にしたほうがバグも発見しやすくなります。 }; void f(){ DATA data ={0,0,0}; DATA data2; memset( &data2, 0, sizeof(DATA) ); }
上記f()の中にあるdataとdata2をビット単位で比較すると一致しません。
アライメントの整え方
プログラムでアライメントを整える場合、次のようにすれば整います。
size_t alignment = 16; size_t mask = alignment - 1; void* pPtr = ((size_t*)(pPtr) + mask) & ~mask;
これはビット計算をチマチマやれば分かります。
１６バイトを手計算するとめんどくさいので
アライメントを８ビットでやってみます。
サンプル１
データを７ビットとする。
この場合計算結果が８ビットになればいい。
８ビット＋７ビット＝１５ビット
１５ビットを２進化 = 1111
７ビットを２進化 = 0111
２進化した７ビットを反転 = 1000
１５ビットと反転７ビットをAND判定 1111 & 1000 = 1000
1000を１０進化 = ８ビット
サンプル２
データを９ビットとする
この場合計算結果が１６ビットになればいい。
８ビット＋９ビット＝１７ビット
１７ビットを２進化 = 0001 0001
７ビットを２進化 = 0000 0111
２進化した７ビットを反転 = 1111 1000
１７ビットと反転７ビットをAND判定 0001 0001 & 1111 1000 = 0001 0000
0001 0000 を１０進化 = １６ビット
