外部ファイルのグローバル変数にアクセスするときはポインタでアクセスしたほうが速いですか？

Question

###前提・実現したいこと
組み込みのファームウェアを開発しています。変数へのアクセス速度などが気になりましたので、質問します。

外部ファイルのglobal.hには、組み込み機器が保持する変数がまとめられて宣言されています。
メインループの中で、global.hに宣言されている変数にアクセスするのですが、普通にアクセスするプログラムと、ポインタを使ってアクセスするプログラムは、速度の観点からして、ポインタを使うほうが速いと思っているのですが、合っていますか？できれば理由もおしえてください。

###ソースコード
####global.h

typedef struct __attribute__((packed)){
	DWORD   total_tick;    //トータル経過tick
	DWORD   pre_tick;      //前回tick値
	WORD	total_sec;     //トータル経過秒
}Param4Judge_Output;
typedef struct __attribute__((packed)){
    BOOL               radio_checked;
    BYTE               contact_type;
    Param4Judge_Output jdg_output;   //判定用tickパラメータ
}ControlType_Timer1;
typedef struct __attribute__((packed)){
	ControlType_Timer1    timer1;
}ControlType;
ControlType controltype;

####main.c

#include "global.h"
...（省略）

int main(){
   ...（省略）
   /* ループ内で、各タスクを呼び出す形で機能を実装しています */
   while(1){
      taskA();
      taskB();
      ...
   }
}

void taskA(){
   update_controltype_tick_ver1();   // 直接アクセスするバージョン
   update_controltype_tick_ver2();   // ポインタでアクセスするバージョン
                                     // どちらが速い？
}

void update_controltype_tick_ver1(){
   DWORD now_tick;
   now_tick = GetTick();
   controltype.timer1.jdg_output.total_tick += now_tick - controltype.timer1.jdg_output.pre_tick;
   controltype.timer1.jdg_output.pre_tick = controltype.timer1.jdg_output.total_tick;
   ...（処理が続く）   
}

void update_controltype_tick_ver2(){
   DWORD now_tick;
   ControlType *p;
   p = &controltype.timer1.jdg_output;
   now_tick = GetTick();
   p->total_tick += now_tick - p->pre_tick;
   p->pre_tick = p->total_tick;
   ...（処理が続く）   
}

###補足
関数のプロトタイプ宣言などは省略しています。

Answer 1

速度の観点からして、ポインタを使うほうが速いと思っている

なぜそう思われたのでしょうか。たしかに、JavaScriptやRubyといったスクリプト言語では、オブジェクトのメンバアクセスはその都度プロパティ参照を解決する必要があるので遅くなることがあるかもしれません。

ただ、C言語では構造体の構造もすべて静的に決まりますので、メンバ参照もコンパイル時に解決できます（継承できない以上、C++のようなvtableが入ってくる余地もありません）。普通にメンバ参照する方では静的変数の位置を決め打ちできるのに対して、（最適化されて消える可能性はありますが）ポインタ経由の参照ではポインタをアクセスするコストがかかるので、むしろ遅くなるのではないかと思います。

どちらにしても、そのレベルで速度を考えないといけないのであれば、できたバイナリを逆アセンブルして判断する、ぐらいのことは必要だと思います。

Comments

[takey]

構造体の変数a.b.c.memberがコードに現れたとき、最終的にmemberにアクセスする時間Tは、
(aにアクセスする時間) = t_a
(bにアクセスする時間) = t_b
(cにアクセスする時間) = t_c
(memberにアクセスする時間) = t_member
とすると、
T = t_a + t_b + t_c + t_member
だと思っていました。
つまり、コード上にa.b.c.memberが現れるごとに、(t_a + t_b + t_c + t_member)時間かかるという考えです。

それを、ポインタをp = &a.b.cのように使うことで、最初のpに代入するときだけ(t_a + t_b + t_c)時間かかり、それ以降はt_member時間だけで済むと考えていました。

ところがそうではなく、コンパイル時点でa.b.c.memberのアクセス先は決め打ちされる（アクセス時間はtに決め打ちされる）ので、コード上にいくらa.b.c.memberがでてきても、一律t時間でアクセスできるということでしょうか？

[maisumakun]

C言語の場合、構造体も型が決まっているので、「a.b.c.member」へのアクセスは、「（aのアドレス+bのオフセット+cのオフセット+memberのオフセット）へのメモリアクセス」という一度で済みます。実際に「a.b」や「a.b.c」へアクセスする必要がまったくないわけです。

[takey]

あまりわかっていないのですが、構造体のメンバ変数へのアクセスは一度で済むと読みました。
つまり、「aのアドレスを読みに行って、bのアドレスを読みに行って、cのアドレスを読みに行って、memberのアドレスを読んでアクセスする」という順序ではなくて、いきなり「memberのアドレスを読んでアクセスする」という動作をしているという理解です。
回答ありがとうございました。

Answer 2

遅くなるも速くなるもターゲットのアーキテクチャやコンパイラの最適化に依存します。

ところで、計測しないということはパフォーマンス(速度)には関心が無いといってもいいくらいなので、質問するよりもまずは計測することをお勧めします。そのうえで、普通はもっとも時間のかかっている箇所(ボトルネック)について改善案を考えるか、あるいはそもそも改善する価値があるのかどうかも含め検討します。

UNIX哲学より

ルール2: 計測すべし。計測するまでは速度のための調整をしてはならない。

Comments

[takey]

至言ですね。
まったくおっしゃるとおりです。

Answer 3

正直な所どっちが速いかはわかりません。
ただ変数の参照程度の処理なら、何百万回と参照してようやく差が出てくる程度じゃないでしょうか。
処理速度を上げたいのであれば、もっと他の所を見直した方が良いと思いますよ。
ポインタにこだわって可読性が落ちる方が問題かと思います。

Answer 4

maisumakunさんのコメントをみて自分の回答は正しくないと気づきました。
コードがすっきりするのは(B)ですが早いのは(A)かもしれません。
a.b.c.member ...(A)
p=&a.b.c; p->member ...(B)

下記は取り消します。失礼しました。

---

「一般的には構造体の先頭アドレスを指すポインターを介してアクセスするのが一番早い」と考えてよいと思います。

p->member

はおおまかに次のようなコードになるでしょう

スタックからpの内容をregisterへロード...(1)
registerの相対アクセスでmemberへアクセス

コンパイラーの最適化によってはpのアドレスが既にregisterに入っているなら(1)は省略されてしまうこともあるかも知れません。そうならなくても(1)のアクセスはスタック上へのアクセスになるのでキャッシュヒットしている可能性が高くメモリーへアクセスしないでロードができる期待が高くなるといえましょう。

これはa->b->c.memberなどに比べて早いというのは想像できると思います。なぜなら複数のCのメンバーへアクセスする度にポインターaの中身をロードしたりbの中身をロードするからです。しかしご質問はa.b.c.memberと書いたときの比較ですね。同じスピードで動く機械語が生成されるかも知れませんし、そうならないかも知れません。しかし一般的にいえば同一の構造体内の複数のメンバーに連続してアクセスするならポインターを介してアクセスすることの方が早いと考えてよいと思います。

細かい性能の違いが気になる場合はアセンブリーソースを比較してみるのがより明解だと思います。ただ高性能なCPUは前の命令をやりながら次の命令も並行してやってたりするので機械語の羅列を見ただけでは即座にどちらが早いというのは難しかもしれません。こういった単純なコーディングの違いでも性能に差がでる要因にはいろいろあると思うので実際に性能を図ってみた方が確実だと思います。