kなんとかの日記 このページをアンテナに追加

2010-06-13

プログラミング言語の優秀さと道具としての評価は別

| 08:38 |  プログラミング言語の優秀さと道具としての評価は別 - kなんとかの日記 を含むブックマーク

ワシは、cgi.rb なんかが標準添付になっている RubyPHPdis る資格はないと思ってる (cgi.rbの元ネタである CGI.pm を擁する Perl も同じじゃないかな)。cgi.rb は、標準添付モジュールのくせにコードが汚いし遅いし、cgi[] の戻り値が String だったり File だったりするし、どう考えても設計ミス。

## Ruby だと
cgi = CGI.new
p cgi['name']    #=> これが File である可能性がある

## PHP だとそんな問題はない
$name = $_REQUEST['name'];   # 必ず文字列
$file = $_FILE['name'];      # ファイルは別途取り出す

そして大半の Rubyist はこういった問題に気づいてすらいない。そういう人たちが PHPdis ってるのは「ハァ?」と思う。

実は Python も似たようなもん。知ってるか、21 世紀になって 10 年近くたつというのに、Python 標準添付の cgi.py はセッション機能をサポートしてないんだぜ? びっくりだろ。しかも Google App Engine でも Python SDK ではやっぱりセッション機能が用意されてない。Pythonセッションになんか恨みでもあるのだろうか。加えてプロセスの起動はトロいわ、cgi.py の読み込みはもっとトロいわで (これは urllib.py のせい)、ちょろっとした掲示板を作りたいときに Python を選ぶのは躊躇する。まあ Python は昔から mod_python が優秀だったから CGI はさほど重要視されてなかったのかもしれんけど、それでも wsgiref を標準添付するまえにやることがあるんじゃねーの? と思う。


結局のところ、言語としての優秀さと道具としての評価は別の話ということだよね。これは言語の速度とアプリケーションの速度とは別の話であるのとよく似ている。RubyPythonプログラミング言語としてはすごくよくできているけども、Web アプリケーションを作る道具としての評価は、ワシからみると PHP とそれほどの差はない*1

逆に初心者向けでいえば、PHP のほうがずっとよく出来ている。初心者が RubyCGI スクリプトを作成すると、

  1. まずファイルに実行属性をつけるところでつまづく (そんな高度な概念は理解できない)。
  2. 次に #!/usr/local/bin/ruby の書き換えがわからなくてつまづく (そんな暗号は理解できない)。
  3. 最後に 1 行目が「"#!/usr/local/bin/ruby\r\n"」となっているせいで理解不能なエラーになってつまづく (←ワシもワシも)。

これに比べると、PHP は天国だ。なにせ拡張子を「.php」にするだけでいい。これは初心者でも分かりやすい! つまづくポイントが少ない方が、道具としては優秀だ (まあ PHP はそれ以外のところではまりポイントが多数あるけど)。

ドキュメントもそうだよね。PHPの公式ドキュメントは優秀すぎる。関数の一覧も見やすいし、検索もできるし、有益なコメントがついててこれがまたドキュメントの価値を高めている。これに比べて Ruby のドキュメントは、揃ってはいるんだけど、見やすさや検索性という点ではダメダメ。これを初心者が見て理解できるかというと、まあ難しいよね (そういうわけで、このプロジェクトには期待してる (競争が発生するという意味で))。言語を「道具」として見た場合、ドキュメントは非常に重要。この点でいえば、PHPRubyPython よりも優秀な道具だといえる。


「言語の速度 != アプリの速度」という話をすると、スクリプト言語屋さんはだいたい同意してもらえる。けどそういう人でも「言語の優秀さ != 道具としての優秀さ (道具としてみれば RubyPHP もさほど変わんないよ?)」という話をすると、怒ったり無理な反論したり感情的な態度になる (ここらへんの反応とだいたい同じだと思えばわかるだろうか)。

でもさ、「言語としての優秀さと道具としての評価は別」なんて、よく考えたら当たり前のことでしょ? いくら RubyPython が優秀だからといって、Windows 用のゲームを作りたい人にとっては VBHSP のほうが優秀な道具なわけよ。あるいは英語がわからない子供にとっては、道具としてはなでしこのほうが優秀なわけよ。優秀な言語がいつも優秀な道具であるとは限らない。そんなの当たり前のことでしょ?

だから、Rubyist や Pythonista が PHP の言語仕様を dis るのは別にいいけどさ、確かにプログラミング言語としての RubyPython は本当によくできてるけどさ、それと道具としての価値はまた別だということを知ってほしい。そんなこととっくに知っとるわい! という人はぜひ cgi.rb の代替物を作るか cgi.py にセッション機能を追加するか urllib.py の _hextochr まわりを修正してから出直してきてほしい。

#他の言語屋さんから dis られて困っている PHPer の方がいたら教えてください。相談にのります。


今日のまとめ:「言語仕様の優秀さ != 道具としての優秀さ」


・・・え、PHP は道具として優秀じゃないって? そこはぜひ Read Air, PLEASE!!


(追記)

ngsw プログラマではないけれど、言語がそもそも道具だと思うんだ。だから評価は不可分なんじゃないでしょうか。 2010/06/14

http://b.hatena.ne.jp/ngsw/20100614#bookmark-22280889

道具としての価値を決定する要素は、言語仕様以外にもいろいろありますよ、ということです。

oukayuka CGIなんて誰も使ってないから放置されてるだけじゃないの? Webフレームワーク全盛の時代にCGIがダメだからこの言語はダメなんて言う人がいるとは思わなんだ。 2010/06/13

http://b.hatena.ne.jp/oukayuka/20100613#bookmark-22280889

キミはせめてtdiaryhikiぐらいは知るべき。Matz日記もるびまcgi.rbに依存してるじゃないか。

こういうこと言ってるのはきっと事情をよく知らないRails使いに違いない。Railsだってcgi.rb使ってる (た) のにね。

#つうか標準添付ライブラリが放置されてたらまずいだろww

