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

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 もアーキテクチャを改良する余地は多いにある。


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


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

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

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

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

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

これは強く同意。

2010-04-25

国内レンタルサーバでの PHP/Ruby/Python/Perl/MySQL/PostgreSQL のバージョンを調べてみた

| 15:30 |  国内レンタルサーバでの PHP/Ruby/Python/Perl/MySQL/PostgreSQL のバージョンを調べてみた - kなんとかの日記 を含むブックマーク

国内レンタルサーバで使われている PHP/Ruby/Python/Perl/MySQL/PostgreSQL のバージョンを調べてみた。レンタルサーバの選択基準は特にない。「レンタルサーバ」でぐぐって適当にピックアップした。

最初にまとめとくと:

  • PHP は 5.2.x が主力
  • Ruby は 1.8.2 が十分現役、1.8.7 が使えるとこなんてごくわずか少しずつ増えてる?
  • Python は 2.3 や 2.4 がまだ現役、2.6 は見つけられずまだまだ少数
  • Perl は 5.8.8 が主力、5.10 はなし (livedoor ですらそう)
  • MySQL は 5 系が主力だが、5.1 が主力とまでは言えず
  • PostgreSQL は使えるところ自体が少数

なおこの情報は 2010 年 4 月現在であることに注意。

(追記: さくらインターネットphp 5.2.x と ruby 1.8.7python 2.6.2 と perl 5.8.x を追加。情報提供あざーっす!)

ロリポップ

http://lolipop.jp/manual/hp/cgi/ から:

Ruby がちょっと古め。

さくらインターネット

http://www.sakura.ne.jp/function/matrix.html から:

  • PHP: ver4 と ver5 が選択可能、それ以外の詳細は記載なし 5.2.x
  • Ruby: 利用可能だがバージョンの記載なし 1.8.7
  • Python: 利用可能だがバージョンの記載なし 2.6.2
  • Perl: 5.8 5.8.x
  • MySQL: 4.0 or 5.1
  • PostgreSQL: 利用不可

情報不足。技術者はあまり使わないのかな。情報提供ありがとうございました

xrea.com

http://www.value-domain.com/xreaip.php?action=all より:

  • PHP: 4.4.8, 5.1.4, 5.2.5
  • Ruby: 1.8.5
  • Python: 2.3, 2.3.4, 2.4.3
  • Perl: 5.6.1, 5.8.3, 5.8.4, 5.8.7, 5.8.8,
  • MySQL: 3.23.58, 4.0.26, 4.1.7, 5.0.22, 5.1.11, 5.1.17, 5.1.19, 5.1.20, 5.1.22
  • PostgreSQL: 7.4.14, 7.4.17, 8.1.3, 8.1.4, 8.2.4

カオスすぎるやろ。そのくせ Ruby だけ 1.8.5 に統一されとる。

livedoor レンタルサーバ

http://flexserver.jp/start/functionlist.html より:

livedoor でさえこんな古いバージョンを使ってるのか。

Perl の会社なんだからせめて Perl だけでも 5.10 系にすればいいのに。

FC2 レンタルサーバ

#ここも情報不足。

ハッスルサーバ

http://www.hustle.ne.jp/service.html より:

  • PHP: 5.2.x
  • Ruby: 利用可能だがバージョン情報なし
  • Python: 利用可能だがバージョン情報なし
  • Perl: 5.8.x
  • MySQL: 5.0.x
  • PostgreSQL: 利用不可

#月額208円から使えるらしいんだけど、RubyPython のバージョンが不明。

チカッパレンタルサーバ

http://user.chicappa.jp/?mode=support&state=manual&state2=cgi_set より

Ruby 1.8.7 が利用可能とな。すばらしい。そのくせ DB のバージョンは書いてない。

kmachukmachu 2010/04/25 15:46 5年ほど契約しているさくらインターネット(さくらのレンタルサーバ)の情報です。さくらは定期的にバージョンアップしていますね。

%uname -a
FreeBSD www236.sakura.ne.jp 7.1-RELEASE-p9 FreeBSD 7.1-RELEASE-p9 #0: Mon Jan 4 18:07:13 JST 2010 root@www236sub.sakura.ne.jp:/usr/obj/usr/src/sys/SAKURA11S i386

%/usr/local/bin/python -V
Python 2.6.2

%/usr/local/bin/ruby -v
ruby 1.8.7 (2009-04-08 patchlevel 160) [i386-freebsd7]

o_showo_show 2010/04/25 16:35 さくらインターネットですが、オンラインマニュアルの方に
もう少し詳しい記述がありました。

http://support.sakura.ad.jp/support/manual/rs/tech_server.shtml

Perl:5.8.x
Ruby:1.8.x
Python:2.6.x
PHP:5.2.x

だそうです。

berobero 2010/04/26 21:33 使ってるであろうディストリでバイナリがメンテされてるバージョンと、独自管理してるであろう部分を分けて考えるといいかと。

例えばRedHat Enterprise Linux5.4(とCentOS互換ディストリ)
php 5.1.6
perl 5.8.8
python 2.4.3
ruby 1.8.5
mysql 5.0.77 *)
postgresql 8.1.18 *)
*)ディストリのマイナーバージョンで変わってる

phpに関しては
mysql_set_charset (PHP 5 >= 5.2.3)
がないと日本語等の扱いでセキュリティ上問題あることが発覚してコレ以降のバージョンを要求するアプリが増えてきたので、
それらのアプリを入れたい顧客の要望に応じて自前管理、
rubyはデフォルトで放置、てかんじではないかと

distrowatchにディストリ毎のバージョン情報があるけど
http://distrowatch.com/table.php?distribution=suse
http://distrowatch.com/table.php?distribution=freebsd
rubyやpostgresqlは載ってない

