その爆速っぷりで巷を震撼させた「Google Chrome」のJavaScript Engine「v8」。その「v8」をなんとサーバサイドに実装させてしまう「v8cgi」に挑戦。

まず、システム要件は、

• Linux (Intel or ARM-based).
• Windows XP SP2 or later, or Windows Vista.
• Mac OS X 10.5 (Leopard).

とのことだが、今回はFedora12 32bit版で挑戦する。
以下はそれを前提に進める。

「v8」及び「v8cgi」をビルドするためのツールを準備する。

• Subversion 1.4以上
• Python 2.4以上
• SCons 1.0.0以上

幸いこの辺のツールは、Fedoraでrpmが準備されているので、入ってないものだけ、yumでサクッとかたづける。

# yum install subversion
# yum install python
# yum install scons


他にもコンパイラとして、

• Linux、MacOSXの場合、GCC 4.x.x
• Windowsの場合、Visual Studio 2005、Visual Studio 2008、またはVisual C++ 2008 Express Edition

「v8cgi」には「v8」も同梱されているので、一緒にダウンロードできる。
今回も/usr/local/srcで展開する。

# cd /usr/local/src
# mkdir v8
# cd v8
# wget http://v8cgi.googlecode.com/files/v8cgi-0.8.0-src.tar.gz
# tar xzvf v8cgi-0.8.0-src.tar.gz

では早速「v8」をビルド。
したいところだが、そこはすんなり行ってくれない。いきなり環境変数の設定などでハマる。
そこで、おまじないしてからビルドする。

# cd v8cgi-0.8.0-src
# export GCC_VERSION=44
# vi SConstruct
（GCC_EXTRA_CCFLAGS = ['-fno-tree-vrp']
を
GCC_EXTRA_CCFLAGS = ['-fno-tree-vrp', '-fno-strict-aliasing']
に書き換える）
# scons library=shared
（「libv8.so」ができてるはず）
# cp libv8.so /usr/lib

これで「v8」のshared libraryはOK。
次に「v8cgi」をビルド。
ところがここでもいろいろ失敗。mysqlとsqliteがうまくいかない。
今回は動かすとこまでが目的なので、あとの宿題としておく。
あと、いろいろ便利なライブラリは、/opt/v8cgi/libに準備する。

# cd ../v8cgi
# scons reuse_context=1 mysql=0 sqlite=0 apache_path=/usr/include/httpd apr_path=/usr/include/apr-1
（mod_v8cgi.soとv8cgiができてるはず）
# cp mod_v8cgi.so /etc/httpd/modules/mod_v8cgi.so
# cp v8cgi.conf.posix /etc/v8cgi.conf
# mkdir /opt/v8cgi
# cp -r lib /opt/v8cgi
# vi /etc/v8cgi.conf
（require.paths.push("/opt/v8cgi/lib")にする。）


次にApacheの設定。あーめんどくさい。

httpd.confに
LoadModule v8cgi_module modules/mod_v8cgi.so
AddHandler v8cgi-script .sjs .jst
を追加。

これでApacheを再起動すれば、拡張子「.sjs」と「.jst」でサーバサイドでv8を利用したJavaScriptエンジンが利用できる。

「v8cgi」を展開したディレクトリのexample/htdocsにサンプルがあるので、
適当に突っ込んで動かそうとすると動かない。ちなみにindex.sjsの中身は、

printbr('Server-side JS with mod_v8cgi in action!');

printbr('<a href="test.jst">See Jst template based pages in action</a>');
printbr('<a href="testjst.sjs">See Jst templates in pages in action</a>');
printbr('<a href="errortest.sjs">See compilation error page</a>');<br />printbr('<a href="errortest2.sjs">See runtime error page</a>');

こんな感じ、「printbrが未定義だ」みたいなエラーで怒られる。
1行目に

require('requestHandler');

をぶっこめば動く。「#!」ではじまるシェバングなどは不要。testjst.sjsも同様。
ただ、公式のwikiによると、requestHandlerは近い将来に削除されるらしく、「response.write()」の利用が推奨されている。

また、test.jstという<% ～ %>でJavascriptが埋め込まれたPHPライクなサンプルもあるが、それは動かない。
これまた公式のwikiで質問があがっていたが、回答は、

「v8cgiはPHPじゃねぇ。response.write()とJSTモジュール使え。」とのこと。