denchuinc ruby 最近RubyでWebプログラミングする人たちって,cgi.rbなんて使ってるのかしら? 拡張子phpにすれば良い,ってのもサーバ側の設定次第な気が……。2010/06/13

http://b.hatena.ne.jp/denchuinc/20100613#bookmark-22280889

キミもtdiaryhikiを知った方がいい。それともcgi.rbを使ってるtdiaryhikiに対するあてつけか? 高度だなあ。

ssig33 はあ、 cgi.rb の代替って sinatra でいいんじゃないですかね 2010/06/13

http://b.hatena.ne.jp/ssig33/20100613#bookmark-22280889

動作がひどく遅い require 'rubygems' が必要な時点で、代替にはならないんじゃないですかね。

あと代替として推薦するならsinatraじゃなくてrackじゃないですかね。

nazoking PHPの $_REQUEST[xxx] は配列が入ってることがあるよ! 2010/06/13

http://b.hatena.ne.jp/nazoking/20100613#bookmark-22280889

それはキーとして「"xxx"」じゃなくて「"xxx[]"」を指定したとき*だけ*だよね。取り出すデータをプログラマがコントロールできるならそれでいいけど、cgi.rbの場合は違うから。

*1:もちろん今なら RailsDjango の存在が前提だろうけど、そこまで含めるとそれは RailsDjango の評価であって RubyPython の評価じゃないし、PHP だってたくさんのフレームワークがある。

hitachitac 2010/06/13 09:50 PHPの言語仕様に文句をつけている人がWebアプリを作成する道具としてのPHPにまで文句を付けている事ってそんなにありますかね?
大抵は、Webアプリを作る場合の手軽さは評価してる事が多いと思いますが。

gg 2010/06/13 10:01 基本的にPHPを批判するのって「言語仕様がアホ」だからですよね。
少なくとも道具としてのPHPは一級品だと思います。事実、自分で書く動的WebページはPHPで書いていますし。

というか「道具としての優秀さ」は比較できるものではないですよね。
「道具」は「用途」があって初めて比較できる。

VB LoverVB Lover 2010/06/13 12:11 PHPはWebプログラミング界のVBや!

kwatchkwatch 2010/06/14 01:08 hitacさん:
> PHPの言語仕様に文句をつけている人がWebアプリを作成する道具としてのPHPにまで文句を付けている事ってそんなにありますかね?

『道具としてのPHP』どころか、PHPを使ってる人のことまで侮辱してますよ。なにか、いじめの深刻さを把握できてない教師のようですね。
http://blog.livedoor.jp/dankogai/archives/50993137.html

gさん:
> というか「道具としての優秀さ」は比較できるものではないですよね。
> 「道具」は「用途」があって初めて比較できる。

はい、まったくその通りです。でも「必ず <?php ?> を書かないといけないPHPはCLIに向いてないからダメだ」というような、用途を勘違いした批判をしてる人もいるんですよ、困ったことに。
http://blog.livedoor.jp/dankogai/archives/50835571.html

VB Loverさん:
> PHPはWebプログラミング界のVBや!

まったくその通りです。言語としてはウンコだけど、道具としては結構使える。

authorNariauthorNari 2010/06/14 10:04 > プログラミング言語の優秀さと道具としての評価は別
その通りだなと思いました。cgi.rbよりはPHPの方がよさそうだなーと思います。

> cgi.rb なんかが標準添付になっている Ruby に PHP を dis る資格はない
この辺りが少し引っかかりました。
アフターRails世代のRubyistって「あぁ、俺はcgi.rbを使ってるー」って人は
あまりいないのじゃないでしょうか(僕とかそうなんですけど)。記事にも書
かれている通り、sinatraとかRailsとかはすでにrack使ってますしね。

cgi.rbをあんまり意識していないRubyistがPHPをdisれないのだとしたら、それ
はなんか「自分が完全完璧じゃないと、人を指摘してはいけない!」ような雰
囲気になってしまってちょっと嫌かなぁと、というのが率直な感想です。

あ、cgi.rbもPHPもヘビーに使ったことはない素人考えなので、全然スルーして
もらって結構です(汗)。

defdef 2010/06/15 01:41 言語としての優秀さと言語仕様の優秀さは別じゃないですかね。そして、Ruby の言語仕様についても批判はありますし。

http://wota.jp/ac/?date=20100604#p01

kwatchkwatch 2010/06/15 07:04 authorNariさん:
> cgi.rbをあんまり意識していないRubyistがPHPをdisれないのだとしたら、それ
> はなんか「自分が完全完璧じゃないと、人を指摘してはいけない!」ような雰
> 囲気になってしまってちょっと嫌かなぁと、というのが率直な感想です。

・「disる」と「指摘する」は違うと思います (ただの指摘をdisられたと感じる人もいますけど)。
・相手よりひどい欠点がある (かつそれに気づいてもいない)
のに相手をdisるのがまずいのであって、『自分が完全完璧じゃないと…』なんて思う必要はまったくないと思いますし、その心配は杞憂じゃないでしょうか。
・「自分はrails以降の人間でcgi.rbなんか意識してないから云々」というのは、単に自分の無知を棚に上げてるだけのように見えます。まあ知らないままで相手をdisるのも言論の自由なんでしょうけど、傍から見るとギャグにしか見えません。

authorNariauthorNari 2010/06/15 09:04 > 「disる」と「指摘する」は違うと思います
あ、なるほど。何も知らないまま、PHPを批判してしまうようなことは駄目だ、とこの記事でいってたんですね。理解不足でした…。納得です。

arikui1911arikui1911 2010/06/16 10:35 > cgi.rb なんかが標準添付になっているRuby
つまり標準添付から外せばいいのです。
極論ですかね。代替もないし。
webrick/cgiはPythonのcgi.pyのようにセッション機能がありませんし。

kwatchkwatch 2010/06/17 21:57 authorNariさん:
主題はそこではなくて、あくまで「言語仕様の優秀さ != 道具としての優秀さ」です。PHPを批判するための条件とかそういう話ではないです。

