2010-04-28

Facebook はなぜ HipHop を開発したかを考える

lang

もとのエントリでも触れたけど、Facebook は PHP を C++ に変換して実行する仕組みを開発し、これを HipHop for PHP という名前で公開している。

知っての通り、Facebook は世界最大の SNS であり、PHP を中心に構築されている。サーバの数も膨大で、その数約 3 万台。詳しくは Publickey の記事を参照のこと。

世界最大の SNS である Facebook が、スクリプト言語である PHP を使って構築されているという事実は、スクリプト言語でも超巨大なシステムが構築可能であることを証明している。他にも、Python なら youtuble だとか、Ruby + Rails ならクックパッドなどもよい事例となるはずだ。つまり、スクリプト言語は十分なパフォーマンスを持っている。

それでも、Facebook は HipHop を開発した。これは何を意味するかというと、Facebook は PHP のパフォーマンスに満足していないということに他ならない。今の PHP の性能で満足できるなら、あるいはシステムのボトルネックがデータベースにしかないなら、HipHop を開発しかつ実際に使用する必要はなかったはずだ。しかしそうではなかった。やはり PHP もボトルネックのひとつになっていたのだ。だからこそ、Facebook は HipHop を必要としたのだ。

あるいは、CPython の 5 倍の性能を目指すという unladen-swallow は Google の中の人が主導していることや、Google Chrome の JavaScript エンジンである V8 の高速性を考えるに、Google がスクリプト言語である Python や JavaScript のパフォーマンスに満足していないことは容易に想像できる。

個人的には現状のスクリプト言語の速度には満足しているんだけど、クラウドの時代ではそうも言ってられないのだろう。そして、今は「満足したスクリプト屋」でも、将来は「不満足な Facebook」になる可能性は、誰にだってある。

それから、

mujin script スクリプトの実行速度は問題になるほど遅くないし、問題になってもPHPならHipHopのような解決もある。開発、メンテコストも考えてよね。けっきょく同じこと言ってる。要するにタイトルで釣るなと。 2010/04/27
はてなブックマーク - スクリプト言語の息の根を止めるのは案外 SSD かもな - kwatchの日記

はてなユーザであるという立場を離れて言う。はてぶのコメントには、バカなものが本当に多すぎる。HipHop についてもちゃんと紹介しているエントリーに対して、どうして『HipHopのような解決策もある』という意見を書く気が起きるのだろう。

　・
　・
　・

疲れたね。長文乙。もし今年の RubyKaigi に応募してなかったら、それは締め切り直前にこんなクソ長いブログを書いていたせいで応募できなかったからだと思ってくれて結構。

2010-04-28

スケールアウトには限界がないのか

system

cpw 2010/04/27 12:43
アプリケーションサーバは分散が容易とういうことを忘れてはいけませんよ。サーバも安くなってきてますしね。人件費の方が高コストです。
スクリプト言語の息の根を止めるのは案外 SSD かもな - kなんとかの日記

データベースサーバと違い、アプリケーションサーバはスケールアウトしやすい。今の時代、コンピュータの値段は非常に安いから、スクリプト言語の性能が低くてもマシンを買い足せばいいだけ…そういう指摘がコメントに何件かあった。これはこれで正しい。しかし、クラウドの時代だとちょっと話は違うんじゃないかとも思う。

スクリプト言語の性能が低いので、マシンを 4 台に増やしました、あるいは 10 台、20 台、…に増やしました、という程度の話なら、スケールアウトでも別にいいと思う。けど先の Facebook のようにマシン数が 3 万台とか、そこまで行かなくてもマシン数が数千台の規模になると、「マシンの台数を倍にしましょう」なんてそう簡単に言えないのではないか。10 台を倍にしても 20 台で済むけど、1 万台を倍にしたら新しいデータセンターが必要になってしまう。

性能が必要となるたびに、スケールアウトするたびに、データセンターを建てるのが本当に正しいことなのか。マシンを数台増やすだけなら「今のコンピュータは安いから」で済むけど、データセンターを建てるなら数億円の話になる。それでも「安い」と言えるのか*1。

データセンターまではいかなくとも、数百台や数千台の規模なら、ランニングコストである土地代・電気代・光熱費も相当なものだろう。マシン単体でみれば安いのかもしれないけど、ランニングコストは継続的にかかる金額だ。もっといえば電気容量や熱といった物理的な限界要因があるから、マシン台数を無制限に増やすわけにもいかないだろう。

昔、CPU は微細化が毎年進んでそのたびにクロック数が向上した。我々はそれが当たり前だと思ったし、それがいつまでも続くと無邪気に信じてた。Pentium 8 は 32.2GHz になるという予想をしたって別におかしくなかった。しかしそれは全くの間違いだったことは、今なら誰もが知っている。

スケールアウトについては我々は同じ過ちを繰り返していないと、誰が断言できようか。クラウドの時代には、今までの常識が常識でなくなり、新しい常識が生まれる。そのことは頭にいれておきたい。

