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

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-28

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

| 09:10 |  Facebook はなぜ HipHop を開発したかを考える - kなんとかの日記 を含むブックマーク

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

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

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

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

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

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

それから、

mujin script スクリプトの実行速度は問題になるほど遅くないし、問題になってもPHPならHipHopのような解決もある。開発、メンテコストも考えてよね。けっきょく同じこと言ってる。要するにタイトルで釣るなと。 2010/04/27

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

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

 ・

 ・

 ・

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

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

2009-11-13

グーグル、C/C++に代わる新言語「Go」をOSSで公開

| 23:33 |  グーグル、C/C++に代わる新言語「Go」をOSSで公開 - kなんとかの日記 を含むブックマーク

Google が新しい言語を発表。Noop涙目。

Goはグーグルの社員7人が「20%の自由時間」を利用して開発した。設計・実装を行っているのが分散OSPlan 9」の創案者であるロブ・パイク氏や、Unix、Cの生みの親、ケン・トンプソン氏、Google ChromeV8エンジンを開発したロバート・グリースナー氏など錚々(そうそう)たるメンバーで、こうした点でも注目を集めそうだ。

グーグル、C/C++に代わる新言語「Go」をOSSで公開 − @IT

言語仕様も興味深いけど、開発者の顔ぶれがすごい。彼らは今Googleにいたのか。大学の教授にでもなっているんだと思ってた。

 Goは軽量な型システムを備えた静的型付け言語という。型の暗黙変換はない。近年、静的型付け言語で記述が冗長になりがちなことなどから、動的型付け言語の人気が高まっているが、それは多くの静的型付けの実装が悪かったからだ、とパイク氏は指摘する。

まったくだ。「静的言語である」ことと「簡潔で使いやすい」ことは両立することに気づいてないやつが多すぎる。静的であることを、使いにくさの言い訳にするな。

 Goには“インターフェイス”と名付けられた仕組みがあり、パイク氏自身は「おそらくGoの中で、もっとも斬新なアイデア」だとしている。Goのインターフェイスは、C++でいえば、純粋仮想関数に似ているという。データメンバがなく、すべての関数が仮想関数であるようなクラスだ。Goでは、あるインターフェイスが定義するメソッドをすべて実装した型は、そのインターフェイスを実装しているものと見なされる。こうして個々のメソッドという実装をクラスという概念でまとめるよりも、より柔軟な型とメソッドの対応付けが可能になるのだという。

これはJavainterfaceのように実装の共有はしないのか、それともRubyのmoduleのように実装の共有も可能なのか。『もっとも斬新なアイデア』というからには、後者じゃないと困る。

 Goで注目すべきなのは、並列処理を念頭に設計されていることだ。Goではmutexやロックといった機構のほかに、抽象度の高い“ゴールーチン”(Goroutines)や“チャンネル”(Channels)といった仕組みを備えている。

それもいいんだけど、数量型とかDecimalのサポートとかはないんだろうなあ。なんかニュースを見る限りは、お金を扱うようなアプリケーション向けの機能は特になさそう。「0.05」を10進数で扱ってくれる言語ってやっぱりCOBOLぐらいなんだろうか。


・・・


FAQをちら見した。


例外がない言語かよ。まじっすか。萎えるなあ。

あのいあのい 2009/11/14 02:09 以下の記事を元にしたただのネタですよ... たぶんね。
http://okwave.jp/qa5419623.html

あのいあのい 2009/11/14 02:13 すみません。見当違いでしたね。削除願います。

PerlerPerler 2009/11/14 05:10 > 自分がろくに知らん言語をよくもまあ批判できるもんだわ。

いや、全く。本日のおまえが言うなブログ記事ですね!
Perlのこと知らないでとばっちりで例外機構もないとか間違えたこと書かれてホントいい迷惑です。

undefundef 2009/11/14 19:19 > Perler
例外処理が出来るのと、例外処理機構が在るってのは別。

Perlのことを知らないでとばっちりで例外機構があるとか間違えたこと書かれてホントいい迷惑です。

PerlerPerler 2009/11/15 22:09 > undef

http://d.hatena.ne.jp/perlcodesample/20091120/1246679588

PerlerPerler 2009/11/15 22:33 > undef
evalは立派な例外処理機構ですがなにをもって例外処理機構ではないと
おっしゃってるのでしょうか?
C++やJavaに習ってtry〜catchじゃないと気にくわないってだけですか?

kwatchkwatch 2009/11/16 07:15 > evalは立派な例外処理機構です