arikui1911さん:
ご自身で分かってられると思いますが、極論です。cgi.rbを改善するか、または代替物を用意することが正攻法であり、cgi.rbを標準添付から外すことは問題から逃げてるだけ。

   2014/06/21 02:44 なんか必死で憐れだなw

2010-05-01

高速なプログラミング言語が生み出す本当の価値

| 10:29 |  高速なプログラミング言語が生み出す本当の価値 - kなんとかの日記 を含むブックマーク

なんか、はてなブックマークとか見てると残念なコメントが多いよなー。『こんな比較は意味ない』とか『できることがまったく異なるテンプレートを並べて比較されても』とかいうやつ、何なの?「言語の速度 != アプリの速度」という主張を示したベンチマークなんだから別におかしくないじゃん。主旨がまるで分かってもらえてない。ネットワークデータベースの処理まで含めて計測したら、「言語の速度 != アプリの速度」という主張がより鮮明になるだけじゃね?

反論する人があまりに残念な反論しかできないようなので、かわりに自分で「高速な言語を使う理由」を説明する (一人マッチポンプ状態じゃねーか)。



  ・  ・  ・  ・


言語が速いことによる本当の利点は、採用可能なアーキテクチャが広がることだと思う。新しいアーキテクチャを思いついたので採用したいが、スクリプト言語ではどうやっても満足な速度が出せなかったのが、Java や C のような高速な言語で実装し直したら現実的な速度に収まった、というケースは確かに存在する。これは、言語の速さのおかげで採用可能なアーキテクチャが広がることを意味していて、この点は高速な言語の大きなアドバンテージだといえる (アーキテクチャは大事だからね)。

実際の例で紹介する。またテンプレートエンジンの例で申し訳ないが、Python には Kid というテンプレートエンジンがある。これは、PHP や eRuby や Velocity のような HTML テンプレートを「汚す」タイプとは違い、HTML テンプレートをクリーンに保てることが特徴である。仕組みとしてはこんな感じ:

この仕組みの利点としては、HTML テンプレートが汚されないのでデザイナにとって優しく協業しやすいことと、ほぼ完全な HTML エスケープが行える (エスケープし忘れが発生しない) ことである。この利点は非常に大きい。

ただ、動作速度は極めて遅い。どのくらい遅いかは前のグラフのいちばん下を見てもらえばわかるけど、速いテンプレートエンジンと比べてだいたい 1/60 ぐらいの速度。これは「DOM ツリーを作成・操作・HTML へ変換」という作業を毎回やっているせい (そりゃ遅いよね)。このくらい遅いと、実行時間の大部分がテンプレートエンジンで費やされてしまう。Kid を改良した Genshi というのもあるけど、これもやっぱりすごく遅い。この手のタイプが遅くなるのは、アーキテクチャ上仕方ない。

ところで、これとよく似た Java 用のテンプレートエンジンに XMLC というのがある。というかこっちの方が本家で、Kid のほうがあとから真似たんだけど、どちらも「DOM ツリーを作成・操作・HTML へ変換」という基本アーキテクチャは同じである。

ただ Kid と違って、XMLC のパフォーマンスは良好である。たしか「実践J2EEシステムデザイン」にベンチマークが載ってたと思うんだけど、それによると Velocity より速いらしい。その理由は、XMLC ではプレゼンテーションロジックJava で記述し、変な独自言語やインタプリタを導入していないため。つまり Velocity と違って、静的言語である Java のよさとパフォーマンスをそのまま享受できるわけだ。もちろん本自体が昔の本なので現在ベンチマークをとるとどうなるかはわからないけど、独自言語の動的なインタプリタを使う Velocity よりは、アーキテクチャ的には不利でも素直に Java をそのまま使った XMLC のほうが速いというのは納得できる。

Kid も XMLC も基本となるアーキテクチャはよく似ており、どちらもデザイナに優しいテンプレートエンジンである。ただ動作速度的には不利なアーキテクチャであることも事実であり、実際 Kid のパフォーマンスはすごく悪い。しかし Java をそのまま使う XMLC は、速度的に不利なアーキテクチャでも実用的な速度で動作する。

この点こそが、高速な言語を使う利点だと思う。DOM ツリーを作らないアーキテクチャなら Python でも非常に高速なテンプレートエンジンを作ることは可能。でもデザイナーに優しいテンプレートエンジンを作りたいから DOM ツリーを使うアーキテクチャにしたいと思ったとき、pure Python では非常に遅いテンプレートエンジンしかできない。しかし Java なら速度的に不利なアーキテクチャでも現実的な速度で動かせる可能性が高い。つまり高速な言語のほうが利用可能なアーキテクチャの幅が広がるというわけ。

なおデザイナーに優しいテンプレートエンジンを作るには必ずしも DOM を作る必要はない。ちょっと考えればわかるけど、動的に操作したい要素は HTML テンプレートの中の一部だけなんだから、そこだけ操作できるようにしてやればよいわけで、ページ全体を DOM に変換して操作するのは無駄すぎる。その点でいうと、Kid も XMLC もアーキテクチャを改良する余地は多いにある。


今日の結論: 高速な言語のほうが利用可能なアーキテクチャの幅が広がる。


#ちょっとタグをつけすぎたかも。ごめんなさい。


ひがさんからのありがたいお言葉

| 10:29 |  ひがさんからのありがたいお言葉 - kなんとかの日記 を含むブックマーク

ひがさんから、ありがたいお言葉を頂戴しましたので紹介させていただきます。



f:id:kwatch:20100501094033p:image

#釣り認定されちゃった。わーい。

んー、「言語の速度 != アプリの速度」という主張を示すにはあれで十分だと思いますけど。データベースネットワークまで含めて計測したら、それこそ言語の速度に関係ない部分が増えるわけですから、先の主張がもっと強調されるだけです。そういった、明らかに言語に関係のない部分を含めなくても「言語の速度 != アプリの速度」というのがよくわかるという点で、あのベンチマークは十分意味があると思いますが、いかがでしょうか。