*1:まあ無駄なスパコンよりはずっと安いけどな。

2010-04-28

『使いやすいのは動的な言語だから』というのは間違い

ruby php python java

いやー、おまいらがスクリプト言語大好きというのはよくわかった。よくわかったけど、信者はもっと落ち着いたほうがいい。

mikihoshi 「スクリプト言語の使いやすさ」のかなりの部分はスクリプト言語(動的言語)であることが担保してるんだから、「スクリプト言語並みに使いやすい静的な言語」って命題が無理筋ではなかろうか 2010/04/27
はてなブックマーク - スクリプト言語の息の根を止めるのは案外 SSD かもな - kwatchの日記

ちげーよ。動的か静的かということと、使いやすいかどうかはさほど関係ない (多少はある)。

確かに、使いやすさに定評のある Ruby や Python は動的言語で、その逆に Java は静的な言語だけど、それは Ruby や Python が使いやすさを最大限考慮して作られたが Java はそうじゃなかった (あるいは Matz や Guido のセンスは良かったけど Gosling の言語設計者としてのセンスは残念だった) というだけの話であり、動的だから使いやすいとか静的だから使いにくいというのは間違い。

現に、動的な言語だけど言語仕様が残念な PHP という言語があるし、静的だけど使いやすいと評判の Ocaml や Haskell という言語がある。まあ Haskell が使いやすいかというと個人的には疑問なんだけど、個人的な嗜好の問題なので置いておくとして、とにかく動的か静的かは使いやすさの要因にはなるだろうけど、『「スクリプト言語の使いやすさ」のかなりの部分はスクリプト言語(動的言語)であることが担保してる』というのはまったくの間違い。

しかし動的か静的かで議論になるというのは、いまだハイブリッド型な言語がまるで認知されていないという証拠なんだろう。残念。Objective-C がハイブリッドだと認知されればいいのかな。

mrkn SSD == ささだ説 2010/04/27

ブーッ！！！
1.9 が高速化したのは、SaSaDa 投入によって Ruby のボトルネックが解消されたからだったのか！
(な、なんだってー！)

追記：あわせて読みたい

2010-04-27

SSD の風が吹けば Intel が儲かる

話は変わって：

とはいえ、HDDとSSDそのもののアクセス性能を比較した場合は10倍から20倍性能が違うのに対し、実際の業務を想定したOLTP処理性能の比較ではそれが2倍〜3倍程度に収まりそうであるのにはやや肩すかしを食らった感じもします。
HDDをSSDにしたらデータベースはどれだけ速くなるか？オラクルと富士通が実験－ Publickey

これはそんなもんじゃないかなあ。データベースではディスクアクセスがボトルネックとはいえ、性能の 90% を占めているわけじゃないからね。

たとえば処理にかかる時間全体のうち、ディスクアクセスにかかる時間が 60% を占めていたとする。ここで SSD によってディスクアクセスが 10 倍高速化したとすると、全体の処理時間は：

40% + 60% * 1/10 = 46%

もとの処理時間の 46% になる。SSD でディスクアクセスが 10 倍高速化しても、処理全体の時間は約 2 倍速くなっただけ。もし 20 倍高速化したとしても:

40% + 60% * 1/20 = 43%

もとの処理時間の 43% になるだけ。10 倍が 20 倍になっても、全体の性能としてはもとの 3 % しか違わない。

こうしてみると、SSD 導入による効果は「高速化」よりも「HDD というボトルネックがなくなる」ことであり、それはイコール「CPU が速くなれば速くなるほど性能が目に見えて向上する」ということなんだと思う。

SSD を導入
　↓
HDD というボトルネックがなくなる
　↓
CPU の高速化がそのままシステムの高速化につながる
　↓
CPU の費用対効果が高くなる (速い CPU を買う理由ができる)
　↓
高くても高速な CPU が売れる
　↓
Intel ウハウハ

そう考えると、Intel が SSD を手がけている理由が見えてくる。今までは、単に Intel の製造設備が余っているから SSD 製造に乗り出したんだと思ってたけど、実は高性能な CPU を売るための地道な戦略の一環なのかもしれない。HDD がボトルネックになるから高性能な CPU が売れない … それならそのボトルネックをなくしてしまえばいいじゃない、そうすりゃ高性能な CPU が売れるでしょ?

そこまで考えているなら Intel スゲー。

2010-04-27

スクリプト言語の息の根を止めるのは案外 SSD かもな

ruby python php

大変たいへん興味深い記事。全プログラマーにとって。

HDDの代わりにSSDを利用したら、リレーショナルデータベースの性能はどれだけ向上するのでしょうか？オラクルと富士通が共同検証を行い、その結果をホワイトペーパーとして先週発表しました
...(snip)...
HDDは200スレッドで性能が頭打ちなのに対し、SSDは200スレッドから300スレッドになってもまだ性能は上昇。ただし、300スレッド時にはCPU利用率が100％に近づいており、先にCPU性能の方がボトルネックとなってしまったようです。
HDDをSSDにしたらデータベースはどれだけ速くなるか？オラクルと富士通が実験－ Publickey

