From: Satoshi Shiba <shiba@...>
Date: 2010-03-29T02:17:53+09:00
Subject: [ruby-dev:40813] Re: Improvement of Fiber switching cost with system 	dependent way

こんにちは，笹田研 修士1年の芝と申します．
Fiberのパッチの中の人です．

KOSAKI Motohiro wrote:
>> メリット：
>> Fiber のコンテキストスイッチが速くなる（どれくらいかは資料を参照）
>>
>> デメリット・変更点：
>> 最大生成数が減ります
>> マシンスタックのサイズが制限されています
>> Fiber 生成コストがちょっと増えます
>> （どれくらいかは資料を参照）
>> ソースコード (cont.c) が結構見づらくなる
>>     
>
> まず資料をレビューしました。感想とか質問とか、、、
>
> ・Fiberは誰かが遅い遅いとblogに書いていた気がするので基本的には賛成
> ・get/set/makecontextとset/longjmpの併用はPOSIX上、保証がないのではないか？
>   
POSIXでの保障は無いと思います．
色々なOSで実際にテストしてみた感じでは，問題無く動作しているようですが．

> ・NetBSDがスタックからTLSを計算しているのは、setcontextとpthreadの混在が
>    出来ないことを意味するのでNetBSDのバグではないか？
> ・マシンスタックの再利用は生成時間だけではなく、スタックにcache hotな領域が
>    割り付けられることによる速度向上もあるので、N=10は素朴すぎる気がする。
>    しかし、N=10でコミットして、後から改善していくので問題ないと思う
>    余談だけど、Linuxのpthreadも似たような思想でスタックキャッシュしていて
>    筋はよいと思います。
> ・Linux, Mac は速度向上が大きいのでよいと思う
> ・Windowsはコンテキストスイッチ速度３倍、生成速度0.6倍、最大生成数1/4
>     なので微妙な気がする。（他の人の意見が聞きたい）
>     (Win32Fiberってなんでこんなに遅いの？）
>   
32bitのWindows環境でも20000以上のFiberは生成できるんですが，20000では足
らないのでしょうか．

あと，Windowsで速度差があまりつかない原因はWin32Fiberの速度ではなくて，
VCの吐くコードのマシンスタック使用量が少ないことにあるようです．

今回，コンテキストスイッチの速度差はRubyが使用するマシンスタックのサイズ
に比例しています．
Rubyの使用するマシンスタックのサイズが大きいほど，コンテキストスイッチの
速度差が開いていきます．
そのため，コンテキストスイッチの速度差に対しては，OSの違いよりもコンパイ
ラによる
マシンスタック消費量の違いの方が影響が大きいです．

GCC4.4.1の方がGCC4.3.3に比べてRubyの使用するマシンスタックのサイズが小さ
いのですが，
同じLinux環境でGCC 4.3.3と4.4.1で比較したところ，
GCC4.3.3の方はコンテキストスイッチ速度が3-18倍だったのに対し，
GCC4.4.1の方はコンテキストスイッチ速度が2-6倍という結果になりました．

> ・Fiberのスタックサイズが小さくなることについてのインパクトを知りたいのですが、
>    言語仕様的に、スクリプト中からFiber生成時にFiberスタックサイズを指定する
>    方法はありますか？いいかえるとワークアラウンドはありますか？
>   
Fiber.newの引数で，マシンスタックのサイズを指定できるようにすることは可
能だと思います．

> ・脇道だけど、研究発表としてはPerlのコルーチンと比べて、どのくら遅かったか。
>    とかあると盛り上がるような気がする
>   
貴重なご意見，ありがとうございます．

>
> 思いつきを五月雨式で書いているだけですいませんが。
>
>
>
>
>