え？逆ギレっすか？
testjst.sjsとtest.tplで同様の事はできるけど…。
サンプルやらhttpd.confの設定の中にあるってことは、古い仕様なのか将来実装されるのか、それはわからない。

で、さっそく以前の「フィボナッチでベンチマーク 」と同じロジックを動かしてみたが、4秒程度で完了。

うをおおおおお！爆速！！！

参考サイト
Google Code : v8cgi
Google Code : v8

v8 サーバサイド Javascript v8cgi

前回に引き続き今回はWEBサイトのサーバサイドで実行されるプログラム言語でのベンチマークをおこなってみた。

PCスペック、アルゴリズムは前回の「フィボナッチ数でベンチマーク（JavaScript） 」と同じである。

「C最速」はやっぱりお約束。でもコンパイルオプションを指定しないと、Javaより遅かった。やはりJITのJavaは勝手に最適化してくれてるんだなぁ…。

Javaはもっともっさりしてる印象があったんだけど、思ったより速かった。重いのはGUIか？

Pascal系代表としてFreePascalを選んでみたのだが、「最適化がクソ」という評判どおり、中間コード形式のJavaよりもおそかった。あとランタイムもくっつけてるせいかコンパイラ系言語でいちばんファイルサイズが大きかった。

Smalltalk代表は、GNU-Smalltalk。さすがというかなんというか、インタプリタの中では抜きん出てはやい。Google ChromeのJavaScriptエンジンもSmalltalk系の言語（Strongtalk?）で作られているらしい。

Rubyは1.9になって恐ろしい程の性能向上。PHP3→4のインパクトを超えた。小数点以下のマイナーアップグレードでいいんだろか…

Pikeは日本ではマイナーだが、世界でもマイナー？でも地味にメンテナンスされている。今回のダークホース。

海外では人気のLua。その人気に恥じない速度を出してくれた。C言語との相性も良く、最近では日本のゲームなどにも使われている。

統計解析専門用語代表としてS言語で書いてみたのだが、その割にはいまいちパッとしない。残念。
RはSのサブセットらしいので、もしかしたらRの方が速いかもしれない。こんど試してみよっと。

PHP、Python、Perlはもう大体ゲバ評どおりの結果。
いや別にどれも嫌いじゃないんだけどね。それぞれ個性があって。

前回のも含めると、Google Chromeなどの最新ブラウザのJavaScript速すぎ。
「超えられない壁」超えちゃってるし…。
もう、今度からロジックまで全部クライアント側のJavaScriptにしようかしらん。負荷分散になるかもしれないし…。出来ない部分だけサーバ側で。

他にも気になる言語はちょこちょこあるので、またやってみたいと思う。
関数型言語って苦手なのよん…。

ベンチマーク フィボナッチ数 プログラム言語

アクセスログを見ていると、以外とシステム絡みのキーワードで検索してアクセスされる方が多いみたいで、最近の脱線具合を思うと、ちと心苦しい。

てなわけで、たまには真面目な事もやってみよう。

今回は、JavaScriptでフィボナッチ数を計算してブラウザの性能を比較してみようというものだ。
数日前に「FireFoxの課題」みたいなブログを見つけて「しまった、先を越された！」と思いつつベンチ結果をまとめてみた。
フィボナッチ数列とは、まぁ、う～ん、ぐぐってちょうだい
n番目の数値とかを求めようとすると、指数関数的に再帰処理が増えていくわけだ。
だから、JavaScriptインタプリタのスタック処理とかの性能の差が如実に反映されることになる。
もっとも、再帰させずに求める方法もあるんだけど、ベンチマークだから。

実行させるプログラムは以下のとおり。40番目のフィボナッチ数を求める。
5回実行し、中間値を求める。

<script type="text/javascript">
<!--
ffunction fib(n) {
if (n < 2) {
return n;
}
return fib(n-2) + fib(n-1);
}
start = new Date();
res = fib(39);
document.write(res, ", ", new Date() - start, " msec");
// -->
</script>

PCスペックは、
CPU : Intel Core Duo T2500（2.00GHz）, Memory 2GB
数年前のDell INSPIRON 6400だ。

まずは、いきなりFedora Core 12から（だって常用なんだもん）

お次はWindowsXP SP3。しかもFedora Core 12 + VirtualBox 3.1.4 （CPU : 1個, Mem : 1GB）

