新城＠筑波大学情報です。こんにちは。

In article <sek76vkxii.fsf_-_@astec.co.jp>
        Takuya KUDO <kudo@astec.co.jp> writes:
> 私が携わった Sparc プロセッサは随分昔の話で組み込み用途
> 浮動小数点演算なし（当時はソフトウェアエミュレーションを
> 使いました）のアーキテクチャです。
> 具体的に言うと富士通 Sparc Lite です。

私がインライン展開の効果を調べたのも、そのくらいの時代です。
SPARCstation 1 くらい。具体的には、inline ではなくて、
#define を使ったのですけれど。その当時の gcc は、inline がな
かったと思います。

同じ仕事をする関数を #defineで書いたのと普通の関数で書いたも
のを用意します。これを単純にループで回すのではなくて、関数を
ネストさせます。こんな感じ。

f1()
{
   int x0,x1,x2,x3,x4,x5;
   f2();
}
f2()
{
   int x0,x1,x2,x3,x4,x5;
   f3();
}

それで、インラインにすると速くなるのですが、ある程度増やして
いくと逆に遅くなります。５段か６段くらいだったかなあ。

これは、昔の話。SPARC で話。キャッシュとはあんまり関係ないか。

In article <bna4dl$1gob$1@maha2.doga.co.jp>
        Masamichi Takatsu <taka2@doga.jp> writes:
> 高津@ドーガです。
> 私がちょっと前にx86で試した時は、inline 展開によるサブルーチンコールの
> オーバーヘッド削減はほとんどありませんでした。
> というか、最近のCPUは賢いので、引数がレジスタ渡しにさえなっていれば
> サブルーチンコールのオーバーヘッドはほとんど無いって感じです。

最近、Pentium III での話ですが、Tempo という specializer で
インライン展開を調整すると効くことがあります。というか、イン
ラインにしないとspecialization の効果が全然出てこないことが
ありました。関数呼出しで、スタックに引数を積む所を削除するの
が効いているように思います。

> かといって inline 展開に意味が無かったわけではなく、関数を跨ったピープ
> ホール最適化が出来るという点では効果的でした。
> 似たような処理がある inline 関数の呼び出しが連続しているところで、
> まとめて共通部分式の削除とか、そういうことができると、数倍とか、
> そういうオーダーで目に見えて高速化できてしまいます。

手続きを越えて、共通式削除の最適化はやってもいいわけですよね。

> inline 展開での性能向上を期待するような小さな関数では、その中に
> サブルーチンコールなどはあまり無いでしょう。

別に小さい関数にしか inline を付けてはいけないという規則はな
いので、ぼこぼこ付ける人が出てくるわけです。

＼＼　新城　靖　（しんじょう　やすし）　＼＼
＼＼　筑波大学　電子・情報　　　　　　　＼＼