[Python-ml-jp 4361] Re: 御意見拝聴：stackless python について

2008年 5月 1日 (木) 13:36:46 JST

nobonobo ＠ python.matrix.jpです。

 とりあえずstackless-pythonはいくつかのライブラリ機能追加パッチと
 VMランタイム（Python25.dll）のみで作られており、
 既存のPython機能をなんら阻害する様にはなっていないようです。

 Windowsでのstacklessインストールに対し、
 既存のwxPythonアプリも動作しました。
 ライブラリ再インストールの必要ありませんでした。

 最小限の配布バイナリを見れば
 既存のPythonバージョンを維持するのに保存すべきファイルも
 数えるほどですので実際試してみてはどうでしょうか。

 --
 Noboru Irieda
 HN: NoboNobo
 HP: http://python.matrix.jp

 2008/05/01 10:46 kenji <kenji ＠ nasuinfo.or.jp>:


> 小林＠那須です。今 genrator を使った軽量で co-operative なスレッド制
 >  御モジュールを作っています。それとの比較の意味で、stackless python を
 >  下の  tutorial, web page と論文を中心に調べてみました。
 >
 >  http://members.verizon.net/olsongt/stackless/why_stackless.html
 >  http://zope.stackless.com/
 >  http://www.stackless.com/spcpaper.htm
 >
 >  「stackless python」 は  stacless 化と thread 制御という二つの方向を
 >  同時に追求しているために中途半端になり、CPython の世界で受け入れられ
 >  なくなっていると感じました。
 >
 >  以下、その理由を書いてみます。stackless python を使っている方で私の推
 >  測・解釈が誤っているときは指摘してやってください。
 >
 >  なお、私は stacless python のコードを実際に動かしてはいません。既にイ
 >  ンストールしてある python の動作を狂わせそうなためです。別の HDD を用
 >  意して、そこで stackless python を試せばいいのですが、そこまでまでし
 >  て試す価値はないと判断しています。できたら、私の判断を否定してくれる
 >  意見を伺えることを願っています。
 >
 >  ---------------
 >  ● stackless の意味
 >  stackless python での stackless の意味は末尾再帰可能の意味だと解釈し
 >  ています。
 >
 >  stackless は C stack を使わないとの意味だと多く箇所で書かれています。
 >  でも CPython の関数だって殆ど C stack を使っていません。stackless の
 >  意味は、CPython に僅かに残っていた C stack を関数のフレーム側に移した
 >  ものだと解釈しています。
 >
 >  このことにより、co-routine が可能になります。末尾再帰が可能になります。
 >  Thread 制御でのコンテキスト・スイッチも早くなりますが、uSec オーダー
 >  の話であり、殆ど意味がないと思います。
 >
 >  Co-routine や末尾再帰が可能になることは、本格的な関数プログラミングが
 >  可能となる意味で CPython より優れていることを意味すると思います。元々
 >  stackless python を作ったのは関数プログラミングを目的としていたと推測
 >  しているのですが、違うのでしょうか？ 「stackless python 」の関数プロ
 >  グラミングについては殆ど書かれないのが不思議です。
 >
 >  末尾再帰を可能にする代償として python virtual machine の作り方が変わ
 >  ります。CPython とは Binary での互換性がなくなります。Python だけで書
 >  かれているモジュールは再利用できるでしょうが dll で書かれた、すなわち
 >  拡張子が pyd のモジュールは利用できなくなると推測します。wxPython,
 >  numpy,matplotlib,vpython... などといった重要なモジュールの多くが
 >  stackless python では利用できなくなると推測します。
 >
 >  末尾再帰可能でありながら、その話は述べずに co-routine の話が多く出て
 >  くるのが不思議です。Co-routine を使いたくなる場面は非常に限られます。
 >  「stackless python」を使っている方たちでも co-routine を使ったプログ
 >  ラムを実際に組み込んで動かしている方は、殆どいないと推測します。
 >
 >  「stackless python」の優位さとして出てくるのが thread 制御の話ばかり
 >  なのが不思議です。次に述べるように stackless python は thread 制御に
 >  焦点を当てて開発されたとは思えません。
 >
 >
 >  ●stackless python は thread 制御に焦点を当てて開発されてていない
 >  私がstackless python を thread 制御のために開発されたのではないと感じ
 >  る一番の理由は Sleep(..) 関数のような基本的な機能が組みこまれていない
 >  ことです。下の Sleeping の節にあるようなルーチンをユーザー側で組み込
 >  んでやる必要があることです。
 >
 >  http://www.stackless.com/wiki/Idioms
 >
 >  上にある Sleeping コードは常に scheduling され続けるループで処理され
 >  なければなりません。これは時間負荷が思い処理です。Python コードで、こ
 >  んなルーチンを組み込んでいたのでは、stackless にしたことの高速応答性
 >  の優位さなんか消し飛んでしまいます。なぜ stackless python には
 >  Sleep(..) 関数が組み込まれていなのか不思議です。
 >
 >  stackless python が thread 制御で thread/threading モジュールよりも勝
 >  る理由は、一つ飛ばした節で述べるように co-operative な scheduling を
 >  しているためだと推測します。
 >
 >
 >  ●thread/threading モジュールの問題点
 >  「stackless python」の co-operative な scheduling を論ずる前に、その
 >  比較対象となるべき CPython の thread/threading モジュールでの
 >  scheduling について考えて見ます。
 >
 >  Python の thread/threading は OS native thread を使うため、その
 >  context switch は pre-emptive です。より具体的には 100 instruction ご
 >  とに Ginant Interpreter Lock を外してやり、そのタイミングで別の
 >  python thread を動かしている python virtual machine に実行を移させま
 >  す。「実行を移す」のは native OS です。
 >
 >  Pre-emptive な thread 制御では virtual instruction のどこで context
 >  switch が発生するか定まりません。どこで context switch が発生しても正
 >  しく動作するようにコードを記述せねばなりません。これが実際には大変な
 >  作業であることは、multi thread で苦労した経験のある方しか分ってもらえ
 >  ません。
 >
 >  一方で python のモジュールの多くは thread safe ではありません。ファイ
 >  ルス・コープ内に収まるとはいえ global 変数を多用する python モジュー
 >  ルでは thread safe など考えずに作られているものが大部分でしょう。
 >  Built in module は thread safe でしょうが、それ以外のモジュールは
 >  thread safe でないと思うべきでしょう。そして thread safe でないモジュ
 >  ールを一つでも import したときに、import した側のモジュールも
 >  thread safe でなくなってしまいます。この関係はリカーシブに遡っていき
 >  ます。ですから、python の thread/threading モジュールを使って multi
 >  thread 制御を行うなんて、普通は怖くてできないでしょう。特に責任と金銭
 >  の絡むビジネスでは。
 >
 >  Pre-emptive な thread 制御の怖さは、プログラムの誤動作に再現性がない
 >  ことです。再現性がなくても誤動作の頻度が高ければ、なんとか理由をつか
 >  め、対策できます。でもクリティカルな条件下でのみ誤動作するバグ、それ
 >  が一週間に一回とかで発生するバグになると、その原因追求と対策は困難を
 >  極めます。一週間に一回の頻度の誤動作でも、そのバグがハングアップなど
 >  の致命的バグならば商品になりません。
 >
 >
 >  ●stackless python が thread/threagin より勝る理由は co-operative で
 >   あることため
 >  「stackless python」はデフォルトで co-operative な scheduling を
 >  行います。context switch が発生するのは channel instance に
 >  send()/recieve() method を発行したとき、または stackless.schedule()
 >  method を発行したときに限られます。
 >
 >  プログラマーが明示的に context switch を記述したときに限ってタスク・
 >  スイッチが発生させることで、バグ対策が簡単になります。Pre-emptive な
 >  thread で発生するクリティカル条件下での誤動作がなくなるからです。
 >  「stacklss python」でも、一つしかない共通リソースを複数のスレッドが協
 >  調せずに利用しあえば誤動作が発生するでしょう。でも、co-operative なス
 >  レッドならば、バグの発生に再現性があります。バグを発生再現条件さえつ
 >  かめば、そのバグの原因追及と対策は容易であることは理解してもらえると
 >  思います。
 >
 >  「stackless python」でも stackless.run(instructionCount) と記述してや
 >  ることで pre-emptive な scheduling が可能です。「instructionCount」ご
 >  とに context switch を発生させられるようにできます。「
 >  instructionCount」 の値を固定にすれば、バグの再現性に問題ないと思われ
 >  るかも知れませんが、そうは単純に行きません。「if .... then ... else .
 >  .. 」などの構文ががあれば、実効命令数が変わってくるからです。多数の実
 >  行命令数の変化が組み合わされば、virtual instruction のどこでも
 >  context switch が発生するようになってくるからです。
 >
 >  ですから stackless python で pre-emptive な scheduling を行うことは絶
 >  対にないと推測します。
 >
 >
 >  ●stackless python が co-operative であることと、stacklessであることは
 >  無関係。
 >  「stackless python」が co-operative な scheduling を行っていることと、
 >  stackless:末尾再帰可能であることは無関係です。Co-operative な
 >  scheduling を行うだけならば、CPython との binary 互換性を捨ててまで、
 >  stackless:末尾再帰可能にする必要はありません。
 >
 >  私は stackless python の thread 制御機能だけならば、 CPython と
 >  bynary 互換を保ったまま実装できるはずだと推測しています。
 >
 >  ================
 >  以上の私の stackless python についての理解・解釈・推測について皆様の
 >  御意見をいただけますでしょうか。
 >  _______________________________________________
 >  Python-ml-jp mailing list
 >  Python-ml-jp ＠ python.jp
 >  http://www.python.jp/mailman/listinfo/python-ml-jp
 >


 --
 Noboru Irieda 入江田 昇


-- 
Noboru Irieda 入江田 昇