いよいよ最も需要が多そうなネイティブWindows。でもXP SP3。
なんか順番間違ってるよなぁ…。
CPU、メモリのスペックは同じ。HDDを差し替えただけ。
はて？ディスクの回転数ちがったっけな？OS比較じゃないからいいか。

IE厳しいなぁ。
しかも「このページのスクリプトが、Internet Explorer の実行速度を遅くしています。スクリプトを実行し続けると、コンピュータが反応しなくなる可能性があります。スクリプトを中断しますか?」とかふざけたことぬかしやがる。
こんなやつはレジストリ変更じゃ！

HKEY_CURRENT_USER¥Software¥Microsoft¥InternetExplorerにStylesってキーを新規に作って、MaxScriptStatements というDWORD値を作る。
未設定の時は、5000000。これを900000000にする。ひでぇ。
このままだと行ったっきりになっちゃうので、ベンチが終わったらデフォルトに戻すか削除する。
今度嫌がらせでIE6も測ってみよう。

Firefoxは新鋭ブラウザに一歩遅れをとっている感じ。なんとも寂しい限りだ。
しかも新しい方が遅い…。Firefox4のTamarinに期待したい。

Google Chromeのバカっ速ぶりに感動。このベンチ以降、Chromeに乗り換えた。

Safari、Operaも現行バージョンで大きな進化をとげ、Google Chromeに迫るタイムを叩きだしている。

JavaScript engineに限って言えば、Chrome、Safari、Operaの各最新版を現世代とすると、Firefoxは一世代、IEは二世代以上遅れている感じだ。

Netscape Navigatorはシャレです。PCにたまたま入ってたので。

もっともブラウザの性能はJavaScriptだけじゃないけどね。

ベンチマーク Javascript フィボナッチ数

オリンピック広場の電子城を歩いてたら、中古のIntel P35のマザーを発見。おもいっきりノーブランドw店員は260元だという。

さんざん交渉してみたが255元から下げられないという。いったんその場を離れてネットで型番から検索してみたら、相場は新品で299~533元（なんじゃこの差は？）

まぁ、新古品っぽかったから、いいかということで思い切って購入。店頭で試しに動かしてみると…

動かない…

CPU買えたり、メモリ買えてもだめ。結局奥から新品持ってきたら起動。

もう、「これ新品持ってけ」ってことになった。
「でも、新品でしょ？」ってきいてみたけど、
「かまわん、かまわん」とのこと

本体だけしかくれなかったから、初期不良とかで卸で交換するのかな？

って、おいドライバディスクも説明書もないじゃん！！！

動かせるのかよこれ・・・。

電子城 自作PC マザーボード

ってなわけでさっそく、インストールしてみた。

PHP6で予定されていた名前空間を実装したことで、名前空間はPHP6の目玉機能ではなくなったわけだが、とにかく今回のアップデートの気合のはいり方はすごい。

けど、俺ってそんなむずかしいことやるわけではないので正直いまいちピンとこない。
遅延静的束縛機能よりも、遅延性的束縛機能が俺には欲しい。

まぁ、それでも便利そうなところは、
SQLite３がPDOでサポートされた。
今まではSQLite2が標準だったのでコマンドラインからSQLiteのファイルを操作する場合、最近のLinuxはほとんどSQlite3になっていたので、わざわざSQLite2をインストールする必要があった。
でも、PDOで接続する場合、DSNの接頭語が、"sqlite"の時はSQLite3、"sqlite2"の時はSQLite2に接続されるようになってるみたいなので、PDOを利用していた既存のコンテンツを移行する場合には注意が必要かも。
はて？PHP5.2.xでSQLiteのPDOって実装されてたっけな？

三項演算子の短縮形"?:"がサポートされた。
式 expr1 ?: expr3 と書いた場合、expr1 が TRUE と同等の場合は expr1、 それ以外の場合は expr3 となる。
これは俺多用しそう…。
三項演算子大好き男だから。

あと、NOWDOCとかは今のところ使いどころが思いつかん・・・。

インストール時に気になったのは、
php.iniのサンプルファイルが、
php.ini-distがphp.ini-developmentに、
php,ini-recommendedがphp.ini-productionに相当するものに変更されている。

あと、php.iniのサンプルはいずれもmagic_quote_gpcがOffになっているところも注意。

phpinfo()を動かしたぐらいまでしかやってないので、今はそれぐらいしかわかりませんでした。

以上！

php php5.3