# ふつうのプログラマーは並列プログラミングを勉強しなくていいよ。 _published: 2010/01/26_  みなさん、マルチタスクしてますか？私は、2ちゃんねるのまとめサイトを見ながら、コーヒーを飲みながら、椅子に座りながら、呼吸をしながら、インシュリンを分泌しながら、iPhoneの充電をしています。超マルチタスクですね。今日は、並列プログラミングの話をします。と言いつつ、昨日も並列プログラミングの話だったのですが。 - [Go言語 (Go lang)の並列プログラミングは超かんたん。 - このブログは証明できない。](http://d.hatena.ne.jp/shunsuk/20100125/1264416726)[](http://b.hatena.ne.jp/entry/http://d.hatena.ne.jp/shunsuk/20100125/1264416726) 昨日の記事は、今日の記事を書くための布石です。並列プログラミング不要論を書くに当たって、プログラミング言語による並列化のサポートについて調べてみたのです。いわば、スイカの甘みを引き出すために塩をかけるようなものです。その結果、言語がサポートする並列処理のコードを書くのは簡単だけれども、並列プログラミングをするにはパラダイムシフトが必要だという結論にいたりました。あ、パラダイムシフトって言っちゃった。 今日の記事は、きしださん(id:nowokay)の意見にまっこうから反論するものではありません。プログラマーが富士山の形に分布しているとして、きしださんは富士山の中腹より上の話をしているのだと思います。私の妄想は、富士山の裾野のプログラマーにはまったく関係ないとして、だいたい中腹くらいまでの階層を想定しています。そもそも階層の違う話なのですね。まあ、もっと上に登るためにという話は置いといて。 それでは、ふつうのプログラマーが並列プログラミングを勉強しなくていい理由。 ## リクエスト単位で並列化すればいい。 並列プログラミングというと、アルゴリズムの話になる気がするのは私だけでしょうか。クリスマスイブにトラックにはねられたのは、私だけかもしれませんが。でも、実際のところ、Webサーバーへのリクエストが並列化されてればいいのではないでしょうか。リクエスト単位、もしくはセッション単位で並列化されていれば、今どきのアプリケーションは大抵うまくいくでしょう。 Webアプリケーションだけに限らず、デスクトップアプリケーションやモバイルアプリケーションも同じことです。これは、ほとんどのアプリケーションがクラウド化する（せざるを得ない）という前提に基づいています。この辺は、以前書いたとおりです。技術的な理由ではなく、ビジネス的な理由です。 - [[iPhoneアプリ開発者があえて言う。iPhoneは終わる。]]  リクエスト単位での並列化は、ロードバランサに任せておけばいいので、プログラミングの仕方には影響がありません。いやいや、分散処理するには、そのためのプログラミングが必要だと反論されるかもしれません。ですが、すでに複数人の人が指摘しているように、スケールアウトからスケールアップの時代になります。その中から、江島さんの記事を。 - [スケールアウトからスケールアップへの回帰:Kenn's Clairvoyance - CNET Japan](http://japan.cnet.com/blog/kenn/2010/01/12/entry_27036420/)[](http://b.hatena.ne.jp/entry/http://japan.cnet.com/blog/kenn/2010/01/12/entry_27036420/) CPUがメニーコアになって、ストレージがSSDになれば、複数台のサーバーが必要なくなります。SPOF (Single Point Of Failure)については、単純にミラーリングすればいいのです。今後は、負荷分散のためではなく、耐障害性のために複数台のサーバーを用意するようになります。ミラーリングなので、分散処理のためのプログラミングは不要です。 ## ライブラリサーバーが登場する。 リクエスト単位で並列化すればいいと言ったものの、そうはいかないケースもあります。処理自体に並列化が必要なケース、例として画像処理が挙げられます。ですが、画像処理をするにも並列プログラミングは必要ないのです。なぜなら、ライブラリサーバーが登場するからです。 画像処理のライブラリサーバーであれば、画像を受け取って、並列処理して返してくれます。富士山の中腹より上のプログラマーがライブラリサーバーを実装してくれるので、ふつうのプログラマーは画像処理を実装する必要がありません。それじゃ、プログラマーがダメになる？でも、OpenCV使ってるでしょ？みんながOpenCVを実装する必要はないのです。 ライブラリサーバーに近いものは、すでに存在しています。Google AJAX Libraries APIは、GoogleがJavaScriptのライブラリをホストしています。ライブラリを使いたい人は、GoogleがホストしているJavaScriptをHTMLファイルから呼び出します。もっとも、JavaScriptなので、動作するのはローカルコンピュータ上なのですが。 - [Google Libraries API - Developer's Guide - Google Libraries API - Google Code](http://code.google.com/intl/ja/apis/ajaxlibs/documentation/index.html) 現在のWebのAPIがデータを公開しているのに対して、ライブラリサーバーでは処理を公開します。そして、内部的には並列処理を行っているのです。 ## ラッパーサーバーも登場する。 ライブラリサーバーを使う側も並列化する必要がある場合もあります。ですが、コアのアルゴリズムを公開するライブラリサーバーを利用して様々な処理を行うライブラリサーバーが何種類も登場します。例えば、コアにImageMagickを利用して、特定の処理に特化したライブラリが何種類もあるのと同じことです。 また、ImageMagickの例で言えば、ImageMagickをRubyから利用するためのRMagickというラッパーがあります。同じように、ラッパーサーバーが登場します。サーバー間通信だから、プログラミング言語は関係ないのでは？と思われるかもしれません。ラッパーサーバーは言語の話ではなくて、XMLやJSONなどのフォーマットの話になります。 と言っても、フォーマットだけなら、どうにでもなります。結局、テキストなので。もっと根本的にプロトコルが違っても構いません。さらに、プラットフォーム依存でも構いません。.NETであれば、WCFのTCPバインディングとか。昔の.NET Remotingとか。クライアント／サーバー間で、オブジェクトを透過的に扱えると便利です。そのように様々なプラットフォームに特化したラッパーサーバーが登場します。むしろ、プラットフォーム依存の方が便利ですね。 プラットフォームのことは置いておいても、機能的には、様々な処理に特化したラッパーサーバーが出てくるわけです。ラッパーサーバーが増えれば、クライアント側で並列プログラミングをする必要性はますます減ってきます。 ## UI層ではAPIが並列化を隠蔽してくれる。 さて、ビジネス層の並列化が必要な処理は、ライブラリサーバーが処理してくれます。それでは、UI層ではどうでしょうか。例えば、.NETのWindowsフォームはシングルスレッドアパートメントになっています。マルチスレッドを前提に作られていません。そのため、プログラマーが自力でスレッドを生成した場合、自力でInvokeしなければなりません。 ライブラリサーバーはすぐにでも作れますが、UI層の並列化にはもう少し時間がかかると考えています。それは、オープンソースで実験的なライブラリサーバーに対して、UI層のAPIはベンダーが製品化しなければならないからです。今どきマルチコアが当たり前と言っても、それは店頭の話であって、ユーザー企業がPCをリプレースするのは大変なことです。ですから、ベンダーもそう簡単に最先端を追うことはできません。 当分の間は、UI層の並列化はデザインパターンで対応することになるでしょう。先程のWindowsフォームの例で言えば、Invokeするパターンが存在すると思います。このようなUI層の並列化のデザインパターンというのはすでに普及していて、Ajaxのデザインパターンがこれに該当します。それならやっぱり並列プログラミングの勉強が必要じゃないかと言われたら、反論できません。 ですが、将来的には状況が変わります。マルチスレッドを前提としたUIコンポーネントに置き換わるからです。例えば、テーブルコンポーネントのロード時のイベントハンドラにWebからデータを読み込む処理を書くと、自動的にバックグラウンドでイベントハンドラが処理され、処理が終了した時点で、テーブルにデータが表示されます。 プログラマーはデータを読み込む処理を普通に書けばいいので、並列化を意識する必要はありません。iPhoneがデュアルコアになるかもという噂がありますが、そうなればUIKitがマルチコア対応になるので、それを利用するだけです。 ## じゃあ、何を勉強すればいい？ 現在は、ハードウェアの進化に起因する過渡期なのだと思います。混乱した状況の中で、並列プログラミングが必要だと言われているだけです。もう少しすれば、ふつうのプログラマーが並列プログラミングを勉強する必要のない時期が来ます。そうなったら、むしろ、ネットワーク障害のエラーハンドリングをしっかりやった方がいいと思います。 それでは、並列プログラミングを勉強する意味はないのでしょうか？もちろん、あります。富士山の上の階層を目指すのであれば、並列プログラミングが強力な登山道具になります。また、並列脳（パラレル脳）へのパラダイムシフトが必要ですから、LISPのように「悟り体験」のために勉強するという人もいるでしょう。あ、パラダイムシフトって言っちゃった。 ## この妄想の弱点は内緒です。 基幹業務系アプリケーションのビジネスロジックを並列化する必要性はないと思うのですが、どうでしょうか。むしろ、サーバーをまたがって連携するようになるはずなので、結局、リクエスト単位での並列化になると思います。ロングタイムトランザクションも、今回の妄想とは関係がありませんし。 それより、ネットワークの通信コストとか。。。 ## スイカに塩をかける書籍紹介。 おもしろそうですね。オライリーのは、下のサイトで細かい目次を見ることができます。 - [O’Reilly Japan - 並行コンピューティング技法](http://www.oreilly.co.jp/books/9784873114354/)[](http://b.hatena.ne.jp/entry/http://www.oreilly.co.jp/books/9784873114354/)