え〜、eval はあくまで動的にコードを実行する機能であって、例外処理機構じゃないよ。
例えるなら、
・Javaのinterfaceは多重継承のかわりにつかえるかもしれないけど、多重継承ではない
・Javaの匿名クラスはクロージャ代わりに使えるかもしれないけど、やっぱりクロージャではない
・Rubyの「func(:arg=>value)」はキーワード引数のかわりに使えるかもしれないけど、本物のキーワード引数じゃない

キミはundef氏の『例外処理が出来るのと、例外処理機構が在るってのは別。』という言葉をもっと噛み締めるといいと思うよ。

PerlerPerler 2009/11/16 11:08 > kwatch
> え〜、eval はあくまで動的にコードを実行する機能

kwatchさんがおっしゃっている「コードを動的に実行する」というのは
eval EXPR
です。
私が言っているのは
eval BLOCK
です。
全く意味は違います。
マニュアル読んでれば「eval はあくまで動的にコードを実行する機能」なんてとんでもなことはいわないはずです。

知らないことをさも知ってるような振りして語ってるのはよく分かりましたから、さっさと訂正してPerlのことを語るのをやめて頂けませんか?

rubyistrubyist 2009/11/16 11:41 http://web.sfc.keio.ac.jp/~hattori/prog-theory/main_c10_s2.html

ランタイムエラーを検出して例外処理をする為の機能を言語が備えてるんだから例外処理機構を備えていると言えると思うよ。
備えてなきゃランタイムエラーの時点で処理を中断か、例外処理が起こりえる条件をあらかじめ想定して例外処理(not 例外処理機構)を事前にしなきゃいけなくなるからね。

undefさんやkwatchさんの言う例外処理機構ってのがいったいどんなものなんなのか僕も分かりません。
是非解説をお願いします m( _ _ )m

kwatchkwatch 2009/11/17 02:15 perlerさん:

> 全く意味は違います。

え、一緒じゃないの?どちらもコードを動的に実行する点では同じで、単に引数が文字列かクロージャかの違いだけでしょ?
ワシ、勘違いしてたのかな。

 ## これって、
 eval { print "in closure\n"; };

 ## これと一緒だよね? 違う?
 my $block = sub { print "in closure\n"; };
 eval &$block;

> マニュアル読んでれば「eval はあくまで動的にコードを実行する機能」なんてとんでもなことはいわないはずです。

http://perldoc.perl.org/functions/eval.html だと

In the second form, the code within the BLOCK is parsed only once--at
the same time the code surrounding the eval itself was parsed--and
*executed* within the context of the current Perl program. This form is
typically used to trap exceptions more efficiently than the first (see
below), while also providing the benefit of checking the code within
BLOCK at compile time.

ってあるから、動的にコードを実行する機能であってると思うけど?

ところで、これって理解できました?
> ・Javaのinterfaceは多重継承のかわりにつかえるかもしれないけど、多重継承ではない
> ・Javaの匿名クラスはクロージャ代わりに使えるかもしれないけど、やっぱりクロージャではない
> ・Rubyの「func(:arg=>value)」はキーワード引数のかわりに使えるかもしれないけど、本物のキーワード引数じゃない

これらの例えが理解できれば、「例外処理ができる」ことと「例外処理機構を備えている」ことは別物だとわかると思うんですけど、どうでしょうか。

kwatchkwatch 2009/11/17 02:33 rubyistさん:

> ランタイムエラーを検出して例外処理をする為の機能を言語が備えてるんだから例外処理機構を備えていると言えると思うよ。

それは「signal trapができるから例外処理機能を備えていると言える」「setjump/longjumpがあるから例外処理を備えていると言える」と同じようなもんだと思うよ。
あるいはrubyの「func(arg:123) 」をキーワード引数と言い張るようなもの。
いちいち if ($@) ... と書かないといけない (書かない場合は見捨てられる) ようなのを例外処理機構と言えるのか疑問。せめてスタックは自動的に遡って欲しいよね。
#毎回 if ($@) と書くのは、毎回関数の戻り値を調べるのと似てるよね。


Wikipediaを見ると、Schemeの例が載ってた。

http://ja.wikipedia.org/wiki/%E4%BE%8B%E5%A4%96%E5%87%A6%E7%90%86
> Scheme では言語レベルでの例外処理を持たないが、これは継続が
> 存在するため例外をライブラリレベルで実現できるからである
>(標準仕様であるSRFI-34で定義されている)。

Schemeでも例外処理はできるけど、『言語レベルでの例外処理を持たない』とある。Perlも同じことじゃないでしょうか (たとえError.pmを使ったとしても)。

