ClojureのSTMは使い物にならない

0×00. Clojureがいけてる件について

ここ数ヶ月でClojureをどんどん実戦投入してみているが、その成果は素晴らしいの一言に尽きる。Javaでは考えられなかったほどスマートかつ柔軟にデータ処理が可能であり、「あれ、こんなに短い記述でできちゃうのか！」と驚かされることが多い。そんなわけで、何でもかんでもJavaで片付けてきた筆者はここにきてClojureにかなり惚れ込んでおり、電子書籍やらウェブサイトやらで本格的に情報収集を進めているのだが…

0×01. Clojureの並列プログラミング

現時点では、Clojureを実戦投入したのは、ちょっとした処理に使うツール的なものだけである。理由は単に、筆者がまだClojureの初心者だからだ。しかしそろそろメインの仕事であるサーバアプリケーションやウェブアプリケーションでも使いたくてウズウズしてきており、そのような視点からさらに調査を進めている。

サーバアプリケーションやウェブアプリケーションでは並列プログラミング的なことをよくやるのだが、ClojureではこれはSTMを使って処理するのが王道のようだ。Clojureの解説を行う本などでは、STMは従来のJavaのロック地獄から解放してくれる救世主的な扱いをされており、筆者としては非常に期待していた。Javaでのマルチスレッドプログラミングは確かになかなか難しい部分があり、コードレビューなどで問題点を見つけ出す技術には経験に基づく勘が要求される。単に並列プログラミングを行いたいだけなのにメモリバリアーが〜とか言われるため、ある種バッドノウハウ的な側面がある（筆者は個人的に大好きだが）。

ClojureのSTMはぱっと見た感じでは拍子抜けするほどシンプルであり、「これで本当に動くなら、今までのJavaの並列プログラミングは何だったんだ…」と思う仕上がりになっている。

0×02. 遅いらしい

筆者の見落としである可能性もあるが、Clojureの解説を行う本（Programming ClojureとPractical Clojure。ついでに現在The Joy of Clojureを読んでいるところ）では、STMのパフォーマンスに関する記述はなかったように思う。そのため、普通に読んでいる読者は、間違いなく「並列プログラミングが必要とされる場面ではSTMを使えばよい」と考えるだろう。筆者もそう思っていたのだが、ある日Clojureに的を絞っているわけではない書籍である「Programming Concurrency on the JVM」を読んでいたところ、「STMはReadが多く、Writeが少ない場面だけにしておくべし」的な記述があって驚いた。Clojureでは基本的に並列プログラミングにはSTMしか選択肢がない（もちろんClojureからJavaのスレッドを生成したりすることもできるが、それならばsynchronized等の文法がサポートされている生のJavaを使った方が百倍開発しやすいため、却下）のに、書き込み競合が多い場面ではSTMが使えないのでは、開発が成り立たないのではと思ってしまうが…。この書籍内では実際にSTMが遅くて使えないケースをソースコード付きで掲載している。

そんなわけで、単純な例でベンチマークを取ってみることにした。

0×03. ベンチマークの内容

マップをひとつ生成する。このマップに対して多数のスレッドから書き込み競合が多く発生するようなアクセスを行う。具体的には、各スレッド内でランダムにキー（100種類のうちの1つ）を生成し、そのキーに対応する値を取得する。値は数値とする。この数値をひとつインクリメントし、再びマップにセットする。マップ内にキーが存在していない場合には1をセットする。スレッドは300個生成し、上記のインクリメント動作はそれぞれのスレッドで10万回ずつおこなう。これをJavaとClojureでそれぞれ記述したものが以下である。

Test2.java

package test;



import java.util.*;



public class Test2

{

public static final int _keyRange = 100;

public static final int _threadCount = 300;

public static final int _repeat = 100000;

//--------------------------------------------------------------------------------

public static void main( String[] args )

throws Exception

{

final long start = System.currentTimeMillis();

final Map map = new HashMap();



Runtime.getRuntime().addShutdownHook( new Thread( new Runnable()

  {

  public void run()

    {

    System.out.println( System.currentTimeMillis() - start );

    System.out.println( map );

    }

  } ) );



for( int i = 0; i < _threadCount; ++i )

  {

  new Thread( new Runnable()

    {

    public void run()

      {

      for( int k = 0; k < _repeat; ++k )

        {

        Random random = new Random();

        String key = "key" + random.nextInt( _keyRange );

        

        synchronized( map )

          {

          Integer value = ( Integer )map.get( key );

          if( value != null )

            {

            int oldValue = value.intValue();

            map.put( key, new Integer( oldValue + 1 ) );

            }

          else

            {

            map.put( key, new Integer( 1 ) );

            }

        

          }

        

        }

      }

    } ).start();

  }

}

//--------------------------------------------------------------------------------

}

bench.clj(注:間違いあり。修正版は0×06項目を参照)

(ns bench)

