StackThreads では, スレッド生成は単に手続き呼び出しである.
ゆえに, オーバヘッドは, ターゲットマシンにおける手続き呼びだし
に必要なもの全てであり, それはレジスタの保存とパラメタの
準備に支配されている. ゆえに, 興味深い数字はブロックと
再開のコストである. switch_to_parent が直接
ブロックしたスレッドから呼ばれた場合の,
ブロックと再開のコストを分解して表3.3に示す.
数字は Sparc の命令数で与えられている. オーバヘッドは手続きの
局所変数の個数(l), 手続きの入力パラメタ(p), 慣例で定まる
callee-save register の数(r)に依存している.
ブロックのコストは, 新しいコンテキストを確保するか,
この手続きの以前ブロックしたときのコンテキストを再利用
できるかどうかに依存する.
r=14 である Sparc のレジスタ使用慣例, l=16,p=3 である 典型的な手続きでは, ブロックコストは267命令(新しい コンテキストを確保するとき)もしくは178命令(コンテキストを 再利用するとき)であり, 再開の コストは191命令である. 局所変数とパラメタをコピーする ことが, ブロックにおいては総命令数の三分の一を数え, 再開においては半分を数える. 再開については, callee-save register の保存と回復が 総命令数の四分の一を占める. スレッドがブロック, 再開を繰り返す簡単なベンチマークプログラムでは, ブロックと再開のペアに要する時間は, 150MHz HyperSparc 上で 2.31マイクロ秒である. これは Plevyak らによって報告された結果 [37] に匹敵する.
3.2.4 (5)節ですでに議論されているように, 我々の方式は 生きている変数の情報を全く無視しており, 全ての 局所変数とパラメタをコピーしている. この起こりうる 制限要因にもかかわらず, 実際的には それらは大きな問題ではないことをこれらの図は示している. StackThreads において生きている変数の情報を利用することは 多くてもブロックコストの三分の一, 再開コストの 半分を節約するだけである. 実際の影響は詳細に依存するものの, これはスイッチに少々のコストを払っても低 オーバヘッドの生成を好むどんなマルチスレッディング 方式にもあてはまる.
コンテキストスイッチのほとんどすべての命令がライブラリで 共有されていることも指摘しておきたい. ベンチマーク プログラムでは, ブロックのために埋め込まれたコード列は たった9命令であり, すべての他の命令はすべてのコンテキスト スイッチの場所および任意の必要な場合(例えば epilogue の コード列)の間で共有されている.