🚀 go-pugleaf

田中＠RWCPです．

>>In article <4kvq8d$iv0@isnews.is.s.u-tokyo.ac.jp> tau@is.s.u-tokyo.ac.jp (TAURA Kenjiro) writes:
>>
>>   ＃＃ もしかしたらこの一連の流れからquitできるかも知れないという期待を
>>   込めてfollowします.

	そうですね．建設的な議論ができるよう，サブジェクト変えちゃいま
	した．

>>    > 	   局所的には参照カウンタ方式を用いるのは分散メモリ上での実装にお
>>    > 	   いては妥当だと思います．
>>    > 
>>
>>   この, 「局所的にはreference count (以下, RC)」というのは「PE内のゴミを
>>   回収するのに」RCを使うと意味でしょうか? 
>>
>>   だとするとちょっと良くわかりません. Exportされたreferenceについては局
>>   所GCをあきらめるのであれば, RCを使うmeritは何でしょうか?
>>
>>   ## 短い時間exportされたゴミを回収するのに, RCを使うmeritはあると思いま
>>   すが, おっしゃってるのはそのような意味ですか?

	基本的には実時間GCを目指したいというのがあり，グローバルなGCも
	On-the-flyでやりたいと考えています．そこで，局所的なGCにはRCを
	使おうかなと考えています．
	ただ，RCを用いた場合に発生するカウンタ操作による負荷がどの程度
	大きくなってしまうのかを検討する必要はあると思いますが．

>>   relocationのcostは単に輸出表のentryを書き換えるだけなので, 輸出入表を
>>   かますのであれば特に複雑さが増すとは思えませんがどうでしょうか.

	そうですね．確かにrelocationが発生しても付加的な操作は輸出表の
	entryの書き換えだけで済みます．
	ただ，頭の中に「グローバルはOn-the-flyで」というのがあったので，
	コピー法に対する抵抗感があったのでこのように書いてしまいました．
	説明が足りませんでした _o_

>>    > 	   (1) オブジェクトのidentityに関して．
>>    > 	       Lispには副作用がありますので，分散メモリ上でオブジェクトの
>>    > 	       identityを維持するにはどうすれば良いか．(あるいは維持をあ
>>    > 	       きらめるか)
>>
>>   最近ABCL/fという並列言語の実装をした時もこれで考えましたが, 結局とった
>>   解決策は(後ろ向きなもので), identity (副作用)のあるobject (並列オブジェ
>>   クト)と, 副作用のない(identityのない)ものを区別するというものでした. 
>>   オブジェクトに関しては, identityを保存(参照渡しによって)しますが,
>>   software cachingその他は現在していません. 

	この研究に関する文献がありましたら，教えて頂けますか？

>>   Lispでconsistency 管理をsoftwareで行なった場合, access時の
>>   local/remoteのcheck自体は現状のLispが行なっているdynamic type checkと
>>   同じレベルのcostと思います(データタグの中に, データのvalidityを示すbit
>>   も含ませておく. この方式だとpointerの中にtagを含ませることはできません
>>   が).
>>
>>   予想されることは, Mostly Readonlyなprogramで, 参照の局所性が十分高い場
>>   合には, semanticsを変えないまま, 動的型検査をことごとく行なうLispと同
>>   じレベルになれるのではないかと思います(注: Lispが動的型検査をことごと
>>   く行なうという意味ではない). 更新がバンバンおきるともちろん辛いです.

	そうですね．私もそう思います．
	確かにたちの良いプログラムであれば，ある程度のパフォーマンスは
	得られるのではないかと思います．
	ただ，質問(3)と関係するのですが，私が気になるのはもともと「ポ
	インタ」でデータが表現されているリスト構造に基づくLispという言
	語を分散メモリ上で実装して，果たしてどの程度のパフォーマンスが
	得られるのだろうかというところなんです．(これを作ってみて調べ
	るのが研究というやつなのでしょうが)
	例えば長いリストを走査するような関数を別のPEに実行させる場合，
	結局は長いリストすべてを送らなければならないわけですよね．
	大きなデータ(画像データみたいなもの)を送ることだってありえます．
	また，変数への値の代入などの副作用が発生したらconsistencyを保
	つためにこれまた通信が発生するわけですよね．
	考えれば考えるほどマイナス的な要素が大きく感じられて，ちょっと
	しりごみしてしまっています．
	まぁ，とりあえずは「作って動かして調べる」から始めないといけな
	いのかもしれませんが．

