本当は今日も東京でRails講習会のための打ち合わせのはずだったのだが、 昨日ようやっと帰宅して、今日また東京出張では体が保たないので、 Skypeで会議に参加することにした。
講習内容もかなり具体化してきている。 まあ、参加者が後悔しない内容になっている(と、いいなあ)。
私も参加する。どうやら私もビジネスマンのコスプレをする必要があるようだ。 うーむ。
それはそうと、Skype会議には課題も多い。
今後、Skypeで会議するためには以下のような点に気をつける必要があるだろう。
電話会議は空間の障害を克服できる有効な方法だと思うので、 今後も工夫していきたい。
今回の中国出張の間、Jones & Linsを持参して GCについていろいろ考えていた。
結局、スクリプト言語は性能を最重視していないので、 対応すべきは停止時間の短さであろうという結論に至った。 ユーザインタフェース系などでのポーズは結構問題になることも多いようだから。
となると、今後RubyのGCについて検討すべきはインクリメンタル化なのであろう。 IoもLuaもインクリメンタルGCを実装しているのだし。 とはいえ、トータルのスループットを考えると効率を無視するわけにもいかず、 効率の良いインクリメンタルGCの実装はどうしたものかと考えたりするわけである。
結論はまだない。
This work is licensed under a Creative Commons License.
むかし竹内さんたちがやっていた並列GCみたいのはできないものなの？
今時だったら、GC用のthreadを用意するとかでもいいような気がします。同じthreadでinclementalにやるのは、どうやっても「言い訳を考えながら行動してる」みたいな、余分なコストが排除できないように思うな。
お二人とも専用threadなどを使った並列GCについて考えておられるようですが、そのようなGCは<br><br> * Rubyが対象にしている広い範囲のプラットフォームでの移植性がない<br> * GCはthread間の同期が多く(移植性の高い形で)性能を上げるのが難しい<br><br>という理由があって、言うほど簡単ではありません。＞ ひろのぶさん、おごちゃん
wktk.
SqueakのGCは完全ポータブルですが、通常のpause timeは0.5msくらいで、一秒に60回くらい実行するとかそんな感じです。<br><br> GCがexactなかわりに外部ライブラリとのやりとりがRubyほど自由ではないので、そのまま適用はできないかもしれませんが...
Rubyも普段はそんな感じなんですが、中には数百万オブジェクトを作っておいてGUIをぶんまわしたいとかいう人もいるんでねえ。問題になるのはワーストケースだけですね。
失礼しました^^;<br><br>working setに数百万入っていると少々たいへんですね。僕もなぜかたくさんのオブジェクトを使うGUIものをやっているのですが、「non-pointerのデータしか入らないArray」を使うと、GCがそれをトレースしなくなるのでworking setにそれなりの量の「ポインタじゃない同質なデータを保持しているArray」が入っていても大丈夫、というような方法でやっています。
「竹内さん達の並列GC」が要求するものって、単に「本流とは別に空間を共用する処理が存在できる」ということだけで、排他や同期はオブジェクトの2bitを使いますよね。となると、今のRubyのthread程度のことで済むのではないかしらん。
娘です。<br>なんか、いろいろ言ってたけど、スカイプでやったんだ。<br>集中力がもたないって・・・。<br>よくわかんないけど、頑張ってください！！
Azul Sysmtesが作ったPauseless GCの解説があります。<br>ポーズ時間を重視するなら、参考になるかもしれません。<br>http://www.nminoru.jp/~nminoru/java/cms/pauseless_gc.html
ハードウェアサポートがあるとムチャができますね。<br>うらやましい。
世代別GCは平均的な停止時間も短いし効率も良くなると思います。<br>major collectionの時にはしっかり止まりますが．．．<br><br>世代別GCのminor collectionごとに、少しずつmajor collection<br>を行う「粗粒度インクリメンタルGC」というのをやってたりします。<br>効率をなるべく落とさず、世代別GC程度の停止時間を狙うものです。<br>http://www.ialab.cs.tsukuba.ac.jp/~maeda/research/pro45-maeda-gc.pdf<br><br>世代別GCにしてもインクリメンタルGCにしても、保守的GCと<br>共存させるとなるとwrite barrierをどうするかが最大の問題だと<br>思うんですが．．．
Rubyの場合はwrite barrierを入れるべき場所は木山くんの研究によってほぼ明らかになっているので、その点はなんとかできそうです。<br>が、なかなかうまくいかない(ワーストケースでも劇的には改善しないうえに、普段のGCが遅くなったりする)んですよねえ。