なぜ私たちはRuby版XOOPS Cubeを開発したか (2)
OSC2009Shimaneの担当コマのスライドまとめ第２回です。前回はこっちにあるけー。
具体的(?)な並列の話に入る前に、背景を共有しとこーや。
並列化の時代はすべてプログラマのあり方を変える！ これはマイクロソフトの偉い開発者の人が言うた「フリーランチ（タダ飯）は終わった」という名文句に集約されとる。*1
数年前まで、CPUはもの凄い勢いで高速化しよった。じゃけー、お客さんから「あんたの作ったプログラム遅いで」と言われたら「いやいや新しいハードを買うてくださいよ」と返しときゃあよかった。
ハードウェアの進化はプログラマの生産性の改善のためにある、という意見が大手を振ってまかり通りよった時代。
シングルスレッドでさくっと書いたプログラムはCPUの速度にスケールする。
実際、新しいCPUでプログラムのパフォーマンスは改善され、お客さんは喜んでくれた。この時代、プログラマの仕事はどんどん楽になっていった。タダ飯を食うとったわけ。
ところが、技術上の問題で、CPUの高速化が頭打ちになってしもうた。ほんじゃけん、低速低電力のCPUをぎょうさん積んでハード性能を上げようという時代に変化した。
新しいハードに買い替えてもCPUのコアの数が増えとるだけで、CPU単体の速度自体はほとんど変わっちょらん。じゃけー、お客さんに「いいハードを買えば、わしらのプログラムはもっと速う動きます」と言えん時代になった。CPU単体の速度は変わらんけえ、シングルスレッドのプログラムの処理時間も変わらんというわけ。
プログラマは難しかろーが直感的でなかろーが道理と合うまーが、きっちりハード特性に合わせてマルチコアプログラミングせんにゃーライバルの製品とやりあえんような時代になってしもうた……
ポイントは、今後はCPUが高速化するんじゃのうて、CPUの数が増える時代になるっちゅー話じゃけー、プログラムをちゃんと並列化させときゃあ、ハードに合わせてスケールするんよね。じゃけん、タダ飯の食い方が変わったということもできる。
じゃけど、並列化は結構たいぎぃ仕事じゃけぇ、「タダ飯」には当たらんらしい。
ちょっと先の方までの話をすると、CPUの高速化は完璧に頭打ちになっとって、各ハードメーカーは並列化のほうに力を入れよーる。なんでも2020年には10,000スレッドくらいの並列実行性能が得られるんじゃと。これは誰かが「超並列化時代」と表現しとった。
10,000どころか、100スレッドくらいで、はぁプログラマがいちいちタスクを切ってスレッドに振る方法ではコアを使いきれんようになると考えられとる。じゃけーこの頃に並列処理向きでないC/C++タイプの言語はメインストリームから脱落して、関数単位で自動的に並列化するような新しい言語が主流になるんじゃないかと予測されとる。最近Haskellとかが注目されとるのもその流れがあってのこと。そうなるとまたタダ飯？(^^;
まぁなんにしても、過渡期にあたるここ数年はプログラマが手でスレッドに仕事を振っていくやり方が最低限求められる。さすがにPHPもぼちぼちスレッディングを積んでくると思われるけん（わしゃあPHP6で積むと勘違いしとったんじゃけど;;）、 XOOPS Cube としても今から対応や基準を準備しとかんと間に合わんじゃろう。
マルチスレッドで一番変わるのはやり方じゃなくて、気分じゃとわしは思う。制約でいえば確実にシングルスレッドより制約があるけぇね。時代がマルチにいくのは完全に確定路線じゃけえ、実質シングルスレッドでも気分や設計だけでも対応させて、全体の意識をマルチ向けにしておけば、時代の変化にうまく乗っていけるじゃろう。逆に言やぁ、後からじゃ絶対に間に合わん。
あと以前 SPURS を例に出したように、低レベルのタスクコントロールブロック制御は、それ自体がモジュール差し込み＆稼働システムとして使えるけぇ、それを BASE またぎを可能にするモジュールランタイムシステムとして使おうというのも方針のひとつ。タスクシステムにしときゃあ自動並列化は割と簡単にできるけぇ。
ちぃと補足……たまに「スクリプト言語で並列化の効果あるん？」と聞かれることがあるんじゃけど、効果ぶちあるよ！
VM上やJITで動くプログラムは元々が遅いけけーじゃと思うんじゃけど、コアに仕事振ったときのパフォーマンス改善"率"でいえばネイティブコードよりおおむねでかいみたいなんよ。
ネイティブコードで２つのコアを使ってもパフォーマンスは単純に２倍にはならんし、下手打つとシングルスレッドより遅くなる場合もあるんじゃけど、スクリプトっぽい言語なら何も考えずに２つのコアを使うだけで劇的にパフォーマンスが改善される。わし感動したもん。150%くらいの性能向上とかは簡単に狙える感じじゃった。*2
あと、Webサービスを提供する環境ではリクエストが複数かかるし、他にもサービスが動いとるけぇ、スクリプト実装のアプリレベルでマルチコアを考慮する必要はないという意見も出るかもしれん。じゃけど、後述するラウンドトリップタイム中にレスポンスを馬鹿待ちせずsleepするっちゅー方法が割とWebアプリでは有効じゃと思うけぇ、それをやるためにも最低コルーチンにあたるスレッディング機構は必須じゃ思う。
ということで続く。(^▽^)/
