電源問題も、スクリプト言語の息の根を止める原因になるかも
HDDは本当に遅い
スクリプト言語の息の根を止めるのは案外 SSD かもな - kwatchの日記 に大変共感した。
しかし SSD が主流になり、ディスクアクセスや DB がボトルネックにならない (あるいはなったとしてもペナルティが少ない) ような時代になったら、言語の速度差がそのままアプリケーションの動作速度になる可能性がある。そうなると、プログラミング言語の速度が今よりずっと重要になるだろうし、動作速度の遅いスクリプト言語は人気が暴落するかもしれないね。まあ暴落まではいかなくとも、人気が下がることは大いにありうる。
HDDは本当に遅くて、いつだってボトルネックに成り得る。ゆえに、スクリプト言語側の遅さは気にされにくかった、というのは盲点だった。
そこでもう一つ、「電源」についても、スクリプト言語の息の根を止める原因になり得るのではないかと思ったので書いてみる。
消費電力あたりの処理能力への注目
まず、電源・電力は今となっては他のリソースより相対的に高価で、また手軽に拡張しにくいリソースである。電気代は気になるし、電源の確保はおおごとなのだ。
そして、電力を最も消費するハードの一つがCPUである。ここ数年、CPUの最大処理能力より、消費電力あたりの処理能力の方が注目されている。CPU自体はそれほど高価でもないので、増やそうと思えば増やせるが、その前に電気代が大きなコストとして乗しかかってきたり、電源に限界が来てしまうので、消費電力あたりの処理能力が重要になるのだ。
GAEでもCPUは高い
また、GAE(Google App Engine)というCPUやストレージなどのリソースごとに課金されるサーバーがある。とあるサービスを移植して軽く動作させたことがあるんだけど、CPUが最も高価なリソースの一つだった。それも、ずば抜けて高かった。GAEにおいては、CPUを多く使うような富豪プログラミングなんて夢のまた夢だな、と思った。(ちなみにそのときは、JavaScriptで出来ることは全てJSに任せてクライアント側のCPUを利用するようにしてみたりもした)
このように、CPUの消費電力あたりの処理能力が注目され、クラウドでも高価なリソースとなれば、いつだってボトルネックになるだろう。電力が足りない!CPUを使いすぎている!どうにかしなければ、と。
スクリプト言語はCPU食いの原因の一つ
CPUの利用率を下げるには、効率の良いプログラミングが欠かせない。スクリプト言語は、静的型付け言語に比べてCPUの利用率が高い。ソフトウェアはとっても作りやすいけど、CPUには優しくなく、消費電力が上がりがちである。
もちろんCPUの利用率を下げる手段は他にも沢山ある。memcacheやKVS、キャッシュや優れたアルゴリズムの採用など。それでも追いつかなくなってきたときは、果たして、スクリプト言語を採用し続けられるだろうか...?
RAMディスクを利用した高速環境むけのソフトを書いてますが
HDDのボトルネックが無くなったら、また別のボトルネックが居て
というのを繰り返し体験してますが、スクリプト言語も微妙なラインにいますね。
ちなみにうちではネットの通信速度がボトルネックの一つとして存在しています。
LLで書いてC言語に変換 コンパイルする というFacebookメソッド
http://www.itmedia.co.jp/enterprise/articles/1002/03/news053.html
Cとかの限度の教育コストと電源コストのどっちが高いか
になってくるのでしょうか?
究極的にはgoogleみたいにlinxカーネルカスタマイズで特注web serverという方向性もありですね。
でも先立つ問題として、
電源やSSDが問題になるぐらいpage viewが増えて欲しいなぁ(オイ
C言語か?スクリプト言語か?という話以前に書いた人間による差分が大きい。
ただ、C言語になると実測でチューニングした人間によって一千倍ぐらい違ったとか、そういう話になるが、スクリプト言語だと数倍~数十倍で目立ちにくい。
ただ、本当に、書いた人間によって速度は違う。言語じゃない。
下手すりゃCで書いてるのにスクリプト言語より遅いとかもありえる。
「スクリプト言語」のJIT実装が続々登場してる以上、
もともとインタプリターだった事は速度面で足枷にならんよ。