Facebook はなぜ HipHop を開発したかを考える
もとのエントリでも触れたけど、Facebook は PHP を C++ に変換して実行する仕組みを開発し、これを HipHop for PHP という名前で公開している。
知っての通り、Facebook は世界最大の SNS であり、PHP を中心に構築されている。サーバの数も膨大で、その数約 3 万台。詳しくは Publickey の記事を参照のこと。
- Facebookが大規模スケーラビリティへの挑戦で学んだこと(前編)〜800億枚の写真データとPHPのスケーラビリティ問題
- Facebookが大規模スケーラビリティへの挑戦で学んだこと(後編)〜キャッシュが抱えるスケーラビリティの問題とデータセンターにまたがる一貫性
世界最大の 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 に応募してなかったら、それは締め切り直前にこんなクソ長いブログを書いていたせいで応募できなかったからだと思ってくれて結構。