ささだです。

　ちょっと VM 実装技術ということで、突っ込んでみます。

Yukihiro Matsumoto wrote:
> まつもと ゆきひろです
> 
> In message "Re: [langsmith:262] Re: プログラミング言語cipher"
>     on Tue, 9 Aug 2005 12:39:27 +0900, "takashi yamanoue" <yamanoue cc.kagoshima-u.ac.jp> writes:
> 
> |> そうでしたら、まつもとさんがRubyで実験したときも関数ポインタの
> |> 方法はかえって速くなかったように記憶しています。
> |>
> |これは知りませんでした。どうもありがとうございました。
> 
> 保守性については置いておくとして、効率だけの話をすると、関数
> 呼び出しのコストは多くのCPUではcaseの分岐コストよりもはるか
> に大きいです。また、caseにしておけば簡単なマクロでGCCの直接
> ジャンプに変換できますので、より効率的には有利というのはあり
> ます。

　これについてなのですが、先日聞いてきた話で

IPSJ-SIGARC/SWoPP2005
> インタプリタ方式による命令エミュレーション処理性能
> 近江谷 康人(三菱電機情報総研)

というのでいわゆるコールスレッデッドコードを使っていました。後で理由を聞
いてみると

前提条件として
・いろんなアーキテクチャ・コンパイラでそれなりに動くものを求める
・だから、pure C で（工数などの兼ね合い）

というもとで、

・長大な１関数はコンパイラが最適化をあきらめてしまう（場合がある）
・関数コール、リターンのコストはあまり問題にならない（ことが多い）
・switch/case でも評価したが、箸にも棒にもかからなかった
・switch/case だとテーブルによる分岐になるとは限らない
・switch/case だと上下限のチェックのオーバヘッドが馬鹿にならない

ということでした。

　関数コールは遅いというのは常識と思っていましたのでそれこそ気にもかけな
かったのですが、コンパイラ・プロセッサによってはそういうこともあるのか
なぁ、と思いました。

　というわけで、現在自分が作っている処理系をコールスレッデッドコードに対
応しました。


　ちょっと細かい分析をしてみると、

・コールスレッデッドコードについて：

◎ 各命令ごとに最適化するため、コンパイラにやさしい
○ 命令の差し替えが簡単
　・たとえば、JIT の実現は容易
○ コンパイル時間は短い（コンパイラにやさしいから）
○ switch/case だと必要な上下限チェックが要らない
○ pure C で書ける
× 関数呼び出しのオーバヘッド（アーキテクチャによる）
× ダイレクトスレッデッドコードのほうが速い（GCC限定）
× 各命令ごとにマシンレジスタを共有できない（GCC限定？）
　・関数の引数でうまいことすれば出来なくもないのか？
× スタックキャッシングが使えない（使えなくもないが、効果は？）
× 分岐予測器はヒットしないだろうなあ
× 各命令間で goto によるジャンプができない
　・出来ないほうがいい、という向きもあるかもしれませんが
× 将来すごいコンパイラが出てきたら、長い関数もきちんと最適化
　 してくれる


　（最近の）GCC に限って言えば、コールスレッデッドコードにする意味は多分
無いんじゃないかと考えています。その他のコンパイラ、とくに今私が興味があ
るのは VC 系ですが、これについては今後評価したいと考えています。

　でも、実際どうなんすかね。保守のことを考えると、関数も switch/case も
direct threaded code もあんまり変わんないし、環境によって速いほうを選べ
るようになっているといいのかな。

-- 
// SASADA Koichi at atdot dot net
//

--
ML: langsmith quickml.atdot.net
使い方: http://www.atdot.net/~ko1/quickml