風邪
風邪
昨日くらいから風邪で全然声が出なくなってしまった。まともにしゃべれない、というのは結構ツライ。思わず電話に出た時とか、話が全然通じなくて切なくなります。
昨日までは声が出ないだけであんまり具合悪くはなかったんですが、今日になって下痢＋気持ち悪さが増大中。明日お休みしようかしら…。
集中力
集中力
僕もあんまり集中力ない方で、自発的に集中状態に入れない時1って結構あるんですけど、状況によってはあえて脳味噌を停止して無理矢理集中状態に持っていかざるを得ないことがあります。
そういう時によく僕たち (僕やはかせ) が使っていた表現が「息を止めてコードを書く」。「今から息止めるから話しかけないでね」とか「ぷはーやっと息が出来るよ…」とか「とりあえず息止めて書いちゃって」という感じで使います。
僕にとっては感覚的にぴったんこな表現でした。
エイプリルフール, 「千石屋綺談」
エイプリルフール
ネタ、思いつかんかった…。直球勝負人生だからして、ジョーク考えるのって苦手なんだよね＞SAK。
今年はあんまりいいネタがない気がするなぁ。Google のフリーメールサービス、「Gmail」のメールボックス容量が 1Gbytes、というニュースに驚いてたら、SAK が「エイプリルフールじゃない？」って言ったのが一番面白かったかも。
「千石屋綺談」
「いつになく苦い話を集めてしまったシリーズです」なんて作者の言葉に少し身構えてしまったんですが、それほど苦しい話というわけでもなく、少しホッとしたり。総じてこの人のいつものお話です。
「損得勘定がないの。そういう人は幸せになれるわ。」という言葉には、ありきたりながら我が身を振り返らずにはいられませんでした。
ICO 開発者の話, redraw ポリシー, XNA の思想, PSX アップグレード第二弾
ICO 開発者の話
とても興味深かった。目指す「リアリティ」に到達できないフィーチャーはどんどん削っていく「サブトラクティング・デザイン」は、従来のソフトウェア開発現場から見るときっと目から鱗な話なんじゃないでしょうか。Unified Process を学んだ時にも、「ソフトウェアは自由度が非常に高いがゆえに、クライアントから次々湧いてくる要求をどう管理するかが非常に重要」という話があり、僕の経験上も開発期間中は主に機能を追加する方向にしか向かったことがないように思います1。
機能を削る方向へは、ソフトウェアをリリース後ある程度実働期間を経た後に、明らかに不必要な機能、冗長な機能などに対して行われることが多い気がしますが、「ICO」はたぶん、4年間という一本のゲーム開発としては長い期間の間に、何度か「擬似リリース」を繰り返し、内容を洗練させていったのではないかと想像します。
思い出してみると、ねおんさんはこの「サブトラクティング・デザイン」を結構意識されてたんじゃないかと思ったりして…。
他にも、節目節目でデモ・ムービーを製作し、自分達の目指す方向性を関係者に対して誤解のないよう継続的に示し続けた話などは、ゲームに限らずソフトウェア開発一般の話として、とても大事だと思いました。僕も今業務時間のほとんどを意識合わせのための資料作りに費やしていますが、「目指している方向性を継続的に資料化して関係者に示す」ことの重要性を日々実感している毎日です。
ところで、同じ GAME Watch のこちらの桜井氏の意見は、僕としてはイマイチ。クレヨンしんちゃんじゃないけど、「そーともゆー」って感じ(ワケワカ。
redraw ポリシー
僕は普段、KDE 環境で生活しているんですが、KDE/QT 環境の redraw ポリシーって微妙にダサい。ふとした拍子にチラチラとフリッカーが見られます。個人的に、そのことがなんとなーく信用できない感じに繋がっているような気も。Konqueror は Explorer と (File Viewer として) ほとんど変わらない機能を持っているんですが、どうも積極的に使う気にならないのはその辺に理由があるような…。
XNA の思想
あははははは。ねおんさんからのこのツッコミ、
XNAの彼は、ビジネスというものについてはイマイチなので、そのあたりの発言は許して上げるようにw
ねおんさんのつっこみより引用
は、個人的にとてもツボでした。まさにその点を突っ込もうかと思っていたので。
さて気を取り直して。僕もこの記事をとても興味深く読みました。この記事を読んで僕が思ったことは二つ。一つはねおんさんも指摘されているビジネス的な面、そしてもう一つは、やっぱり Microsoft はソフトウェアの会社であるのだなぁ、ということ。
この記事を読むと、Microsoft は、3/27 の僕の意見で言うところの「モデル規定者」の立場を明確に指向しているように見えます。現状、XNA について語られる言葉では、必要以上に「開発環境」というものが強調されているように僕は感じますが、その裏には「プログラミングモデル」自体を構築していこう、というソフト屋の意図がありありとうかがえます。
実は XNA の考え方は、Allard さんが Win32 API との対比を行っていることからも分かるように、Microsoft が昔から行ってきたことでもあるんですよね。かつて Microsoft は、Windows API (GDI やドライバモデル) を規定した上で、オープンな土俵でハードウェアベンダーに競争させることで、より最適化されたハードウェアの発展をドライブし、また DirectX によって同様に 3D グラフィックスハードウェアの発展をドライブしてきました。もちろん、彼らはそれぞれと並行して (それら下位レイヤーからのフィードバックを受けて) モデル自体のブラッシュアップも精力的に行ってきました。この手の物事の進め方についてはお手の物なのでしょうね。
さて、XNA のスコープにおける直接のライバル、SCEI の場合はどうか、というと、実はそういう「モデル発展のフィードバック」を作ることがすごく下手なんじゃないかと思うんですよね。PS の時は SGI という先行者がいたために、プログラミングモデル的には単にそれをなぞればよく、成功の要因は主にタイミングと思い切りのいいハードウェア設計、それに流通改革にありました。PS2 の時も基本的な方向性は PS のころと変えずに単にそれをスケールアップしただけで、PS2 ならではの新しい方向性の提案 (eDRAM による超広帯域 framebuffer とか、VU とか、ある種特異なメモリモデルとか) も、結果的に見るとどうもあさっての方向を向いていたようです。外し具合がたまたま致命的なものではなかったためになんとか成功している、という状況でしょう。
僕が気になるのは、Microsoft が PC の世界というオープンな環境で自らのモデルを提案し、日々ブラッシュアップしていっているのに対し、SCEI はそうしていないように見える点です。そのことは、基本的にオープンな DirectX ベースのプログラミングモデルが載せられることがはっきりしている Xbox2 と、IBM と共に完全な密室で作成していてどんなものになるのか見当もつかない次世代 PS (Cell マシン) の違いを見ても強く感じます。
プログラミングモデル、なんていうものは、「いかに多くの人に理解してもらい、使ってもらえるか」が勝負なわけで、開かれた環境で広く議論され、叩かれた方が良いものが出来ることは明らかだと思うんですが、SCEI にはそういった議論を起こそうという方向性は見えません。出て来るのはなんだか抽象的な話ばかりで、とても議論に耐えうるような情報ではありません。これはうまくない。
確かに、「モデルの実装」という世界ではパテントが全てを支配し秘密主義にも意味があるでしょう。しかし、こと「モデル」の構築を考えた時には、秘密主義は百害あって一利なしなように思えます。
その実装面にしても SCEI は分が悪い状況にあります。秘密主義を取っている SCEI は、全てのイノベーションを SCEI 内で起こす必要があります。ところが Microsoft は、自らの提示したモデルをもっとも良く実装したハードウェアベンダーの製品を選んで使うことが出来ます2。開発者の量が桁違いです。
そういう状況を考えると、次世代 PS が成功するには、そうとう天才的な人が現れて革新的なモデルを提案するか (Cell の伝えられている極めて特殊な構成を見るとこちらを期待したくなりますが、PS2 の時のように思いっきり外す可能性も高いよなぁ…)、または技術面とは全く別のところで相当うまく立ち回る必要があるんじゃないかなぁ、と悲観的になりますね。「PC の世界に深く入り込んでしまっているがゆえに見えなくなっている点」というのもなさそうだしなぁ。そういうモノがあったとしてもたまたま今はまだ注目されていないだけだろうし…。
ビジネス面について一点だけ。Allard さんの言う「開かれた開発環境」を実現するには、現在のコンシューマゲーム機におけるクローズドライセンスモデルではないものを考える必要がありますが、Microsoft はもうずいぶん前からもっと開かれたモデル、つまりオープンな規格の上で、他より価値の高いものを提供することで利益を得る、というよりシンプルなモデルを指向してきているように僕には思えます。ので Allard さんの今後の行方には結構期待!
p.s. マネージャとしてのご忠言、どうもありがとうございます。とても参考になりました。
PSX アップグレード第二弾
今回はノーエラーで無事に終わりました。1.3倍再生はなかなか面白い。またしばらく様子を見てみます。
鬱陶しいログ
鬱陶しいログ
apache のログに、
xxx.xxx.xxx.xxx - - [26/Feb/2004:15:56:54 +0900] "SEARCH /\x90\x02\xb1...
で始まるアクセスがウチのサイトにしてはたくさん記録されてて (しかも１行が文字数にして 32806 文字もある)、おかげでログファイルの容量が先週分と今週分で 40Mbytes 超えてる。調べてみたら、上の時刻 (2004/02/26 15:56:54) くらいから始まってるみたい？先週から急に増えてる？といっても先週は一週間で500件くらいだけど…。今週は二日で既に 500 件超。
送信元がまちまちであるところからたぶん worm なんだと思うんだけど、イマイチ確たる情報が得られない。去年の4月に fix されてる IIS の穴が関係してる、という記述は見つかったんだけど…。
apache の名誉挽回, ゲームマシンのアーキテクチャ, ありえない
apache の名誉挽回
イマイチ結果に納得できなかったので、
- prefork MPM な apache2
- 手元でコンパイル、ほとんどデフォルト設定の apache1.3
でも試してみたところ、小さなファイルでは全て一昨日の apache2 worker MPM とほぼ同等の性能が出ました1。やっぱり速いじゃん、apache。
ところで大きなファイルの場合は、手元でコンパイルしたデフォルト設定のものでも apache2 と apache1.3 の間には大きな差があり、大きなファイルの転送時の効率は apache2 の方が明らかに良さそうでした。
woody 標準の apache が遅い原因はまだちゃんと調べてませんが、考えてみたらバイナリは標準とはいえ、設定については name based virtual host の設定とかされてたりしてあんまり標準的ではないことに気がついたりして…。
ベンチマークは難しいね、やっぱり(汗。
ゲームマシンのアーキテクチャ
マイクロソフトの「XNA」が発表になったりしましたが、次世代 PS 等将来のゲームマシン、というかエンタテインメントマシンのアーキテクチャについてふと考えてみました。
「エンタテインメント」2の本質が「体験を通して感情を動かすこと」だとすれば、物理デバイスと切り離されたファミコン以降のゲーム機が目指さなければならない方向のうち、もっとも計算量が必要な方向は「計算的に現実感を創出する」という方向です。ちなみにイノヴェイティブな手法でピンポイントにとんでもない「リアリティ」を生むことも可能なわけですけれども、そちらはマシン・アーキテクチャとの相関がそれほど高くない (必ずしも計算量を必要としない) のでとりあえず置いておきます。
「現実感創出」のための一つのピース、3D グラフィックスのクオリティ向上に向けては、昨今の PC ゲームの世界を見ていても、nVidia vs. ATI を始めとして各ソフトウェアベンダー間でも極めて競争が過酷なこともあり、相当スゴイ世界が繰り広げられていますが、もう一つのピース、物理シミュレーション系の話は、Half-Life2 など一部そういったことを売りにし始めているゲームも出てきているとはいえ、まだ 3D グラフィックスほどの盛り上がりが見られません。
将来のゲームマシンには、「物理シミュレーションを効率良く実行する」という特性がある種必須なのではないかと僕には思えるのですが、これって今の PC のアーキテクチャの延長線上で考えるのは難しいんじゃないかと思うんですよね。根拠はまったくなくて、強いて言えば「(将来構築される物理シミュレーションモデルはきっと) 並列度が極端に高い処理だろう」、と僕が想像しているからだけなんですけど。
えーとつまり、3D グラフィックスがシェーダモデルを構築しそれに最適化されたハードウェアを生み出してきたように、物理シミュレーションの世界でも何らかの計算モデルを構築し、それに最適化されたハードウェアを設計する…という流れが出て来るんじゃないかと想像しているわけです。
次世代 PS に搭載される予定の「Cell」が、そこまで考えられて作られているといいんだけど (例えば、順序は逆だけど初めから Cell に最適化された物理シミュレーションモデルが用意されている、とか…)、うーん、なんとなくビミョー(笑。
ありえない
六本木ヒルズで起きた回転扉での死亡事故について、ドアに挟まれることを防止するセンサーに死角があった、との報道が。
もし本当だとしたらとんでもない話です。その「安全装置」の設計者は、何を守るべきかを全く理解できていなかったとしか思えない。
昨今の情報漏洩事件での漏洩させた当事者の弁に、「(もし情報漏洩させたことが注意義務違反に当たるなら) ガチガチのセキュリティをかけているごく一部の上場企業以外は、どこも個人情報を扱うことが困難になるのではないかとも思う。」なんて話が出ていて失笑したんですが、これも同じですよね。何を守るべきなのか、をきちんと理解していれば、(一部上場企業にしか賄えないほどの・笑) 無尽蔵にコストがかかることなんてなくて、現実的なレベルに落とし込むことが可能なはずです。
なんとなーく「安全装置が必要と言われたので付けました」とか「とりあえずよく分からないけど SSL にしましたから安心です」というレベルの認識で設計されている気がするなぁ。仮にもエンジニアなら、その「設計の意図」を胸を張って説明出来るくらいでいて欲しい。トレードオフに埋もれた現実も理解出来るけど、かといって本質を見失ってはどうしようもないよ…。
昨日の追記, apache2, Kernel 2.6.4 と VMware 4.5.1
昨日の追記
昨日のテストは非常に小さいファイルで実験してたわけですが、これを例えば 1Mbytes のファイルにしてみると、また全然違った結果が得られます。
apache では
kazawa@tpx20:~$ ab -c 20 -n 1000 http://localhost/dummy.dat
This is ApacheBench, Version 1.3d <$Revision: 1.65 $> apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/
Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Finished 1000 requests
Server Software: Apache/1.3.26
Server Hostname: localhost
Server Port: 80
Document Path: /dummy.dat
Document Length: 1048576 bytes
Concurrency Level: 20
Time taken for tests: 23.763 seconds
Complete requests: 1000
Failed requests: 0
Broken pipe errors: 0
Total transferred: 1049356904 bytes
HTML transferred: 1049083631 bytes
Requests per second: 42.08 [#/sec] (mean)
Time per request: 475.26 [ms] (mean)
Time per request: 23.76 [ms] (mean, across all concurrent requests)
Transfer rate: 44159.28 [Kbytes/sec] received
Connnection Times (ms)
min mean[+/-sd] median max
Connect: 1 21 13.6 20 123
Processing: 279 454 81.0 432 919
Waiting: 275 452 81.0 430 916
Total: 279 475 82.6 448 930
Percentage of the requests served within a certain time (ms)
50% 448
66% 454
75% 464
80% 477
90% 482
95% 649
98% 745
99% 929
100% 930 (last request)
一方、tomcat では十分最適化をかけた後でもこのくらい。
kazawa@tpx20:~$ ab -c 20 -n 1000 http://localhost:8080/dummy.dat
This is ApacheBench, Version 1.3d <$Revision: 1.65 $> apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/
Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Finished 1000 requests
Server Software: Apache-Coyote/1.1
Server Hostname: localhost
Server Port: 8080
Document Path: /dummy.dat
Document Length: 1048576 bytes
Concurrency Level: 20
Time taken for tests: 39.073 seconds
Complete requests: 1000
Failed requests: 0
Broken pipe errors: 0
Total transferred: 1055016112 bytes
HTML transferred: 1054807228 bytes
Requests per second: 25.59 [#/sec] (mean)
Time per request: 781.46 [ms] (mean)
Time per request: 39.07 [ms] (mean, across all concurrent requests)
Transfer rate: 27001.15 [Kbytes/sec] received
Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0 8 14.1 7 299
Processing: 491 769 79.2 751 1338
Waiting: 490 765 79.3 747 1335
Total: 491 777 81.8 758 1340
Percentage of the requests served within a certain time (ms)
50% 758
66% 777
75% 783
80% 785
90% 800
95% 826
98% 1080
99% 1331
100% 1340 (last request)
localhost でテストしているのでボトルネックはローカルの CPU か IO、1Mbytes のファイル一つなら完全にキャッシュに乗っかってしまうことを考えるとたぶん CPU にあるわけですが、apache へのテスト実行時、CPU はほとんど system に費やされているのに対し、tomcat では user と system が半々ぐらいとなっており、このあたり (対 kernel で見た時の apache の皮の薄さに対して JavaVM の厚化粧っぷり) が原因かも。このくらいの規模のテストだと、マシンリソースへの要求はやっぱり tomcat の方がかなり大きいですからね…1。
apache2 ではまだテストしてません。また後程。
apache2
というわけで、apache 2.0.49 でも試してみました。prefork MPM では面白くないので、worker MPM を使って見ました。
kazawa@tpx20:~$ ab -c 20 -n 10000 http://localhost:8080/hello.html
This is ApacheBench, Version 1.3d <$Revision: 1.65 $> apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/
Benchmarking localhost (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Finished 10000 requests
Server Software: Apache/2.0.49
Server Hostname: localhost
Server Port: 8080
Document Path: /hello.html
Document Length: 92 bytes
Concurrency Level: 20
Time taken for tests: 9.430 seconds
Complete requests: 10000
Failed requests: 0
Broken pipe errors: 0
Total transferred: 3580000 bytes
HTML transferred: 920000 bytes
Requests per second: 1060.45 [#/sec] (mean)
Time per request: 18.86 [ms] (mean)
Time per request: 0.94 [ms] (mean, across all concurrent requests)
Transfer rate: 379.64 [Kbytes/sec] received
Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0 9 2.9 8 48
Processing: 7 10 2.2 9 50
Waiting: 6 9 2.1 8 48
Total: 17 18 3.3 17 58
Percentage of the requests served within a certain time (ms)
50% 17
66% 18
75% 18
80% 18
90% 20
95% 25
98% 26
99% 27
100% 58 (last request)
はやっ！1Mbytes のファイルについても、
kazawa@tpx20:~$ ab -c 20 -n 1000 http://localhost:8080/dummy.dat
This is ApacheBench, Version 1.3d <$Revision: 1.65 $> apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/
Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Finished 1000 requests
Server Software: Apache/2.0.49
Server Hostname: localhost
Server Port: 8080
Document Path: /dummy.dat
Document Length: 1048576 bytes
Concurrency Level: 20
Time taken for tests: 7.669 seconds
Complete requests: 1000
Failed requests: 0
Broken pipe errors: 0
Total transferred: 1048852000 bytes
HTML transferred: 1048576000 bytes
Requests per second: 130.40 [#/sec] (mean)
Time per request: 153.38 [ms] (mean)
Time per request: 7.67 [ms] (mean, across all concurrent requests)
Transfer rate: 136765.16 [Kbytes/sec] received
Connnection Times (ms)
min mean[+/-sd] median max
Connect: 3 11 3.1 12 28
Processing: 138 140 11.2 138 192
Waiting: 127 139 11.1 136 190
Total: 142 152 11.1 149 203
Percentage of the requests served within a certain time (ms)
50% 149
66% 152
75% 155
80% 156
90% 161
95% 166
98% 198
99% 202
100% 203 (last request)
と、他を引き離す性能を見せました。正直、1.3 系に対してこれほどアドバンテージがあるとは思いませんでした。それとも 1.3 系も自分でコンパイルしてみたものではまた違うのでしょうか？
なお、性能に関係するパラメータはデフォルトのまま、下記の通りです。
StartServers 2
MaxClients 150
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestsPerChild 0
Kernel 2.6.4 と VMware 4.5.1
VMware の 4.5.1 がリリース、とのニュースを読んで、さっそく入れてみました。
いつも通り tar ball を展開後、vmware-install.pl を実行、4.0.5 の時はひっかかっていた kernel module の作成もさくさく進んで、無事インストール出来たかに見えました。
ところが、いざ実行してみようとすると、Window は表示されるのですが、Guest OS を起動しようとすると signal 11 で落ちてしまいます。/var/log/kern.log には oops まで出てしまう始末。どうも vmmon モジュールがうまく動作していないようです。
しょうがないので 4.0.5 に戻そうとしたんですが、kernel 2.6 に 4.0.5 を入れるための手元にあったパッチ (vmware-any-any-update48.tar.gz) は kernel 2.6.4 の場合は使えず、最新の vmware-any-any-update55.tar.gz もなぜかモジュールコンパイルの途中でエラーが出てうまくいきません。
一瞬途方にくれて「kernel をダウングレードするしかないかなぁ…」と思ったんですが、上記パッチの提供元にあった、obsolete ディレクトリを掘り返してみたところ、vmware-any-any-update53.tar.gz ならば正常にパッチを当てられることが判明、なんとか無事、Kernel 2.6.4 上で VMware を再び動作させることが出来ました。
良かった良かった。
不思議な結果?(2)
不思議な結果?(2)
CGI や FastCGI、Servlet 等の性能を評価していた時のこと。
ふと戯れに (ってそればっかりだな…) apache と tomcat の Coyote で、通常のファイル送出性能にどれくらいの差があるのか調べてみたくなりました。
環境は昨日と同じです。性能測定には ab (apache bench) を使いました。
さて、まず apache。手元の環境は Debian woody、apache の version は 1.3.26 です。
kazawa@tpx20:~$ ab -c 20 -n 10000 http://localhost/hello.html
This is ApacheBench, Version 1.3d <$Revision: 1.65 $> apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/
Benchmarking localhost (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Finished 10000 requests
Server Software: Apache/1.3.26
Server Hostname: localhost
Server Port: 80
Document Path: /hello.html
Document Length: 92 bytes
Concurrency Level: 20
Time taken for tests: 19.021 seconds
Complete requests: 10000
Failed requests: 0
Broken pipe errors: 0
Total transferred: 3560000 bytes
HTML transferred: 920000 bytes
Requests per second: 525.73 [#/sec] (mean)
Time per request: 38.04 [ms] (mean)
Time per request: 1.90 [ms] (mean, across all concurrent requests)
Transfer rate: 187.16 [Kbytes/sec] received
Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.2 0 10
Processing: 1 37 101.9 26 2658
Waiting: 1 37 101.9 26 2658
Total: 1 37 101.9 26 2658
Percentage of the requests served within a certain time (ms)
50% 26
66% 28
75% 29
80% 30
90% 33
95% 38
98% 175
99% 531
100% 2658 (last request)
毎秒500回ちょっとですか。この時は妙に結果がばらつくのが気になりました。あ、昨日と同じで、何回か実行して結果が安定してきたところを見ています。
さて、次に tomcat です。tomcat のバージョンは 5.0.19、JavaVM は最新のものを持ってきて 1.5.0β1 を使ってみました。
kazawa@tpx20:~$ ab -c 20 -n 10000 http://localhost:8080/hello.html
This is ApacheBench, Version 1.3d <$Revision: 1.65 $> apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/
Benchmarking localhost (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Finished 10000 requests
Server Software: Apache-Coyote/1.1
Server Hostname: localhost
Server Port: 8080
Document Path: /hello.html
Document Length: 92 bytes
Concurrency Level: 20
Time taken for tests: 14.684 seconds
Complete requests: 10000
Failed requests: 0
Broken pipe errors: 0
Total transferred: 3133756 bytes
HTML transferred: 921104 bytes
Requests per second: 681.01 [#/sec] (mean)
Time per request: 29.37 [ms] (mean)
Time per request: 1.47 [ms] (mean, across all concurrent requests)
Transfer rate: 213.41 [Kbytes/sec] received
Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0 14 7.1 13 147
Processing: 15 15 7.7 14 148
Waiting: 7 14 7.5 13 147
Total: 26 29 9.0 26 155
Percentage of the requests served within a certain time (ms)
50% 26
66% 27
75% 27
80% 28
90% 35
95% 38
98% 57
99% 70
100% 155 (last request)
むむむ。apache よりも速いですね。なお、デフォルト設定の tomcat から変更したところと言えば、
- JAVA_OPTS 環境変数に「-server」オプションをセット (HotSpot Server VM が利用される)。
- server.xml を編集してアクセスログが出力されるようにした (apache 側と条件を揃えるため)。
くらいです。あ、もちろん Server VM 使用、ということで、結果が安定するまで何回か (5〜6回) くらい ab を回し、JITC による最適化が行き渡るようにしています (最適化されるまでは4倍くらい遅いです)。
さて、ここまでの話だと「単純なファイル送出なら apache より tomcat 方が速い」という結論が出かねないわけですけれども、ここで、apache のテスト時に結果がばらついていたことを思い出しました。そこでテスト中の apache プロセスの状況を調べてみました。
すると、結構高い頻度で apache プロセスが起動したり終了したりしているらしいことが分かりました (defunct な apache プロセスがたびたび現れる)。手元の apache は woody のそれをインストールしたままの設定でしたが、性能に関係する主なパラメータの状況は下記のようになっていました。
MinSpareServers 5
MaxSpareServers 10
MaxClients 150
MaxRequestsPerChild 100
MaxClients が 150 なのはいいとして、MaxRequestsPerChild が 100、ってのはまたずいぶん安全よりな設定なんですね、woody は。
そこで、SpareServer が常に 20 以上存在するようにし、また MaxRequestsPerChild を 10000 に変更してもう一度テストしてみました。その結果が下記です。
kazawa@tpx20:~$ ab -c 20 -n 10000 http://localhost/hello.html
This is ApacheBench, Version 1.3d <$Revision: 1.65 $> apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/
Benchmarking localhost (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Finished 10000 requests
Server Software: Apache/1.3.26
Server Hostname: localhost
Server Port: 80
Document Path: /hello.html
Document Length: 92 bytes
Concurrency Level: 20
Time taken for tests: 14.631 seconds
Complete requests: 10000
Failed requests: 0
Broken pipe errors: 0
Total transferred: 3560712 bytes
HTML transferred: 920184 bytes
Requests per second: 683.48 [#/sec] (mean)
Time per request: 29.26 [ms] (mean)
Time per request: 1.46 [ms] (mean, across all concurrent requests)
Transfer rate: 243.37 [Kbytes/sec] received
Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0 2 2.6 1 30
Processing: 6 27 8.1 25 387
Waiting: 0 26 8.2 25 386
Total: 6 29 8.6 27 388
Percentage of the requests served within a certain time (ms)
50% 27
66% 28
75% 29
80% 30
90% 37
95% 49
98% 54
99% 57
100% 388 (last request)
これで、tomcat とほとんど変わらない性能が出るようになりました。apache って結構頻繁に SpareServer の回収を行ってるんですね。また、大量のアクセスが定常的に発生しているような場合は、常にたくさんのプロセスが立ちあがっているように設定しておかないと結構オーバーヘッドが大きいのですね。なるほどー。
というわけで、こちらはあんまり不思議な結果にはなりませんでした。一つ分かったのは、単純なファイル送出ならば tomcat Coyote でも十分な性能を持っていること。apache の持つ多彩な機能が必要ない場合は、安直に Coyote を使ってしまうのも悪くないのかもしれません。
昨日は, 不思議な結果
昨日は
夜になって鳥乃が激しく嘔吐し、しまいには血の混じった胃液まで吐き出したので急遽近所の救急病院へ行きました。そこで吐き止めと失われた水分を補給するために点滴してもらっている間に鳥乃はすやすや眠ってしまい、0:00 過ぎに家に帰ってきました。
今日、かかりつけの病院に行って薬をもらってきたんですが、「今日一日は固形物は避けるように」と言われたのに早くもいつもの食い意地を発揮してヨーグルトやプリンをぱくぱく。元気になったのはいいけどちょっと心配だよ…。
不思議な結果
64bit 環境での性能向上率をいろいろ調べていた時のこと。
C で言う long long int、64bit 整数に関する演算速度を調べてみようと、下記のようなテストプログラムを作りました1。
#include <stdio.h>
int main()
{
long long int a, b, c, d;
int i;
a = b = c = d = 1;
for ( i=0; i<100000000; i++ )
{
a = d % 0xFFFFFFFFFFFFFFFLL;
b = a + a + 1LL;
c = b * 4LL;
d = c / 2LL;
}
printf("i:%d, a:%lld, b:%lld, c:%lld, d:%lld\n", i, a, b, c, d);
}
まず、このプログラムを今の僕の手元の環境でコンパイル、実行した時の結果は下記の通りとなりました2。
kazawa@tpx20:~$ uname -a
Linux tpx20 2.6.3 #1 Sat Mar 6 11:30:13 JST 2004 i686 unknown
kazawa@tpx20:~$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 8
model name : Pentium III (Coppermine)
stepping : 3
cpu MHz : 597.526
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse
bogomips : 1179.64
kazawa@tpx20:~$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
kazawa@tpx20:~$ icc -V
Intel(R) C++ Compiler for 32-bit applications, Version 7.0 Build 20021021Z
Copyright (C) 1985-2002 Intel Corporation. All rights reserved.
FOR NON-COMMERCIAL USE ONLY
GNU ld version 2.12.90.0.1 20020307 Debian/GNU Linux
Supported emulations:
elf_i386
i386linux
/usr/lib/crt1.o: In function `_start':
/usr/lib/crt1.o(.text+0x18): undefined reference to `main'
kazawa@tpx20:~$ gcc -O3 -o multi_gcc multi.c
kazawa@tpx20:~$ time ./multi_gcc
i:100000000, a:436906, b:873813, c:3495252, d:1747626
real 0m19.619s
user 0m19.201s
sys 0m0.004s
kazawa@tpx20:~$ icc -O3 -mp1 -prec_div -fp_port -rcd -tpp6 -mcpu=pentiumpro -xiMK -o multi_icc multi.c
kazawa@tpx20:~$ time ./multi_icc
i:100000000, a:436906, b:873813, c:3495252, d:1747626
real 0m13.636s
user 0m13.346s
sys 0m0.003s
ここまでは、「ふむふむ、やっぱり Intel コンパイラの方が結構効率いいんだなぁ (最適化オプションが違い過ぎかも)」とか思いつつ普通に考えていました。
実際にはここでさらに 64bit バイナリを作ってテスト…という作業を行っていたのですが、その後戯れに、「Java だとどうだろう？」と思いつき、テストしてみることにしました。
まず、先程の C のプログラムとほぼ同じ内容の下記のようなプログラムを作成します。
public class multi {
public static void main(String[] args) throws Exception {
long a, b, c, d;
int i;
a = b = c = d = 1;
for (i = 0; i < 100000000; i++) {
a = d % 0xfffffffffffffffl;
b = a + a + 1l;
c = b * 4l;
d = c / 2l;
}
System.out.println("i:" + i + ", a:" + a + ", b:" + b + ", c:" + c + ", d:" + d);
}
}
Java の場合は long が 64bit なのでこれで OK なのです。さてその後、普通に javac でコンパイルして実行してみました3。
kazawa@tpx20:~$ java -server -version
java version "1.4.2_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_01-b06)
Java HotSpot(TM) Server VM (build 1.4.2_01-b06, mixed mode)
kazawa@tpx20:~$ javac multi.java
kazawa@tpx20:~$ time java -server multi
i:100000000, a:436906, b:873813, c:3495252, d:1747626
real 0m7.485s
user 0m7.223s
sys 0m0.033s
ちょっとびっくりなことに、VM の起動時間まで含まれてしまう time による計測にもかかわらず、icc による結果に比べても倍くらい高速です。なんじゃこりゃーって感じです。
１億回のループ中、中間結果をはしょったりしているんじゃなかろうか、と１千万回に１回中間結果を表示するようにしてみたりもしたんですが、結果は変わりませんでした。当然の如く、得られる数値も全て同一です。
これほど小さなプログラム、それも計算主体のものでこんなに差が出る理由がはっきり言って謎です。なお興味深いことに、テストプログラム中の *4 を *6 に、/2 を /3 に変更して試してみた結果が下記です。
kazawa@tpx20:~$ time ./multi_icc
i:100000000, a:-384307168202464939, b:-768614336404929877, c:-4611686018429579262, d:-1537228672809859754
real 0m31.510s
user 0m30.825s
sys 0m0.007s
kazawa@tpx20:~$ time java -server multi
i:100000000, a:-384307168202464939, b:-768614336404929877, c:-4611686018429579262, d:-1537228672809859754
real 0m32.544s
user 0m31.778s
sys 0m0.027s
icc 版は２倍、java 版は4倍くらい遅くなって、どちらもほとんど変わらない結果となりました (Java が１秒ほど遅いのは VM 起動時のラグだとすると体感的にはちょうどな感じ)。つまりあれですか、かけ算をシフト命令で置き換えられるような時の 64bit 計算の効率が激しく良い、ってこと？しかし、いくら HotSpotVM が動的最適化して効率の良いネイティブコードを生成する、と言ったって、icc が静的に生成するコードよりも効率のいいものを作れるものなんでしょうかね。しかもこんな単純なコードで。
おまけ。HotSpot Server VM でなく Client VM では、
kazawa@tpx20:~$ time java multi
i:100000000, a:436906, b:873813, c:3495252, d:1747626
real 0m58.071s
user 0m56.676s
sys 0m0.040s
てな感じになります。また IBM VM でも
kazawa@tpx20:~$ /usr/local/IBMJava2-141/bin/java -version
java version "1.4.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1)
Classic VM (build 1.4.1, J2RE 1.4.1 IBM build cxia32141-20030522 (JIT enabled: jitc))
kazawa@tpx20:~$ time /usr/local/IBMJava2-141/bin/java multi
i:100000000, a:436906, b:873813, c:3495252, d:1747626
real 0m56.422s
user 0m54.605s
sys 0m0.093s
と、あまり変わらない結果となります。こう見てくると、HotSpot Server VM だけが異常に (C と比べても) 速いことがわかります。なんでなんだろう…？
液晶テレビ
液晶テレビ
最近、電気屋さんにいくとついつい大画面フラットテレビ売り場に入り浸ってしまいます。
どこかで「日本人には絵画的な液晶テレビの画質がうけている」という話を見かけましたが、確かに液晶テレビの画面は絵画的です。店頭でずっと見ていて1、個人的にはどうも違和感、というか物足りない感じがずっとあったのですが、昨日ブラウン管のテレビを見比べてみて一つ原因かもしれないことを思いつきました。
というのも、液晶テレビには (当たり前なんですけど) フリッカーがほとんどないんですよね。逆に残像が気になるくらい。もちろん、最近の機種はずいぶん残像が少なくなってきていて、実用上はほとんど問題ないわけですけれども。
対して、ブラウン管のテレビはかなりちらちらしています。真正面から見ている時はほとんど気になりませんが、目の端に画面を捉えている時などはかなり気になるでしょう？
僕なんかは小さいころからブラウン管のテレビをずっと見続けてきていて、テレビというのはすなわちブラウン管のあれだ、という意識があるわけです。ああいう、ちらちらした画面、言ってみれば (無駄に) 刺激過多の画面をずっと見続けてきたがゆえに、液晶画面の絵画的な、しっとりとした画面を見ると、どうも物足りないというか、違和感があるんじゃないかな、と思いました。同じようにフリッカーが少なく、しかも残像もないプラズマはどうか、というと、どちらかと言うと液晶テレビを見た時の印象に近い気がするし…。気のせいかなぁ？
とにもかくにも、今の僕の感覚はある意味狂ってしまっているとも言えるわけで、子供たちのためにはもしかすると今からもっと低刺激な映像装置を使った方が良いのかもしれないなぁ、と思ったりしました。