>>    > 	   (2) 各PEにはどの程度のセルを持たせれば良いか．また，グローバル
>>    > 	       なGCを行なうタイミングは？
>>
>>   いつグローバルGCをやればいいのかについては私は今のところ, no ideaです.
>>   理想は常に裏でcuncurrent GCがlow overheadで走っているというものだとは
>>   思いますが.

	僕は主にGCに興味があって，田浦さんのおっしゃる「理想」を実現し
	たいと考えています．

>>    > 	   (3) 例えば，大きなオブジェクト(配列とか長いリストとか)を引数と
>>    > 	       して渡すとなると，メッセージの量がかなり多くなってしまいま
>>    > 	       すよね．グローバルなGCに際してもそうですが，メッセージ量を
>>    > 	       軽減するために何か良いお考えはありますか？
>>
>>   softwareでconsistency管理をするという前提のもとでなら, listのような
>>   linked data structureをどこまでたどって送るべきかについては, 任意性が
>>   ありますから, 必ずしもメッセージが必ず増えてしまって困る, ということに
>>   はならないと思います(配列の場合は辛いでしょう). 

	後にも書きましたが，最終的には「大きなデータを処理するようなプ
	ログラムをばんばん走らせるLisp」を作りたいと考えており，この部
	分に関する良い方法を模索しています．

>>   Remote fork時にargumentをcopyするのは, 一種のeagerなcache update
>>   protocol (similar to cache injection)ですから, mechanism 的には
>>   softwareでconsistency管理するのと同じ機構で実現できると思います. 難し
>>   いのは実際に相手が必要としているデータの見極め, ということになるのでしょ
>>   う. これについては, 安易には, user annotation. Compilerでの解析もそれ
>>   なりにはできると思いますが, 面倒そうですね.

	確かにconsistencyの保持はcacheのconsistency保持と同じmechanism
	でできると思いますが．．．
	以前shared memory上で並列Lispを作成したことはあるのですが，
	shared memoryからdistributed memoryに移るにあたり，やはりもっ
	とも気になるのがオブジェクトのidentityの問題と，通信量がどの程
	度パフォーマンスに響いてくるかという点にあります．
	それで，同じような研究をなさっている皆さんはどのような手段をお
	とりになったのかなと．．．

>>   興味があります. どのようなLispでしょうか? scratch からですか? それとも
>>   既存の何かの変更でしょうか?

	電総研で開発されたEuslispというshared memory上で動く並列Lispが
	あります．Euslispは特にロボット研究への応用を目指したオブジェ
	クト指向型Lispであり，Common Lispのほとんどの機能＋ロボットが
	センシングや行動を計画するために必須な３次元幾何モデルを定義・
	操作・表示する機能を備えているLispです．
	現在このEuslispをdistributed memory上で動くように移植しようと
	いう計画があります．

	ちょっと考えただけでも検討すべき課題がたくさんあるので，少しで
	も良いものができるようこのNGにこのような投稿をしたわけです．
	今回の田浦さんの記事は大変参考になりました．
	これからも何かあったらこのNGに投稿したいと思いますので，今後も
	よろしくお願い致します．

	なお，Euslispは公開ソフトウェアであり，
	etlport.etl.go.jp(192.31.197.99)からanonymous ftpで入手可能で
	す．また，URLは http://ci.etl.go.jp/~matsui です．

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
		新情報処理開発機構 (Real World Computing Partnership)
		超並列研究部 超並列パフォーマンス研究室

		田中良夫	yoshio@trc.rwcp.or.jp