kwatchkwatch 2009/11/17 02:41 まつもとさん曰く:

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-list/64
> * rubyには例外処理がある
> perlでは例外処理はevalを用いて間接的に実装する.

別の人:

http://d.hatena.ne.jp/hottolinkblog/20090923/1253709356
> ここで少し話が逸れますが、Perlでは例外処理機構がありません。
> といっても、完全にないわけではなく、evalを利用することで実現します。

世間的にはこういう認識だと思いますけど、いかがですか? > perler, rubyist

kwatchkwatch 2009/11/17 09:46 んー、ちょっと心配になったので、map のサンプルを貼ってみる。
まず、map { }, @arr の第1引数はクロージャのはず。

use strict;
use Data::Dumper;

my @arr1 = (1, 2, 3, 4);
my @arr2 = map { $_ * 2 } @arr1;
print Dumper(\@arr2); #=> $VAR1 = [2,4,6,8]

my @arr3 = (1, 2, 3, 4);
my $block = sub { $_ * 2 };
my @arr4 = map &$block, @arr3;
print Dumper(\@arr4); #=> $VAR1 = [2,4,6,8]

で、eval の第1引数もおんなじことだと思ってたんだけど。違うかな?

perlerperler 2009/11/17 10:43 try { ... throw ... } catch {...}

eval { ... die ... } if ($@) { ... }
とで、セマンティクス的な違いがあるようには見えないんだけど。

perlerperler 2009/11/17 10:44 あー、前の人の名前見ずにコメントしたけど、おいらと上の人は別人です。

文系から見て文系から見て 2009/11/19 17:08 他人を汚して自分を立てないと
自分で使用している言語の意義も唱えられない。
それが真のプログラマー。

kwatchkwatch 2009/11/21 09:47 perlerさん:
> try { ... throw ... } catch {...}
> と
> eval { ... die ... } if ($@) { ... }
> とで、セマンティクス的な違いがあるようには見えないんだけど。

んなわけねー。
try { ... }
catch(NameError ex) { ... }
catch(TypeError ex) { ... }
finally { ... }
と比べてみようよ。

・例外の種類を指定できない。catch(Exception ex) としか指定できないようなもの。言葉をかえれば、興味のある例外だけをcatchしてそれ以外は上位に伝播する仕組みがない。
・例外が発生してもしなくても終了処理を実行する仕組みがない。

こんくらいのことはすぐにわかると思うんだけど、それが分からないってことは、evalじゃない例外処理機構を備えた言語をperlerさんは使いこなしていないということでしょうね。try-catchとevalとで『違いがあるように見えない』んじゃ仕方ない。
#つうか、『catch {...}』みたいな書き方をしている時点で気づくべきでした(普通はそんな書き方しない)。

ところで、『例外処理が出来るのと、例外処理機構が在るってのは別。』という言葉は理解できました?これが理解できないなら話は噛み合ないままなので、理解できたかどうかを、YesかNoかで教えてください。

あと、これも理解できました?理解できたらYes、理解できなかればNoでお答え下さい。
> ・Javaのinterfaceは多重継承のかわりにつかえるかもしれないけど、多重継承ではない
> ・Javaの匿名クラスはクロージャ代わりに使えるかもしれないけど、やっぱりクロージャではない
> ・Rubyの「func(:arg=>value)」はキーワード引数のかわりに使えるかもしれないけど、本物のキーワード引数じゃない

kwatchkwatch 2009/11/21 09:48 文系からみてさん:
これが他人を汚しているように見えるんだったら、メガネが汚れているせいだと思うので、たまには拭いてあげてください。

kwatchkwatch 2009/11/21 10:05 ちょっと補足:

perlerさん
> セマンティクス的な違いがあるようには見えないんだけど。

今はセマンティクス的な違いがどうのこうのじゃなくて、Perlが例外処理機構を備えているかどうかの話ですよー。話をそらさないでー。
話の論点が分かってないひとは、もう一度下の言葉を読み直すといいよ。

> 例外処理が出来るのと、例外処理機構が在るってのは別。

> Schemeでも例外処理はできるけど、『言語レベルでの例外処理を持たない』とある。
> Perlも同じことじゃないでしょうか (たとえError.pmを使ったとしても)。

oskimuraoskimura 2010/06/18 19:26 >Schemeでも例外処理はできるけど、『言語レベルでの例外処理を持たない』とある。

R6RSでは例外が定義されています
http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-8.html#node_chap_7