(import '(java.util Random))



(def _keyRange 100)

(def _threadCount 300)

(def _repeat 100000)

(def mapref1 (ref {}))

(def _start (System/currentTimeMillis))

(def _agents (seq (repeat _threadCount (agent nil))))



(defn fn1 []

  (let

    [

     _random (new Random )

     _key (str "key" (.nextInt _random _keyRange))

    ]

    

    (dosync

      (let [ _oldValue (get @mapref1 _key) ]

        (if (nil? _oldValue)

          (alter mapref1 assoc _key 1)

          (alter mapref1 assoc _key (+ 1 _oldValue))

        )

      )

    )

  )

)



(defn fn2 [ dummy ]

  (dotimes [ _index _repeat ]

    (fn1)

  )

)



(doseq [ _agent _agents ]

  (send-off _agent fn2)

)



(defn fn3 []

  (println (- (System/currentTimeMillis) _start))

  (println @mapref1)

)



(doseq [ _agent _agents ]

  (await _agent)

)



(fn3)

(shutdown-agents)

(System/exit 0)

0×04. ベンチマーク結果

この2つのプログラムを実行してみると、Java版は6〜7秒程度で終わるが、Clojure版は60秒程度かかる。Clojure版はざっと10倍程度遅いことになる。（これは書き込み競合が極端に多い例であり、ClojureのSTMが最も苦手とするケースではあることに注意が必要だ。Writeが少なく、Readが多いケースでは、Javaより速い場合もあるかもしれない。）

0×05. STMは使えないと思う理由

筆者はこの結果を受けて、「ClojureのSTMは使えない」と判断した。

「Readが多いケースならば、STMもよいのでは」という意見もあるかもしれない。しかし開発している最中に、いちいち「この部分の競合ではReadが多いか？」などと考えるのはナンセンスだ。

また、サーバアプリケーションに予想以上のアクセスが集中するなどのケースで、「読み込みが大部分だろう」と思っていた箇所で書き込み競合が多く発生してしまったら悲惨なことになってしまうかもしれない。そして、そもそも書き込み競合が多い場面で使えないのでは、別の技術も勉強する必要があり、無駄である。

さらにもう一つの理由として、「正しいコードかどうか」の判断を付けることができないという点があげられる。Javaのロックベースのマルチスレッドプログラミングは、確かに落とし穴が多い。しかしFindBugsのようなツールやコードレビューなどによって、デッドロック等の問題が発生する可能性などを見つけることができる。また、実際にデッドロックが起こってしまった場合などにも、問題点がはっきりする。問題点が見つかれば、それを修正していくことで、「正しいコード」に近づく。そしてある時点で、ほぼ確実に正しく動作するコードになった、と自信を持つことができるようになる。そしてそのコードは速い。

ClojureのSTMでは、実際にアプリケーションを完成させてテストするまで、「性能がでるかどうか」つまり「正しいコードかどうか」を判断することができない。サーバアプリケーションではしばしばテスト時点では想像もできない複雑なパターンのアクセス集中が発生することが予想されるため、いつまでたっても「このコードでいける！」と自信を持つことができなくなるだろう。また、問題があった場合の修正はアプリケーションの作り自体の変更になる可能性があり、Javaでのデッドロックの修正よりもよほど大がかりになる可能性がある。これはかなりの茨の道になるだろう。

この筆者の判断は現時点でのものなので、数年後にSTMが爆速になっていたりすれば、もちろん使ってみるつもりだ。また、性能が問題にならないようなちょっとした処理であればもちろんSTMは便利に使えるだろう。

0×06. 追記（コードのミスを修正）

コメント欄でTakahiro Hozumiさんより非常に有意義なコメントをいただいた（ありがとうございます！）。やはりSTMのパフォーマンスには問題があるらしい。また、上記の筆者のClojureコードにはミスがあり、実際には300スレッドを生成できていないことがわかった。

修正版を作成したので以下に掲載する。

bench.fixed.clj

29行目をコメントアウトすると、確かに300スレッド生成できていることが確認できる（また、ps -eLf等のコマンドでも確認済み）。

問題のパフォーマンスだが、修正後のコードを使って300スレッド生成してみるとさらに遅くなることがわかり、Javaより10倍どころではなく、恐ろしく遅くなることがわかった。そのため、0×05で示した本稿の結論的なものは変わらない形となる。

0×07. さらに追記

Clojureでは（今回のテストのように）単純に多くのスレッドを生成したいだけの場合にはagentの使用は不適切であるとコメント欄で指摘していただいた。このような場合にはagentの使用には大きなオーバーヘッドがあるようだ。The Joy of Clojureの11章がこのあたりに触れた説明となっており、とても参考になる。

本稿で目的としているテストを正しく行うためのコードはTakahiro Hozumiさんが作成してくれたhttps://gist.github.com/3048d90328d3118583a4の(ref-bench)であり、パフォーマンスはJavaの10倍程度遅いということになるようだ。

少し話題が反れるが、Programming ClojureやPractical Clojureを読んだ印象はまさに「Clojure=シンプル」であったのだが、The Joy of Clojureの11章の印象は（悪い意味で）かなり違う。現実的にはそれほどシンプルな記述で並行プログラミングを実現できる、というわけではなさそうだ。lockingなどは普通にデッドロックを起こす可能性があるように思えるためClojureらしくないと感じる。

0×08. またまた追記

詳しくはコメント欄を参照していただきたいが、最終的には以下のようなことになるようだ。