テンプレートの処理の全体に対する時間の割合が出てない』とおっしゃってますけど、それこそ採用するテンプレートエンジンやアプリケーションの内容で大きく違うんだから、出してもあんまり意味ないと思いますよ。出したところで「言語の速度 != アプリの速度」は変わりませんし。それでもデータを出せというのでしたら、どれだけ意味があるかわかりませんけど、ビュー層の改善だけでアプリケーションの速度が 2 倍になった例とか、Django のテンプレートを止めることで最大 30 パーセント高速化した例とか、あとは Google の人によるこの説明を読んでください。

Unladen Swallow's benchmark suite is focused on the hot spots in major Python applications, in particular web applications. The major web applications we have surveyed have indicated that they bottleneck primarily on template systems, and hence our initial benchmark suite focuses on them:

Unladen Swallowのベンチマーク集は、主要なPythonアプリケーション、特にウェブアプリケーションホットスポットにフォーカスしている。我々が調査した主要なウェブアプリケーションでは、主にテンプレートシステムがボトルネックであると分かった

Google Code Archive - Long-term storage for Google Code Project Hosting.

(翻訳は日本語訳より引用、強調は筆者)

Google の見解では、テンプレートシステムがボトルネックだそうです。他にもボトルネックはあるはずですけど、わざわざ『主にテンプレートシステムがボトルネック』と言うくらいだから、けっこうなボトルネックだったのでしょう (まあ Djangoテンプレートエンジンは遅いですから)。

日本を代表するアーキテクトであるひがさんには、ぜひ Google の主張を蹴散らすような調査結果を出していただき、ひいては筆者の釣りレベルを判定していただきたい所存であります。なお補足すると、eRuby より速いテンプレートエンジンを使えば、通常はそこがボトルネックになることはまずないです (eRuby より遅いとボトルネックになっている可能性はあります)。


ちなみにご自身で Web アプリを作って計測すればわかると思いますけど、言語による Web アプリケーションの速度の違いって思ったより小さいんですよ。たとえばデータベースアクセスはボトルネックのひとつですけど、JDBC と Ruby/Python 用のデータベースライブラリでは大した性能差はないです。それよりフレームワークライブラリアプリケーションサーバによる違いのほうがずっと大きくて、たとえば Ruby on Rails がクソ遅いのは Ruby のせいじゃなくて Ruby on Rails そのものが遅いせいだとか、JSFJava とは思えないくらい遅いとか、mod_python がえらい高性能だったりとか、そういうのを体感すると言語の速度を競うのがすごくばからしくなります。自分が測定したときはキャッシュを使わないで計測しましたが、キャッシュを含めるとますます言語の速度が関係なくなります。ですから、キャッシュとかネットワークとかを含めない、言語のみのベンチマークのほうが、「言語の速度 != アプリの速度」がよく分かるんじゃないでしょうか。その点をふまえて考えると、あのベンチマークはきちんと意味があると思います。つうか、きちんと測定したデータを測定してない人に頭ごなしに否定されるとか意味分かんない。


あと、もしできたらでいいんですけど、twitter でコソコソ反論するんじゃなくて、ブログのコメントやトラックバックを使って反論していただけると幸いです。

#まあ『釣りレベルがわかるというもの』とのことなので、ひがさんから見下されていることはよくわかりましたw



f:id:kwatch:20100501101709j:image

レベルが低くてすみません。


  ・

  ・

  ・


あっ、でも、釣りレベルは高いかもしれませんよ、ひがさんに認定されるくらいにはww

tsgrtsgr 2010/05/07 16:28 むしろ結論は「言語の速度 != アプリの速度」とか「高速な言語のほうが利用可能なアーキテクチャの幅が広がる」みたいな極めて自明な事よりも「みんなベンチマーク大好き」とするべきでは?

kwatchkwatch 2010/05/13 18:10 > 極めて自明な事

ほとんどの人にとっては、自明ではありません。JSPやVelocityがPHPやeRubyより遅い事実すら知らない人が大勢いるでしょう。

> みんなベンチマーク大好き

これは強く同意。

2010-04-30

プログラミング言語の速度とアプリケーションの速度がいかに関係ないかがわかるグラフ

| 08:51 |  プログラミング言語の速度とアプリケーションの速度がいかに関係ないかがわかるグラフ - kなんとかの日記 を含むブックマーク

まずは次の表をご覧あれ。これはプログラミング言語ベンチマークとして有名な Computer Language Benchmarks Gameベンチマーク結果。上にいくほど高速で、下に行くほど遅い言語になる。

f:id:kwatch:20100429184937p:image

これを見れば、最速な言語は C/C++ であり、JavaHaskellOCaml といった静的な言語は軒並み上位に登場する。これに対し、RubyPythonPHP といったスクリプトは全部下のほう (つまり遅い)。その速度差は非常に大きく、このベンチマークで見ると Python3 や Ruby1.9C/C++ の約50倍から60倍遅く、Perl は約90倍、PHP にいたっては約130倍遅いことになる。

(ちなみに JIT つきの Lua が驚異的に高速なのが目をひく。この結果が本当だとしたら、言語の速度に大きく関係するのは動的か静的かではなく、どれだけ優秀な JIT を搭載しているかが大事ということがいえるかもしれない。)


   ・  ・  ・  ・  ・


さて、スクリプト言語は軒並みトロいということが分かったうえで、次のグラフをご覧頂きたい。これは各プログラミング言語でのテンプレートエンジンのベンチマーク結果である。約3年前の結果なのでバージョンは古めであるが、今でも参考にはなるはず。Test1 はテンプレートを毎回読み込むテストであり CGI 向け、Test2 はテンプレートを最初の1回だけ読んで使い回すテスト*1であり FastCGI や mod_xxx 向けである *2

f:id:kwatch:20100429185643p:image

(クリックで拡大)

これを見ると、Java や C で実装されたテンプレートエンジンが必ずしも最速ではないことが分かる。たとえば Velocity は Java の有名なテンプレートエンジンだが、実は性能は eRuby にすら劣ることがわかる*3。また C で実装された Cheetah や Template-Toolkit も、pure Python や pure Perlテンプレートエンジンに思いっきり負けている。さらに、さきほどの言語別ベンチマークでいちばん遅かった PHP が、このベンチマークでは最速の地位にいる*4