名無し名無し 2016/03/22 20:20 おれおまえきらい。
これからずっと読んでいくね
おまえのこと

2009-02-21

TraceMonkey とか V8 とか SquirrelFish とか、速さも大事だけどさ…

| 01:55 |  TraceMonkey とか V8 とか SquirrelFish とか、速さも大事だけどさ… - kなんとかの日記 を含むブックマーク

Mozilla が開発中の次世代 JS エンジンについてのプレゼン資料 (via オレンジニュース)。たいへんよくまとまっている。書いた人グッジョブです。


TraceMonkey に限らず、Google ChromeV8 とか Safari (WebKit) の SquirrelFish とか、なんか JavaScript 用の VM が盛り上がってるんですけど、速さばっかりが話題になっていて、メモリ消費量はあんまり話題になってないっすね。

たしかに、Web ブラウザはアプリケーションのプラットフォームとしてだけでなく、ゲームのプラットフォームにもなるだろうから、JavaScript のパフォーマンスが大事なのはその通りなんですけど、もっとメモリ消費量を減らすことも頑張って欲しいんですけど、無理ですかね。

Safari が仮想メモリ 4 GB 弱、実メモリ 1.5 GB 弱使ってたりとかすると、ほんとゲンナリする。実際にはかなりの部分は rendering engine が消費してるんだろうけど、Tracing とか使うと JS エンジンも結構な量を消費しそうで、いやだ。


あと、動的言語で『最終速度は C や Java に匹敵する処理速度』(スライド 6 枚目) を追求するのって、なんか努力する方向が間違っているように思うのはワシだけだろうか。そんなことするくらいなら、動的言語より使いやすい静的言語を作るとか、動的言語なんだけど部分的に型指定できるようにするとか、そういうアプローチのほうが自然で無理がないと思う (JavaScript2.0 が ECMAScript 4 ベースでなくなったのは残念だ)。まあいったん広まってしまった言語はおいそれと言語仕様を変更できないから仕方ないだろうけど。


アセンブラを吐くためのライブラリ

| 01:55 |  アセンブラを吐くためのライブラリ - kなんとかの日記 を含むブックマーク

ところで JIT を使うのが一般的になると、アセンブラを吐くためのライブラリが重要になるはず。ちょうど Java では bytecode manipulator (generator) として Javassist とか ASM があるけど、アセンブラ用のはあんまり聞かない。探してみたけど、あんまりなさそう。


それに比べると Java byte code 用は豊富。参考までに、Java バイトコード用ライブラリの一覧。たくさんあるね。

ささだささだ 2009/02/21 12:04 添削するのは誰がいいですかね.

rubikitchrubikitch 2009/02/21 13:41 英語ですがJay Fields氏のブログはどうでしょうか?
http://blog.jayfields.com/2008/06/developer-testing-and-importance-of.html などテストについて鋭い洞察があります。

ku-ma-meku-ma-me 2009/02/21 21:50 Ruby 自体のテストコードを添削してほしいです><

c-yanc-yan 2009/02/22 21:37 > 動的言語なんだけど部分的に型指定できるようにするとか、そういうアプローチのほうが自然で無理がないと思う
全く持って同感です. Common Lisp という成功例があるのに、なんでなのでしょうね.

2009-02-20

Lispのパワーユーザーは世界で100人

| 08:47 |  Lispのパワーユーザーは世界で100人 - kなんとかの日記 を含むブックマーク

小飼氏は「LispがJavaScriptたりえないのはコミュニティが存在しないせい。世界レベルでも100人くらいしかパワーユーザがいない」と,コミュニティとテクノロジーの発展との関係を指摘します。

Web開発者の未来は明るいか?─「Webデベロッパの祭典@東京」開催:レポート|gihyo.jp … 技術評論社

いくらなんでもこれは失礼だろ。Tongue slip だろうけど。

絶対可憐チルドレン 画像絶対可憐チルドレン 画像 2010/03/23 15:21
携帯で無料&簡単に画像が読み放題です!
会員登録もありません!
FAIRYTAIL?エアギア?あねどきっの人気マンガ作品も充実!!
一度遊びに来て下さい!!
詳細はこちらになります▽

絶対可憐チルドレン 画像
http://comic.fansfree.com/sunday/children/

NARUTO-ナルト- 画像
http://comic.fansfree.com/jump/naruto/

ToLOVEる-とらぶる- 画像
http://comic.fansfree.com/jump/toloveru/

PSYREN(サイレン) 画像
http://comic.fansfree.com/jump/sairen/