あと、webページを書いた時点と、ベースディストリの更新で多少のバージョン違いが起きているかもしれません。
livedoorとかすごくCentOSっぽい

2009-09-14

練習不足でしたごめんなさい in YAPC::ASIA2009

| 01:30 |  練習不足でしたごめんなさい in YAPC::ASIA2009 - kなんとかの日記 を含むブックマーク

先日、YAPC::ASIA2009で「Basic Mechanism of OOPL」というタイトルで発表させていただきました。場を提供してくれた事務局の皆様、ありがとうございました。それから聞きにきていただいた方、ありがとうございました&ごめんなさい。完全に練習不足でした。ほんとすみません。

実はYAPC::ASIAまでにpyKookをPerlに移植しようと思っていて、練習そっちのけで発表当日の朝まで作業してました。また資料自体はよく書けた(つもりになってた)し、内容も良く知っている(つもりの)ことだったから、大丈夫だろうとタカをくくってたら・・・ボロボロでしたね。今までで一番まずい発表でした。申し訳ありません。

しかも発表内容で間違いがありました。

  • Perlの '@ISA' 変数は名前がおかしいのではないか、なぜならis-a関係はインスタンスとクラスの関係を表すものであり、クラス間の関係を表すものではないから」という趣旨のことをしゃべりましたが、クラスの継承関係のこともis-a関係というそうなので、これはこちらの間違いでした(object.is_a?(Klass) に慣れてると Klass.is_a?(Klass2) はおかしいように思うんだけど、そうではないらしい)。
  • 最後のスライドでJavaScriptの説明をしたのですが、内容が間違っていました。「.__proto__」がコンストラクタをさすという説明をしてましたが、正しくはコンストラクタの「.prototype」を指します。

どちらもアップロードした資料のほうでは加筆修正削除しておきましたので、気になる方はご覧になってください。

#でもビデオは残るんだよなー。あー恥ずかし。


YAPC::ASIA2009の感想をちょっとだけ:海外から参加された方と何人かお話ししたんだけど、そのうち結構な数の人が日本語でしゃべってて、すごいあせった。日本語は学習コストが相当高いように思うんだけど、すごいよね。日本語のできる外国人にお会いすると、いつも「英語ができなくてごめんなさい」と思ってしまう。英語がんばらんといかんわ、ほんとに。


あーそれから、視聴率のほうですが・・・たぶん1%を切ってた。視聴者は両手の指で足りるぐらいだったので。視聴率とれる番組が作れるよう精進します。

2009-09-09

裏番組が強すぎる リターンズ

| 00:48 |  裏番組が強すぎる リターンズ - kなんとかの日記 を含むブックマーク

さっき気づいた。前もそうだったけど、今回も裏番組が強力すぎる。またですよ奥さん。


f:id:kwatch:20090910004220p:image


参考: http://conferences.yapcasia.org/ya2009/schedule?day=2009-09-11

2009-02-20

ライブラリの更新頻度で言語を批判するとは新しい視点だ

| 23:09 |  ライブラリの更新頻度で言語を批判するとは新しい視点だ - kなんとかの日記 を含むブックマーク

Java系プログラマ』さんだそうです。これだからJava屋さんは(ry

そこで気がつくのですが、

あれ....CPAN ライブラリのバージョン更新があまり進んでない.....

ということなんですね。たとえば、用途から考えて、現役でちゃんとメンテされているに決まっている XML::RSS あたりを基準に考えると、

2009年:2、2008年:8、2007年:1、2006年:4

というくらいの更新があります(要するについさっきも更新があった、くらいの頻度)。それに対して、XML:RSS が要求する XMLパッケージの基盤ライブラリである XML::Parser で、最終更新が 2007年11月ですし、SHA アルゴリズムを使うメッセージダイジェスタ実装の Digest::SHA だと、

2008年:2、2007年:1、2006年:8、2005年:4

と、2006年くらいにピークがある、という格好になっています。

no title

べつにいいんじゃね? SHA なんてアルゴリズムの仕様は明確で安定しているんだから、そのライブラリも安定しているだけじゃん。なんか問題でもあんの?


さすがにもう Perl という言語は古くなってきています。

これは同意するけど、その理由として Digest::SHA1 の更新頻度を挙げるのはまさにバカだろう。


1. 言語仕様が汚い。厳格にはサブルーチンの「引数」という概念がないし、変数はすべてグローバルで特に宣言した場合だけローカルになる...というあたりの仕様は、そりゃインタプリタの実装は楽チンだろうけども、美意識(とミスしにくさ)には欠けるよね。

2. 後付けのオブジェクト指向。何かヘンテコなやり方です...神の祝福が要る(bless)わけですが、「神の祝福」って何だろ?

3. 5.8(2002年) でマルチエンコーディングに(実質上Unicodeに)ようやく対応。これはタイミング的にはちょっと遅れを取った感が否定できなかったです....

1. はなんであんな仕様になったんだろうね。まったく理解できない。

2. は、まあしょうがないわな。いけてないのは事実だけど、あとづけの仕様としては頑張ってると思う。

3. はよくしらんので保留。それよりまともな例外処理をいれてほしい。


そりゃ Perl6、という話もないわけではないのですが、これだけCGI(そりゃMovableTypeだって...)が書かれちゃうと、下手すれば

Perl6 は登場(そりゃ現在でも Haskell で実装された Pugs はありますが...)しても全然普及せずに、Perl5 だけ「レガシー資産」扱いで細々とメンテされる

状態になる可能性も否定しきれないようにも感じます(そりゃCOBOLやFORTRANだってまだ現役言語には違いない!)。

『そりゃ』が大好きみたいですね。

絶対可憐チルドレン 画像絶対可憐チルドレン 画像 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/