動的なスクリプト言語 (Ruby や Python など) と静的なコンパイル型言語 (C++ や Java など) では、だいたい 5 倍から 10 倍ぐらいの速度差がある。それでもスクリプト言語が実用的に使われたのは、言語の速度差がそのままアプリケーションの速度差にはならないから。つまりスクリプト言語で作られたアプリケーションが、必ずしも C++ や Java 製のアプリケーションより 5 倍も遅いというわけではない。

言語の速度差がそのままアプリケーションの速度差にならない理由は、CPU より I/O (ネットワークやディスクアクセス) がボトルネックになるから、というのはよく言われるし、実際そうである。少なくとも今までは。

しかし SSD が主流になり、ディスクアクセスや DB がボトルネックにならない (あるいはなったとしてもペナルティが少ない) ような時代になったら、言語の速度差がそのままアプリケーションの動作速度になる可能性がある*1。そうなると、プログラミング言語の速度が今よりずっと重要になるだろうし、動作速度の遅いスクリプト言語は人気が暴落するかもしれないね。まあ暴落まではいかなくとも、人気が下がることは大いにありうる。

スクリプト言語屋さんは今からそのときに備えるべきだろう (そのときが来てからじゃ手遅れ)。とりあえずできることは：

スクリプト言語の実装を高速化する
- Python なら unladen-swallow とか、JIT を搭載して CPython より速い (こともある) PyPy とか
- PHP なら C++ に変換して実行するとか
- Ruby はささだ先生頼み? それとも LLVM 頼み?
並列化や非同期 I/O を拡充する
- Ruby なら EventMachine とか NeverBlock とか (1.9 に Fiber が搭載されててほんとうによかった)
C 実装の関数やライブラリを増やす
- h() とか CGI.parse() とかはもう拡張モジュールにすべきだと思うんだ

つーかね、21 世紀も 10 年目に突入したんだし、もうそろそろ「スクリプト言語並みに使いやすい静的な言語」が主流になって欲しいよね。もともと速度的に不利なスクリプト言語を一生懸命高速化するよりも、そっちのほうがあるべき姿だと思うんだけど、賛同者はおらず。なんで OCaml は今いち人気がでないんだろう。

*1:まあアーキテクチャやキャッシュ技術が最重要なのは変わらないだろうけど。

2010-04-26

DI コンテナの起動が遅いなら、起動が速いのを作ればいいじゃない

gae java

自分で書いたコメントなんだけど、今見るといいこと書いてあるように思うので、エントリにしてみる。3行でまとめると：

Spring の起動が遅いことと、DI コンテナの起動が遅い/速いというのは、別の話。
DI コンテナの起動が遅いなら、起動の速い DI コンテナを作ればいいだけであり、あれだけ推していたものを起動の遅さを理由に使わないのはおかしい。
DI の有用性は、App Engine に関係しない。App Engine で必要ないなら一般のアプリでも必要ないはず (でもそうじゃないよね)。

> DIを使うとspin-upが遅くなってしまうから使わない方が良いみたいです。Springとかはそれでかなり苦労してるらしいです。
うーん、どうでしょう？
「Spring の起動が遅い」ことと「DI コンテナの起動が遅い」ことは別の話ですよね？spin up time が問題なら起動の速い DI コンテナを作ればいいのであって、DI コンテナを捨てるのは間違った選択じゃないでしょうか。従来の DI コンテナが起動時にすべてのクラスをロードするようなアーキテクチャだから起動が遅いのだと推測しますが、だったらロードを遅延させるような DI コンテナを作ればいいだけの話です (ひがさんの実力なら難しいことでもないでしょう)。
少なくともあれだけ「DI はスバラシイ」と主張していた陣営が、こんなことを理由にあっさりと DI コンテナを捨てるというのは、なんというか不自然さを感じます。
> おそらくひがさんは、DIを使うメリットがなくて、それよりもデメリットの方が大きくなる(spin upの時間はとても大切)から「複雑になるだけ」という言い回しになったんじゃないかーと思います。
DI コンテナ導入の具体的なデメリットが spin up time のことしか言及されてないのですが、仮にデメリットがその点だとしても、それを「複雑になる」という表現はしないと思います。だから spin up time の問題とは別に、DI コンテナの導入が「複雑」だと表現したのだと思います。
> 実際使ってみるとappengine上でDIが必要になったケースは(自分で使ってる限りでは)ないですね。
なぜ App Engine だと DI コンテナを必要としないのか、その理由はぜひ知りたいですね。ひがさんが述べているように、テストのしやすさとトランザクションまわりが他の手段で代替できるからというのが理由なら、別に App Engine に限った話じゃないと思います。
まつもとさんも「DI コンテナは必要ない」と主張しているんですけど、それは Ruby のような動的な言語に限定した話であって、Java のような融通の利かない言語では DI なり AOP なりで柔軟性を持たせる必要があると思います。App Engine に関係なく。
2010-04-20 - kなんとかの日記