Design and Implementation of RJJ

Design and Implementation of RJJ

2008-06-17

The Problem Statement: it's not "atomic-vs-lock" but instead it's "where do we put atomic/lock?"

Randall R Schulz

Azul Systemsのブログで以下のようなコメントを見つけた(http://blogs.azulsystems.com/cliff/2008/05/javaone.html):

Cliff Click wrote:

STMの性能はユーザから見て透過的ではない。STMランタイムはアボートと再実行をしなければならないからだ。その仕組みは複雑怪奇で、負荷が高い状況でSTMの振る舞いは予測不能だ。実際の製品で使える代物ではない。

これについて何かコメントは反証はあるかい?

Raoul Duke

Rich Hickey wrote:

明示的にロックを使えばそういう予測不能な事態はなくなるのか?私にはそうは思えない。

要するに負荷が高い状況ではいずれにせよ振る舞いは複雑になる、と言いたいらしい。

うーん、でもロックを使えばある意味そういう複雑な事態は起きないと思う。何が原因でロールバックが起きたのかを調べるのがSTMでは難しい(どのSTMシステムを仮定するかにもよるけど)のに比べて、少なくともロックを使えばどのロックで90%のスレッドが寝ているのかをすぐに調べることはできる。STMでは、オーバーラップしているトランザクションのベン図の中のどの変数が再実行の原因となったのか分かるかい?

もっともClojureはそれを見つけるための仕組みを持ってるとRichは言ってたけどね!http://groups.google.com/group/clojure/browse_thread/thread/2f73b80fd

Cliff Click

そのとおり。負荷が高い状況ではSTMの性能は予測不能だ。

ロックを使えばどのロックで衝突が発生しているかがわかるし、衝突の理由も普通はわかるし、対策も考えられる(ロックを分割したり、クリティカルセクションを短くしたり、java.util.concurrentの中のデータ構造を使ったり)。

STMではそういうことは不可能だ(少なくとも今のところは)。STMを普通の論文で使われているよりも大規模なケースで試したことのある人と何人か話したことがあるけど、結果は全くひどいものだ。自分が使っているSTMランタイム専門家にでもならない限りは(ここで言う専門家とは単に使えるだけではなくて自分で作って改造できる、ということ)、十分に性能が上がることはない。これは研究レベルで未解決問題だし、解決されそうな兆候もない。

Rich Hickey

人間が手でロックを書いたシステムはたいていどこか間違っているものなんだから、その振る舞いは(そしてもちろんその性能も)予測不能だ。ひどい開発者の手によるロックの使われ方を見て私が得た経験がそれだよ。STMがどういった性能の振る舞いを示すのか理解するのは難しいけど、人間が手で書いた並列プログラムの挙動を理解するのも同じくらい難しい。しかし少なくともSTMでは動作の正しさはシステムが保障してくれるし、問題に対して各アプリケーションが個別に対応するのではなく同じSTMシステムを使うユーザはみな知識を(そしてバグフィックスも性能改善も)共有できる。そしてSTMの性能がお気に召さなかった時はいつでもトランザクションを用いずに手でロックを書くこともできるのだ。STMを使っている限りはシステムの複雑性を劇的に減らすことが出来る。

並列性の話と性能の話をごちゃ混ぜにすべきではないと私は思う。並列なプログラムはなによりもまず正しく動かなければならないのだ。この点について、手でロックを書くのは複雑で全くよろしくない。スケーラビリティ性能を誰もが問題にしているわけではないのだ。数千もの同時接続を処理しなければならないシステムもあるだろうが、ほとんどのシステムはそうではない。数百個のCPUを一つのアプリケーションで使い切る必要のある人もいるだろうが、ほとんどの人はそうではない。しかし複数のコアを利用するあらゆるアプリケーションはなによりもまず正しく動作しなければならないのだ。

やろうと思えば、メモリへのどの参照で衝突が起きたかを正確に知るためにClojure STMを改造してフォールトカウンタを付けることもできる。どこで衝突しているかがわかれば、解決策はSTMだろうがロックだろうが似たようなものだ。書き換わる可能性のあるデータはなるべく共有しない、長いトランザクションと短いトランザクションに同じデータをアクセスさせない、トランザクションが成功するための条件をなるべく早くチェックする、などなど。



STM designs differ from one another quite a bit, so any general statements are difficult to assess. I think the level of granularity of the STM comes into play. Most of the STM papers I've read concentrate on creating lots of transactional cells with which they envision constructing concurrent data structures like the ones in java.util.concurrent. I don't think that's a good idea at all.

2007-03-15

研究で手を動かし始める前に自問すべき10の質問

ネタ元:http://www.popxpop.com/archives/2007/03/10_6.html

  1. パワポのスライド1枚だけを使ってあなたのアイデアを他の研究者に説明できますか?
  2. あなたの解決しようとしている問題を一つの文章で定義できますか?
  3. あなたのアイデアで速くなるベンチマークプログラムを6つ以上知っていますか?そのベンチマークプログラムのことをあなたは十分に知っていますか?
  4. もし誰かがあなたのアイデアを今日盗んだとしても、あなたはその研究を続けますか?
  5. あなたが予想している半分の効果、3倍の時間がかかったとしてもあなたはそれをやりたいですか?
  6. 何度落とされても諦めずに投稿し続ける気がありますか?
  7. 査読者に注目してもらえるようなアイデアですか?投稿して査読者のコメントをもらいましたか?
  8. 研究のあらゆる場面で物事をちゃんと評価して、助けてくれる助言者はいますか?
  9. たとえ失敗したとしても、致命的な事態を回避できますか?
  10. あなたはこのような言葉を信じていませんか?「これはみんな欲しがるよ!」「先行研究はないね。」「誰も思いつかなかったよ!」・・・

2007-02-02

誕生日パラドックス

人を集めた時にそのうち少なくとも2人の誕生日が重なる確率が50%を越えるのは22〜23人である。

では、365の各日付に誕生日が該当する人が少なくとも1人いる確率が50%を越えるのは何人か?言い換えると365日が全て埋まる確率が50%を越えるのは何人か?

その人数はあなたの予想より多いだろうか?少ないだろうか?

2006-01-18

[]SPECjvm06

SPECjvm06って何ですか?

2006-01-01

[]船戸明里「Under the Rose」1巻(ASIN:4344803167)

こんなネガティブマンガだったとは。「エマ」みたいのを勝手に想像してた。ヴィクトリアンなオカルト&推理物っぽいところがたまらん。ホームズ。こんなマンガに出合えるとは年初からツいてる。続きも買う。しかし第1話はさすがに説明不足で読解に苦労した。

Connection: close