トップ «前の日記(2010-04-16) 最新 次の日記(2010-04-18)» 編集

日々の破片

著作一覧

2010-04-17

_ few people use Haskell, but many people talk about it

Haskellers Meeting 2010 Springに行ってきた。

最初が和田先生の『私はemotionally functional programmer』という挨拶で、単なる自分語りのようでありながら、その実、日本での関数型プログラミングのちょっとした歴史のようになっているところがおもしろかったのではないかと思う。というか歩く日本のコンピュータ史。

次がSimon Peyton-Jonesさん(MSRの人)の『Haskellが放つ並行処理の刺客STM』についてで、当然のように英語オンリーなのだがパワポが見やすくて、えらくわかりやすいプレゼンだった。一瞬、おれの英語力が異様にパワーアップしたのかと勘違いしたが、そうではなく、Simonの発音と間の取り方、パワポに書かれた強調点と強調点の間をつなぐ喋りがうまいからだと気づく。

つかみが、langpop.comとかからとってきたHaskell小話で、次が並行処理の難しさについて学部生ネタ。というか、研究者ってブログ界でもそうだが学部生レベルという言い回しが好きだな。

で、atomicは並行処理の難しさを学部生レベルにするんだよ、というところから本題に入るのだが、続きはまた後で。

_ atomic

Haskellは並行処理のために3種類のフォーム(どう訳せば良いんだ?)を持つ。

1つは、Explicit Threadsで、forkIOとかSTM(本題)。

1つは、semi implicitで、Deterministicとか、Pureなやつでparとseq。

最後は、Data parallel。

parとseqというのは、並行というよりも並列処理かな。

f x = a `par` b `seq` a + b
  where
    a = f (x - 1)
    b = f (x - 2)

プログラミングの世界では30年の長きに渡り、ロックと状態変数による並行実行制御を行ってきたけど、これって競合、デッドロック、起こし忘れ(notifyAllを呼ぶべきなのにnotifyにしたために停止したままのやつがいるというのが典型だろう。というわけで、Effective JavaだとnotifyAllを使えというようなアドバイスになるわけだが、わざわざオーバーヘッドを招く方法を勧めなければならないところが30年の歴史というわけだな、と俺様が注)、極悪非道なエラーリカバリー、とろくでもない方法だ。

データベースの連中はもっとスマートだ。cとdはおいておくとして、AtomicとIsolationならできるじゃん。

ってわけでSTMだ。

で、STM(Software Transactional Memory)は、とりあえあずTLSに変更分をログしておいて、最後にメインメモリにフラッシュするときに他のスレッドによって変更されているかどうかチェックしてだめならエラーとする。楽観ロックだ。

atomicを単位としよう。

ところが、atomicの返り値をIO ()としたら、atomicの漏れが生じる可能性がある。(atomicそのものはクリティカルセクションだからだ)

型で解決するのがHaskell流。というわけで、atomicはSTMを取り、atomic以外はSTMを扱えないようにすれば万全で、atomic漏れは起きない。

さらに3個のアイディア。

retryは、atomicを最初からやり直す。汚染したのはTLSだけだから問題なし。(atomic内のatomicのretryは上位atomic自体をretryさせる、ということに聴こえた)

orElseは、atomicが失敗したら代替として実行する関数。ステートメントじゃないよ。だからorelse :: STM a -> STM a -> STM a、美しい!(Haskellerには美しいらしい)。

最後はalways。これは説明がなかったような。聞き逃しただけかも。

論旨は明快、内容は合理的、プレゼンは緩急自在でジョークを交えて飽きさせない、えらくおもしろかった。

もっともatomicが成立するのは、Haskellが関数型だから実行時間というものを別次元としてよけておけるから、可能なのかな? とは思った。

ビューティフルコード (THEORY/IN/PRACTICE)(Brian Kernighan)

Simon Peyton-Jonesさんはビューティルフコードの24章(美しきかな、並列)の著者らしい(が、おれはこの本は読んでいないので知らないが、アマゾンで目次を読めるので見ると、「簡単な例:銀行口座問題、STM、サンタクロース問題、Haskellにおけるリフレクション、結論」となっているので今回のプレゼンは、これのさわりの部分なのかも)。

で、次は山本和彦さんの、Mighttpdの3つの約束(俺様用HTTPD、モジュラリティの確保、Apacheより速くLightyには負ける)がどうなったかというプレゼン。HaskellではStringは[Char]だから遅いのでByteStringを使うってことと、Haskellのselectはユーザスレッドだからカーネルスレッドよりオーバーヘッドが小さくて軽い(はず)、でやってみたけど、Apache prefolkよりは速かったがworkerより遅かった(でも、prefolkのベンチ結果が遅すぎるのでちょっとベンチ結果自体が怪しい)、でプロファイリングしてみたら、selectが遅いのが主因だ。というわけで、Eventを早く取り込めというのが結論。あと、Haskellのselectはselect 1024の壁があるからprefolkを使ってc10kしたとか。

山本さんと言えばLIST遊びを持っているのでサインしてもらおうかと思ったが雨降ってたし面倒なので持っていかなかったのだが、つい会場でプログラミングHaskellを買ってしまったのでサインをもらった。

プログラミングHaskell(Graham Hutton)

原書を持っている(し、完読した)のでいらないよーと言ったけどオーム社の中の人に、「いやいや、山本さん書下ろしの関数解説がついているのは日本語版だけ」とそそのかされたのでつい買ってしまった。

で、最後は山下nobsunの、IO ()だと型みてもなんだかわからないから、=>で意図を示せるようにしたい提案(たぶんに、simon用プレゼンのような。サンタ問題の書き換えとかもプレゼンに含まれていたし)。もう少しHaskellに詳しいとおもしろいのかも知れないが、ぶっちされた感はある。が、問題意識はわかったような気はした(気のせいかも)。

本日のツッコミ(全1件) [ツッコミを入れる]
_ arton (2010-04-18 20:27)

atomicってメモ書きをそのまま書いているけど、本当はatomicallyだ。


2003|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|04|05|06|07|08|09|10|11|

ジェズイットを見習え