Re: Static branch prediction and annotation
河野真治 @ 琉球大学情報工学です。
In article <m3brs479jh.fsf@maedapc.cc.tsukuba.ac.jp>, MAEDA Atusi <maeda@cc.tsukuba.ac.jp> writes
> inlineしないspecializationって,specializeした色んなバージョンのサブルー
> チンを作るってことでしょうか.だったらinliningしても良いような.
実はおんなじ引数で呼ぶってのがたくさんあるからinlineにしたい
わけなので、それらが共用される可能性があるからspecialization
の方が優れていると思います。(subroutine のoverhead が小さければ...)
> 昔,MIPSのコンパイラはオブジェクトを中間コード(uコード)で出力しておい
> て,リンク時に手続き間最適化やをしていましたが,あれは廃れたんですか
> ね.
オブジェクト指向に起因するindirect callや、shared library 用
のdynamick linkがしこたまある現状ではあんまり意味無いんでし
ょうね。これも、時代の流れか。
> > そもそも、コンパイル時の静的な分岐予測って、効くんですかね。
> ループに関してはある程度効くんじゃないですか.
動的分岐予測がある状況ではループで静的予測ほとんど意味無いと
思う。ループでない部分(櫛形の一回の分岐)みたいなものの方が静
的分岐予測は有効だと思います。
In article <m37k2s760a.fsf@maedapc.cc.tsukuba.ac.jp>,MAEDA Atusi <maeda@cc.tsukuba.ac.jp> writes
> 他のRISC(SPARC, Alpha, PA-RISC, MIPS)は汎用レジスタをcallのlinkageに使
> いますね.Pentium4やAthlonは,オンチップにreturn address stackをそれぞ
> れ16, 12エントリー持っていて,RET命令の分岐先を予測するのに使います.
スタックトップが大域メモリにあるとそこを書き換える可能性を否
定できないので限界はあると思います。結局、スタックマシンは、
階層型メモリに対応できてないってのが僕の考えなんだけど。
一方で、return とか分岐判断用の専用のレジスタがあった方がい
いかというと、それも少し疑問に思ってます。VAX みたいに、PC
が汎用レジスタって方がやっぱりいいんじゃないかな。昔は、予測
や依存関係の解消にハードウェアを割けなかったから、だめだった
んだけど...
> link registerが専用レジスタだと,整数演算とcall/returnの間に依存関係が
> なくなります.また,PowerPCは条件call(すべての分岐命令はlink bit が1だ
> とPC を保存), 条件return(branch conditional link register命令)があると
> いう意味では,普通のアーキテクチャより汎用性があります.
整数演算とcall/return/branchには、結局、依存関係はあります。
if (i+3===hoge) do_process();
みたいな感じですよね。むしろ積極的に依存関係を使って動作を予
測して良く方が良い。逆に、ハードウェア量に制限があるなら、命
令の種類を増やすのはまずい選択だと思う。
r10 = 0x234234234+r11
pc = r10
みたいなのと、switch (i) みたいなのって、あんまり変わりません
よね。
条件callや条件returnが使えないのは、コンパイラを書いてみると
わかるんだけど、
call する前にしなければならないこと
return する時にしなければならないこと
が山程あるからです。
引数の準備
使ったレジスタの後始末 (値を元に戻したり)
フレームポインタがあれば、その操作
C++ などあれば、stack 上のオブジェクトの破壊
もちろん、そんなことしないですむ短いサブルーチンには有効なん
ですけど。どうも短いサブルーチンってのはあんまりないみたい。
プログラマの性がそうさせるのか?
さらにPowerPCの複数あるフラグとかで分岐予測しやすいようにし
てやると、早めの分岐という意味では逆に遅くなります。また、C
のような言語だと計算と分岐の順序をいじるのは危険すぎる。なの
で、結局、フラグは一つしか使わないってことになりがち。
たぶん、PowerPC には「速くしたい特定のアプリケーション」
ってのがあったので、ああいう命令になったんだと思います。
しかし裏目に出てるような気がするな。
---
Shinji KONO @ Information Engineering, University of the Ryukyus,
河野真治 @ 琉球大学工学部情報工学科,
Fnews-brouse 1.9(20180406) -- by Mizuno, MWE <mwe@ccsf.jp>
GnuPG Key ID = ECC8A735
GnuPG Key fingerprint = 9BE6 B9E9 55A5 A499 CD51 946E 9BDC 7870 ECC8 A735