またこのグラフには出てないが、JSP は Velocity より遅いことが分かっている。そもそも Java は静的であることが強みのはずなのに、Velocity にしろ JSP (EL) にしろ動的な言語を導入しているのだから理解に苦しむ。わざわざ Java の強みを捨ててまで、動作も遅くなるものを導入する必要があったのだろうか。あるいは <c:out/> のかわりに ${fn:escapeXml()} を使うとか、性能に無頓着すぎるだろ*5

Java のように高速な言語でも、Velocity や JSP のようなアーキテクチャではたいして速度は出せない。逆に RubyPHP のようにスクリプト言語の中でも遅いと言われるものでも、正しいアーキテクチャを採用すれば十分な速度は出せる。言語の速度を気にするのも結構だが、もっと重要な要素があるんだからそっちを気にしたほうがいい。


   ・  ・  ・  ・  ・


このように、プログラミング言語の速度とアプリケーションの速度は、必ずしも一致しない。一致しないどころか、まるで関係ないと言っても差し支えないぐらいである。もちろんテンプレートエンジンの速度でアプリケーションの速度を測れるわけではないが、「必ずしも一致しない」という結論は変わらない。

だから、たとえばPHP と Perl とをちまちま比較してもいいけど、その程度の差でどちらが速いかを結論づけても大して意味はない。それより「PHPPerl (や RubyPython) ではこの程度の差しかない」ことが認識できればそれでよく、あとは各自アプリケーションチューニングにいそしむべきだろう。少なくも「PerlPHP より速いんです (キリッ」と言いながら Template-Toolkit を喜んで使っているやつや、「Java は速いんです (キリッ」と言いながら喜んで ${fn:escapeXml()} 使ってるやつは何も分かってないから、そんなやつらがいたらハナで笑ってよい。


今日のまとめ:プログラミング言語の速度 != アプリケーションの速度


なお複数の言語を使ったベンチマークでよさげなのがあれば紹介して下さい。ぐぐってみた限りでは他によさそうなのが見つからんかった。

*1:つまり Test2 であればディスク I/O の影響はほとんど受けない。ファイルキャッシュを考えると Test1 もほとんど影響をうけないと思われる。

*2:このベンチマークでは HTML エスケープはやってないが、HTML エスケープすると性能はだいたい半分に落ちると思えばよい。

*3:Velocity は 1.6 で速度がもう少し向上しているので、今なら eRuby に勝っているかもしれない。

*4:なおこのベンチマークでは Perl があまりぱっとしないが、Perl の潜在能力はこんなもんじゃないことを付け加えておきたい。

*5:${fn:escapeXml()}はELレベルでの関数呼び出しになるから、<c:out/>よりかなり遅い

apollo440apollo440 2010/04/30 12:18 ・・・えーっと、引き合いに出しているのはxx用テンプレートエンジンの速度(=作りかたの上手/下手)であって、xx言語の最大能力(=いわゆるベンチマーク)ではないのでは・・・。

apollo440apollo440 2010/04/30 12:21 ^あぁ、訂正。だからタイトルどおり、ってことですね。

anonymousanonymous 2010/04/30 13:41 二つ目のような物をみた気が…と思ったらこれでした。
Googleのリンクをそのままコピペしたので変なことになってます。

[PDF]An Example of Ruby Program Faster Than C 『言語の性能の違いが速度 ...
www.kuwata-lab.com/presen/rubykaigi2007.pdf

PsychsPsychs 2010/04/30 16:10 > これを見ると、Java や C で実装されたテンプレートエンジンが必ずしも最速ではないことが分かる。

いや、Tenjin は C で実装されているわけですが。このベンチマークから読み取れるのは、単に C で書かれている Tenjin が速いということだけでしょう。

通りすがり通りすがり 2010/04/30 18:08 javaに対する評価を多く記述されているようですが、javaでwebシステムを構築されたご経験がない方のようですね・・・
もしくは、テンプレートエンジンへのコーディングだけで完成できるような、非常に小規模なシステムしかご経験がないのでしょうか・・

一般的にjavaでwebシステムを構築する際には、JSPやVelocityなどのテンプレート上に全ての処理の記述なんてやりません。

複雑であったり、速度が要求される処理は全てクラス内で終わらせ、JSPでは計算結果のリスト等を表示するだけです。

つまり、高負荷な処理は全て静的なレイヤーで行ってしまうので、テンプレートエンジンの速さがうんたらと言われても、それがjavaの実行速度の全てと捉えてしまうのは判断が甘すぎます。

さらに通りすがりさらに通りすがり 2010/05/01 03:01 >一般的にjavaでwebシステムを構築する際には、JSPやVelocityなどのテンプレート上に全ての処理の記述なんてやりません。

だから言語の速度なんてのは関係ない。
いかに組上げるかって話じゃないの?
誰もそれが実行速度の全てって言ってないし。

ちゃんと文脈読み取ってから批判しようよ。

kwatchkwatch 2010/05/01 09:36 PsychsPsychs さん:
> いや、Tenjin は C で実装されているわけですが。

え?そんなことないはずですけど。もし C で実装されているなら、ぜひソースを紹介してください。


通りすがりさん:

> つまり、高負荷な処理は全て静的なレイヤーで行ってしまうので、テンプレートエンジンの速さがうんたらと言われても、それがjavaの実行速度の全てと捉えてしまうのは判断が甘すぎます。

エントリの主旨は「言語の速度 != アプリの速度」です。だれも『javaの実行速度の全て』とは言ってないんじゃないでしょうか。通りすがりさんがそう取り違えただけで。


さらに通りすがりさん:

> ちゃんと文脈読み取ってから批判しようよ。

主旨が伝わらないのはやはり書き手の技量の問題かなと思います。どなたか存じませんが、こちらの能力不足のせいでお手をわずらわせて申し訳ない。

blastydotblastydot 2010/05/01 13:10 >Template engine should use their host language directly unless there are some kind of reasons.

http://www.kuwata-lab.com/tenjin/pytenjin-faq.html#faq-why-so-fast

アセンブラかもしれんけど、まあ、Cかな。

元のベンチマークは13種類のプログラムを走らせて総合的に言語性能を導き出そうとしているのに対し、なぜかテンプレートエンジンを持ち出して、アプリケーション性能を語るのは不自然。
これだと言語なんか関係ないでしょ。

そもそも、元のベンチが多種の処理を持ち出して示しているのは、結局のところ、アプリケーション性能には言語性能は密接に関連しているということそのもの。

blastydotblastydot 2010/05/01 14:08 あと、趣旨は〜だといいながら、JSP批判で自己完結してるようにしか見えないのも不自然ではあるな。

通りすがり氏は趣旨を読み違えているというよりも隠しきれてない部分に突っ込んでるだけでは。

そもそも、DB周りで変なことしてるならともかく、ページ出力部分で神経なんか使ってられんでしょ。jk
ページ出力が命って言語からするとJSPとか馬鹿に見えるのはしかたないとは思う。
同様に、アプリの性能だといいながら、結局テンプレートとかページ出力部分にしか着目してないのは低次元だと思われてもしかたがない。

おっさんおっさん 2010/05/02 15:28 そもそも、2種類のベンチマークでどうこう言うなら、ハードウェアとOSくらい、同じ物で比較しないと意味ないんじゃないの?
乱暴すぎで、妄想だと言われてもしょうがない気がする。

kwatchkwatch 2010/05/13 18:26 > blastydot 2010/05/01 13:10
> >Template engine should use their host language directly unless there are some kind of reasons.
>
> http://www.kuwata-lab.com/tenjin/pytenjin-faq.html#faq-why-so-fast
>
> アセンブラかもしれんけど、まあ、Cかな。

えーと、これは何がいいたいのかな?まさかこれが「tenjinがCで実装されている理由」のつもりじゃないですよね。もしそうならバカすぎる。

> 元のベンチマークは13種類のプログラムを走らせて総合的に言語性能を導き出そうとしているのに対し、なぜかテンプレートエンジンを持ち出して、アプリケーション性能を語るのは不自然。
> これだと言語なんか関係ないでしょ。

はい?なんで『言語なんか関係ない』の?

> そもそも、元のベンチが多種の処理を持ち出して示しているのは、結局のところ、アプリケーション性能には言語性能は密接に関連しているということそのもの。

元のベンチって、shootoutのことですよね。ちゃんとベンチみました?フィボナッチとかN体問題とかCPU boundなものに偏っていて、世間一般で使われる業務アプリやらWebアプリとはかけ離れてますよ。

> blastydot 2010/05/01 14:08
> あと、趣旨は〜だといいながら、JSP批判で自己完結してるようにしか見えないのも不自然ではあるな。
>
> 通りすがり氏は趣旨を読み違えているというよりも隠しきれてない部分に突っ込んでるだけでは。

『隠しきれない部分』!これは流行る!

> そもそも、DB周りで変なことしてるならともかく、ページ出力部分で神経なんか使ってられんでしょ。jk

神経使う必要ないでしょ、どのテンプレートエンジンでも。方向がずれた反論はバカさ加減が目立つだけだからやめたほうがいいと思う。

> ページ出力が命って言語からするとJSPとか馬鹿に見えるのはしかたないとは思う。

関係ねーーー!

> 同様に、アプリの性能だといいながら、結局テンプレートとかページ出力部分にしか着目してないのは低次元だと思われてもしかたがない。

アプリの性能はキャッシュやネットワークが加味されて言語速度の要素が薄まるので、『言語の速さ!=アプリの速さ』を裏付けるなら、キャッシュもネットワークも入らないベンチのほうがいいでしょ。


> おっさん 2010/05/02 15:28
> そもそも、2種類のベンチマークでどうこう言うなら、ハードウェアとOSくらい、同じ物で比較しないと意味ないんじゃないの?
> 乱暴すぎで、妄想だと言われてもしょうがない気がする。

なんでやねん。shootoutのベンチマークとテンプレートエンジンのそれとは別個に評価してるんだから、ハードもOSも別でいいじゃん。

にこっにこっ 2012/12/14 10:47 たぶん、エントリーの投稿者は誰も返信しないのを見て勝ち誇った顔をしているのでしょうけど、
少し深い知識を持った人なら呆れた顔で見ているでしょうね。

具体的な反論になって無いなどと言い出すのでしょうけど、
もう少し柔軟な頭を持つようにしましょう。

頑張って下さいね。

あかさあかさ 2013/03/17 10:08 お前らと下は頭悪すぎるゴミ屑以下だな。

名無し名無し 2013/09/11 00:12 簡単なことをまわりくどく書いているから誤解をされているんだろうね。。。

たいちたいち 2017/07/26 19:11 これの批判的なコメントしている方々はちゃんと文を読んでいるのかな?
『プログラミング言語の速度 != アプリケーションの速度』
なんて当たり前で、投稿者その一例を出してくれているんでしょ。。
特に → にこっさん
全く意味のないコメントをしているあなたの方がもう少し考えた方がいいのではないでしょうか。。。

たいちたいち 2017/07/26 19:11 これの批判的なコメントしている方々はちゃんと文を読んでいるのかな?
『プログラミング言語の速度 != アプリケーションの速度』
なんて当たり前で、投稿者その一例を出してくれているんでしょ。。
特に → にこっさん
全く意味のないコメントをしているあなたの方がもう少し考えた方がいいのではないでしょうか。。。

2010-04-29

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

| 15:59 |  Re: スクリプト言語の息の根を止めるのは案外 SSD かもな - kなんとかの日記 を含むブックマーク

まえのエントリのコメント欄より:

flat8 2010/04/27 10:19

確実にIntelはそこまで考えていると思います。で、ある程度SSDが普及したらSSD自体の製造からは手を引くでしょうけど。

やはりそうでしょうか。さすがIntel

ところでIntelが『SSD自体の製造からは手を引くでしょう』という根拠は何でしょうか。CPU ほどは儲からないからかもしれませんが、減価償却の終わった製造施設で生産できるなら、Intel としては悪くない分野だと思うので、製造は続けていくように思います。

通りすがり 2010/04/27 11:31

クライアントコードの処理時間(コスト):バックエンドの処理時間(コスト)の考察無しには、SSD時代になったとしても一概にスクリプト言語不利とも言えないのではないでしょうか。

SSDによりディスクI/Oボトルネックが大きく軽減されることは、スクリプト言語にとって不利になるのは間違いないと思います。あとはそれがどのくらい不利かが問題。さほどの不利ではないという考えも当然できますが、それは人によって判断が異なるでしょう。

yuki_hero 2010/04/27 12:10

まぁ、巨大な企業は、社会基盤そのものにも目をつけていますから...

目をつけられない頭の悪い企業も多いですけどね。特に日本は。

cpw 2010/04/27 12:43

アプリケーションサーバは分散が容易とういうことを忘れてはいけませんよ。サーバも安くなってきてますしね。人件費の方が高コストです。

アプリケーションサーバは分散が容易』ですが、数千台・数万台という規模になると、さすがにそうもいってられないでしょう。サーバ自体は安くても土地代や電気代や光熱費はばかにできませんし、もし仮にですがスクリプト言語を止めることでサーバ台数が 1 ケタ減らせるぐらいの効果があれば、さすがにスクリプト言語は使わないと思いますよ。あくまで仮定の話ですが。

あと『人件費の方が高コスト』というのはその通りですが、今の話とどう関係が?スクリプト言語のほうが人件費を削減できるとでも?

Goat 2010/04/27 13:02

ボトルネックになるのはストレージだけではないでしょう。PHPはもちろん、RubyPythonPerlも多くはウェブ系のシステムに使われていると思いますが、そういう場合ではネットワークボトルネックになってきます。

そして、スケールアップよりもスケールアウトという流れの中でますますその傾向は強くなっています。

仮にコードがボトルネックになったとしても、多くの場合はアルゴリズムに問題があるのであって、そこを改善してオーダーを変えてしまえば、5倍〜10倍の差なんて問題にならなくなりますし、そもそもタイムクリティカルミドルウェアでは今でもCやC++が主流なのでSSDスクリプト言語に与える影響はほとんどないのではないかと思います。

はい、ボトルネックストレージだけではありません。しかしストレージ以外のボトルネックも将来は解消される可能性が十分あり、そのときに備えて手は打っておくべきだと思います。

あと『多くの場合はアルゴリズムに問題がある』というのは本当に実感します。これについては別途エントリを書きます。

通りすがり 2010/04/27 13:44

インタプリタコンパイルかで速度が極端にかわるようなら、単純にPerl,PHP,Ruby,Python等で静的コンパイルできるようにするんじゃないかなぁ〜?

インタプリタ型言語も内部的にはコンパイルしてから実行してますし、さすがにこのコメントは的外れでしょう。

muha 2010/04/27 13:51

逆にますますインタプリタが使われると思う。 人件費より高いの無いでしょ

んー、インタプリタだと人件費が抑制できるという主張でしょうか。その根拠は?Java開発者よりPHP開発者のほうが単価が安いということ?

とことこ 2010/04/27 14:38

確かにトランザクションが多いところはそうなるかもしれない、

よく知りませんがスクリプト言語の作成効率が高ければ、そんなにトランザクションがおきないところは安く構築するために有効だと思われるので、そんな劇的にシフトはしない気がする。

これも「スクリプト言語のほうが安く済む」という前提のコメントですね。その根拠って何でしょうか。

Taruryun 2010/04/27 17:08

元のテストの結果は、僕が読む限り、

処理能力が頭うったのは

『DBサーバの』CPUに読めるんですが・・・。

もし息の根止められるとしたら、フロント用アプリケーションを書くための言語もろもろではなく、「SQLというスクリプト言語」でしょう・・・

元のテストは確かにDBサーバが対象ですが、「SSDによってディスクI/Oボトルネックが解消されるとスクリプト言語にとっては不利である」という考察は、DBサーバかどうかに関係なく成り立ちますよね?

apollo440 2010/04/27 21:46

いやいやいや、”全”プログラマーって。ストレージ使うのが当たり前じゃない世界もあるし、もうちょと範囲狭くして欲しい気が。

あと、(人気の)スクリプト言語は、「使いやすい」じゃなくて「遊びにはよい」かと。

まあ『ストレージ使うのが当たり前じゃない世界もある』のはその通りですが、元記事の興味深い結果はストレージに関係ないプログラマでも知っておくべきでしょう。

noname 2010/04/28 00:56

C++, javaで生活している者から一言


スクリプト屋(笑

が必死だなw

お互い様ですね。

negi 2010/04/28 18:04

仕事でjavaからphpに移って6年くらいだけど、

スクリプト言語

実行速度やコード書く速度とかより

バグが激しくてテストが半端ないよ。

誰かが書いたソースを使いたく無いし、

使おうと思うとソースの細部まで読まなきゃならなくなる

せめて返却値くらいは型を決めてくれ。

NULLの場合とBoolの場合とがあるって糞でしょ?

あとExceptionもだね。

俺もOCamlが何で流行らないのか疑問なんだよね。

OCaml関数型言語で手続き型から移行しやすい言語だと思う。

まあデフォルトで日本語使えねーって事もあるかもね。

camomileも開発止まってるのかな?

他はHaskellに期待してます。

スクリプト屋は一度、静的型付けの関数型言語をかじった方がいいと思うよ。

前半は言語よりも開発者の能力に大きく依存する話。C++Javaでその問題が解決するわけではありません。

後半のOCamlについては、単に普及させようとする人の熱意と戦略が足りないだけだと思います (怒られそうだけどあえて言う)。最後の一文は強く同意します。逆にC++Java屋さんはスクリプト言語をひとつぐらいマスターすべき。

anonymouseanonymouse 2010/04/29 23:35 >> スクリプト言語の作成効率が高ければ、
> これも「スクリプト言語のほうが安く済む」という前提のコメントですね。

「〜〜れば」なので前提ってのは誰が見たって分かる。

そうではなくてSSDがボトルネックを解消するかしないかよりも
単に「作成効率」の高い言語を選ぶのではないのですか?

自分の場合ではWebアプリはRubyが作成効率が高く,デスクトップアプリだとC#が高い。
人によってはLispが一番高い人がいるはず(※ただし個人開発に限る)。

kwatchkwatch 2010/04/30 08:57 > 「〜〜れば」なので前提ってのは誰が見たって分かる。
その前提内容を聞いているんですけど。

> そうではなくてSSDがボトルネックを解消するかしないかよりも
> 単に「作成効率」の高い言語を選ぶのではないのですか?
別に作成効率は無視していいと言ってるわけじゃないんですけど。
実行効率より作成効率を重視しても別に構わないと思いますし、それが悪いといった覚えもありません。選ぶ基準は人それぞれなので、あなたの好きな基準で選べばよろしい。
ここで言っているのは単に、SSDが普及すると言語の速さが今より重視されてスクリプト言語の人気が落ちるかもねといってるだけであり、作成効率で選ぶことに反対するというような話ではまるでないです。何か勘違いされてませんか?

anonymousanonymous 2010/04/30 13:31 >> インタプリタかコンパイルかで速度が極端にかわるようなら、
>> 単純にPerl,PHP,Ruby,Python等で静的コンパイルできる
>> ようにするんじゃないかなぁ〜?
>
> インタプリタ型言語も内部的にはコンパイルしてから実行して
> ますし、さすがにこのコメントは的外れでしょう

結局スクリプト言語(インタプリタ型の言語)はコンパイルしながら、実行してるから速度も遅くなるわけで、あらかじめ実行体作っておけば速くなるって発想では?

それほど的外れでもないかと。

anonymouseanonymouse 2010/04/30 13:32 後半については私の勘違いで。

で前半は,
「雨が降れば,傘を差す」
というような仮定の文に
「それって雨が降ることが前提のコメントですよね,その根拠は?」
って返し方はおかしくね?というつもりでした。

berobero 2010/04/30 21:45 >>インタプリタかコンパイルかで速度が極端にかわるようなら、単純にPerl,PHP,Ruby,Python等で静的コンパイルできるようにするんじゃないかなぁ〜?
に対し
>インタプリタ型言語も内部的にはコンパイルしてから実行してますし、さすがにこのコメントは的外れでしょう。
と返してますが

HipHop for PHP
http://journal.mycom.co.jp/news/2010/02/08/028/index.html
http://www.sssg.org/blogs/naoya/archives/1689
PHP->C++コード変換->静的コンパイルでFacebookのCPU負荷を30-50%以下にしたそうな

静的コンパイルでなく動的コンパイル(JIT)ならもっとありますね

kwatchkwatch 2010/05/01 10:48 anonymousさん:
> 結局スクリプト言語(インタプリタ型の言語)はコンパイルしながら、実行してるから速度も遅くなるわけで、あらかじめ実行体作っておけば速くなるって発想では?
> それほど的外れでもないかと。

あーわかりました、静的コンパイルとおっしゃってるのは、事前にコンパイルしておくという意味ですね。
その意味でいうと、Pythonはすでにそうなっています。またスクリプト言語でコンパイルが必要になるのはスクリプトを読み込んだときだけです。そのため、毎回スクリプト言語を読み込む必要のある CGI ではおっしゃるとおりですが、mod_xxx とかを使ってアプリケーションサーバをたてている場合は、スクリプトは最初に一度だけ読み込めばいいので、ご心配されていることは杞憂です。

> で前半は,
> 「雨が降れば,傘を差す」
> というような仮定の文に
> 「それって雨が降ることが前提のコメントですよね,その根拠は?」
> って返し方はおかしくね?というつもりでした。

もとの文章はこれですかね。

>> よく知りませんがスクリプト言語の作成効率が高ければ、そんなにトランザクションがおきないところは安く構築するために有効だと思われるので、そんな劇的にシフトはしない気がする。

その前提が、根拠があいまいなものだったので、質問しました。根拠のない前提をもとに話しても、全体が意味ないので。
で、「スクリプト言語の作成効率が高ければ、...、そんな劇的にシフトはしない気がする。」は、仮定が正しいとすると、わりと合っていると思います。なにせ世の中はまだCOBOLのコードがたくさん残っているくらいなので、言語のシフトというのはそうそう起きないのかなと思います。


beroさん:
こちらは「静的コンパイル」をanonymousさんとは違う意味で使ってますね。HipHopは「静的コンパイル」じゃなくて「静的な言語に変換してからコンパイル」ですよね。それなら的外れでもなんでもないです。

> 静的コンパイルでなく動的コンパイル(JIT)ならもっとありますね

JITを動的コンパイルっていうんでしたっけ。JITは動的コンパイルの一種ということでしょうか。

2010-04-28

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

| 09:10 |  『使いやすいのは動的な言語だから』というのは間違い - kなんとかの日記 を含むブックマーク

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

mikihoshi 「スクリプト言語の使いやすさ」のかなりの部分はスクリプト言語(動的言語)であることが担保してるんだから、「スクリプト言語並みに使いやすい静的な言語」って命題が無理筋ではなかろうか 2010/04/27

はてなブックマーク - スクリプト言語の息の根を止めるのは案外 SSD かもな - kwatchの日記

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

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

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

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


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

ブーッ!!!

1.9 が高速化したのは、SaSaDa 投入によって Rubyボトルネックが解消されたからだったのか!

(な、なんだってー!)


追記:あわせて読みたい

もぐもぐ 2010/04/29 10:50 その手の大手さんは書き直し・高速化のためにコストをさく余裕があるイメージ。
Py->CとかGoogleでやってるとか聞いた気がする。