bird昨日の追記, 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 を再び動作させることが出来ました。
良かった良かった。

bird不思議な結果?(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 を使ってしまうのも悪くないのかもしれません。

bird昨日は, 不思議な結果

昨日は

夜になって鳥乃が激しく嘔吐し、しまいには血の混じった胃液まで吐き出したので急遽近所の救急病院へ行きました。そこで吐き止めと失われた水分を補給するために点滴してもらっている間に鳥乃はすやすや眠ってしまい、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 による結果に比べても倍くらい高速です。なんじゃこりゃーって感じです。

1億回のループ中、中間結果をはしょったりしているんじゃなかろうか、と1千万回に1回中間結果を表示するようにしてみたりもしたんですが、結果は変わりませんでした。当然の如く、得られる数値も全て同一です。

これほど小さなプログラム、それも計算主体のものでこんなに差が出る理由がはっきり言って謎です。なお興味深いことに、テストプログラム中の *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 版は2倍、java 版は4倍くらい遅くなって、どちらもほとんど変わらない結果となりました (Java が1秒ほど遅いのは 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 と比べても) 速いことがわかります。なんでなんだろう…?

bird液晶テレビ

液晶テレビ

最近、電気屋さんにいくとついつい大画面フラットテレビ売り場に入り浸ってしまいます。
どこかで「日本人には絵画的な液晶テレビの画質がうけている」という話を見かけましたが、確かに液晶テレビの画面は絵画的です。店頭でずっと見ていて1、個人的にはどうも違和感、というか物足りない感じがずっとあったのですが、昨日ブラウン管のテレビを見比べてみて一つ原因かもしれないことを思いつきました。
というのも、液晶テレビには (当たり前なんですけど) フリッカーがほとんどないんですよね。逆に残像が気になるくらい。もちろん、最近の機種はずいぶん残像が少なくなってきていて、実用上はほとんど問題ないわけですけれども。
対して、ブラウン管のテレビはかなりちらちらしています。真正面から見ている時はほとんど気になりませんが、目の端に画面を捉えている時などはかなり気になるでしょう?
僕なんかは小さいころからブラウン管のテレビをずっと見続けてきていて、テレビというのはすなわちブラウン管のあれだ、という意識があるわけです。ああいう、ちらちらした画面、言ってみれば (無駄に) 刺激過多の画面をずっと見続けてきたがゆえに、液晶画面の絵画的な、しっとりとした画面を見ると、どうも物足りないというか、違和感があるんじゃないかな、と思いました。同じようにフリッカーが少なく、しかも残像もないプラズマはどうか、というと、どちらかと言うと液晶テレビを見た時の印象に近い気がするし…。気のせいかなぁ?
とにもかくにも、今の僕の感覚はある意味狂ってしまっているとも言えるわけで、子供たちのためにはもしかすると今からもっと低刺激な映像装置を使った方が良いのかもしれないなぁ、と思ったりしました。

bird君は天然色, 「Avalon」, 今日のあゆみさん

君は天然色

生茶」の新しい CM でかかっている歌。懐かしいなぁ。好きなんですよね、この歌。

「Avalon」

Avalon SAK から借りていまさら見ました。すみません>誰に?

実写、なのに全然実写っぽくないのが印象的。昔、人は人工物と自然物を主に複雑さの違いで判別している、という話を読んだのを思い出しました。

映画だけだとストーリー的には少し食い足りない感じ。腹八分目で抑えておくのがポイントなのかしら?(笑。それにしてもますます「イノセンス」が見たくなってしまった…。

今日のあゆみさん

F1 予選の中継を見ていた時のこと。
「ジャガーってイタリアのチーム?」
「いや、イギリス」
「イギリス?ミック・ジャガー?」
「?」
「…肉じゃが?」
なんでそーなるの!?(笑

birdVAIO のキーボード, リモコン交換

VAIO のキーボード

あゆみさん VAIO のキーボードがまた効かなくなってきた…。
ずいぶん前からふとした拍子にキーボードが効かなくなることがありました。1) 電源を入れ直す or 再起動 or スタンバイから復帰すれば直る、2) USB キーボードでは問題なく入力出来る、といったことから、どうも OS がくさい。
ちょっと調べてみると、「[REG] デバイス ドライバ エントリ、パート 2 – マウス/キーボード ドライバ」というページを見つけました。イベントビューワーの「システムログ」には特に何も残っていないところから、怪しそうなパラメータとして「PollStatusIterations」を増やしてみたりしたんですが、改善されず。他にも「PollingIterations」や「PollingIterationsMaximum」、「ResendIterations」などを増やしてみたりもしてみましたが、状況は変わりませんでした。
しょうがないから USB キーボードを買ってくるかなぁ…。

リモコン交換

ちょっと前から PSX のリモコンの効きが悪くなってきました。電池チェッカーで調べてみた限り、電池が切れている、というわけでもないようなんですが、とにかくリモコンが効かない。おかしいのは、そんな時でも裏の電池蓋を開けて、電池をグルグル回してあげると、ごく普通に使えるようになるのです。
しばらくグルグルしつつ使っていたんですが、イイカゲンめんどくさくなってきたのでまたしてもサポートに電話してみました。こちらで一通り症状を伝えた後、先方に教えてもらった確認点を確認して特に相関がないことを報告すると、あっさり交換処理に。しかも新品をすぐ送ってくれ、新品到着時に故障したリモコンを運送屋さんに交換で渡してくれれば良い、とのこと。
というわけで、我が家はリモコンだけ新品の PSX となりました。今考えてみると、使っていた電池1が微妙に消耗してたのかも。チェッカーではまだ残量はあることになっていましたが、PSX のリモコンが要求する電圧が実はかなりシビアだ、とか。グルグル回すと復活するのは、グルグルすることで電池と接点がこすれて接触抵抗が下がり、一時的に電圧が回復する、とか。そんなことはないか…。
新品電池を入れてちゃんと試してみればよかったなぁ。今度のリモコンで同じ状況になったら試してみようっと2

birdMSN Messenger 6.1, Subversion 1.0.1, 桜のつぼみが

MSN Messenger 6.1

にアップデートされてから、netbios-ns な UDP パケットをやたらにばらまいているような気が…。
気のせいか?

Subversion 1.0.1

mod_authz_svn が SVNParentPath に対応したり、匿名ユーザも含めた形でアクセスコントロールが出来るように拡張された模様。ますます便利になったなぁ。
それにしても、こちらの日本語訳はいつも対応が早くてとても助かります。今回の拡張についてもさっそく翻訳されているようです。どうもありがとうございます。

桜のつぼみが

大きくなってきましたね。都立大の周りにはたくさん桜の木があって、毎年楽しませてもらっています。アウトレットモールの菜の花畑も綺麗だし、いよいよ春めいてまいりました…。

bird「ビラヴド」, 読書の時間, こないだのデカレンジャー, 日曜に

「ビラヴド」

ビラヴド トニ・モリスン著。南北戦争前後のアメリカにおける、黒人奴隷の「自由」や「自身」を取り戻すための苦悩の日々を描いたお話。あゆみさんに借りた本。

この本では、当時のアメリカにおける黒人奴隷の境遇が、当事者の視点で切々と語られています。読むのがつらいくらいのその告白を読みつづけている間に僕が感じたのは、絶望的な「共感の欠如」でした。白人の『先生』は、単なる家畜と同じように奴隷を扱います。そこに悪意があるわけではなく、奴隷というものが他の家畜と同じ、農場主にとっての資産に過ぎないと思っているだけなんですね。出産可能な年齢の女奴隷は資産を増やしてくれる可能性があるから大切、まだ若い子供奴隷を売って大人の奴隷を二人買おう、女奴隷に子供を生ませるために若い男奴隷とまぐわせよう、エトセトラ、エトセトラ…。『先生』が来る前に農場を所有していたガーナーさんにしても、「同じ人間である」というレベルでは共感を持ちつつ、しかし奴隷という立場への共感は持ち得ませんでした。

一方の黒人の側でも、共感し得ない白人による扱いを受け続けたゆえ、自由州において黒人の権利獲得に尽力している白人に対してすら、彼らの考えていることなど分かるわけがない、とあきらめてしまっています。

本を読みながら僕は、ガンジーさんが菜食主義者だったことを思い出しました。それはもちろん、彼がヒンズー教徒であったことと深い関係があるのでしょうが、彼の持っていた「共感の力」とも関係しているのではないだろうか、と思いました。ガンジーさんが大衆から圧倒的な支持をうけた理由として、大衆と同じ服を着、大衆と同じものを食べて、歩いて大衆の元へ赴き、大衆に対して共感出来る言葉で語りかけることが出来たからだ、と書いてありましたが、ガンジーさんのサッティヤーグラハも、原理的にはその、人間の持つ「共感の力」を用いたものと言えるのではないでしょうか。

人は、共感を感じないものに対してはどこまでも残酷になれるようです。しかし逆に、「共感の力」はアメリカで奴隷制度を廃止させました。他者への共感を拒否する人間はまた、他者に共感されることもなくなってしまう、ということを、いとも簡単に人を殺すことの出来る人達には考えて欲しいです。

読書の時間

総計三時間にもなる行き帰りの電車で本を読んでいればそりゃたくさん読めますがな>うさ。薄い文庫本なんかだと一往復で読み終わっちゃうんですよね。だから最近は厚い本が好き。厚すぎると腕が筋肉痛になっちゃうのが難点。「虚数の情緒」は大変だった…。
森博嗣は犀川&萌の最初の三巻だけ読みました。その野暮ったさが結構ツボなので、そのうちまた続きを読むかも。

こないだのデカレンジャー

「ウメコ、俺じゃない」
わはははははははは。あいかわらず最高っす。今回はかなりお色気過多だったなー。父親向けなんでしょーか?

日曜に

家族でお出かけ。駅を歩いているとあゆみさんが恥ずかしそうにしている。
「どしたの?」
と聞いてみたところ、
すっぱいお口をした Suica ペンギンのポスター1を見て、思わず同じ顔をしちゃったところを、ちょうどすれ違った人にばっちり見られちゃって恥ずかしかった」
とのこと。わはは。あるある、そういうこと。

bird「王の帰還」, そういえば鳥乃は, ここのところ, 次はマレーシア

「王の帰還」

先週の金曜にレイトショーで見てきました。21:00 スタートだと終了は 24:40!歩いて帰れるところに映画館があるんでもないとなかなか見られないスケジュールだよな…。
で、肝心の内容ですが、僕は3時間半があっという間に感じられたほど、楽しめました。どのシーンをとってもおざなりなところがなく、原作への愛を感じる出来だったと思います。
映画の内容には大満足だったんですが、隣に座ったおじさんが…。シーンの変わり目に必ず「ムフー!」と盛大な鼻息を吹くのです。それも「息止めてんのかよ!」と裏拳ツッコミしたくなるような勢い。むちゃくちゃ気が散るがな。

そういえば鳥乃は

大きくなったらドラえもんになりたいのだそうです。こないだ、いつものように「ドラえもんになりたいんだ!」と言った後、小さな声で「僕ドラえもん」と大山のぶ代チックな声でぼそっとつぶやいてました。おとーさんは笑いをこらえるのに必死だったよ。プププ。

ここのところ

更新頻度が低いのは、実生活と脳生活1の比率について最近よく考えているからかも。思うに、どうも僕はこれまで家庭での実生活を軽んじ過ぎていたようで、必要以上に脳生活偏重型だったみたいです。ここを更新することなどの脳生活も確かに必要なことだとは思いつつ、日々の生活の中での比率は今よりもう少し低くてもいいだろうと。それよりももっと人間的な生活を送るために必要な実生活に時間をかけた方が、僕にとっての幸せ度は高まることに最近ようやく気がつきました。子供達にとっても今はその方が良いみたい。

次はマレーシア

F1 の話。今週末はマレーシア GP です。先週のオーストラリアは、開幕戦としては近年稀に見るくらい落ち着いたレースでした。たぶんどのチームも今年から導入された「1レース1エンジンルール」が気になって、「リタイアするくらいなら速度を犠牲にしよう」とコンサバ方向に振ってきた結果なんでしょうが、その反動がマレーシアで出るんじゃないかと今から楽しみ。とっても涼しかったオーストラリアと違い、マレーシアは猛暑ですからねー。明らかに速度の足りなかったチームもちらほらありましたから、今回はきっと勝負をかけてくるに違いない。ドタバタしたレース展開に期待!

birdMS InfoPath, 歩きタバコ

MS InfoPath

が近ごろ流行っているようですね。こちらの記事などを見て思ったのは、クライアントを握っている Microsoft としてはしごく当たり前の展開だとは思いつつ、その革新性はどこにあるんだろうか?ということ。

僕なりの理解では、InfoPath とは、

  1. XML オーサリングツールであり、
  2. FORM 作成/実行ツールである。

というもの。先に紹介した記事でも、「InfoPathは、定形フォームを使ったデータ入力の支援ツールだといえる。」とあり、最後は「一言でいって『もはやクライアント・アプリケーションを開発する必要はない』ということだ。」とまで言っており、つまりは現在 SIer が各企業にカスタム・メイドしている業務系のアプリケーションのクライアント部分に位置づけられる製品/技術であることが分かります。

さて、まず最初に僕が考えたのは、「MS ワールドの外に同等の位置づけの製品はあるだろうか」という点です。同じような業務アプリケーションのクライアント側技術としては、最近は Web ベースとされることも多く、そこで用いられる技術としては Struts/Tiles や JSF、オーサリング環境という意味では Project RAVE が対応することになるのでしょうか。Web ベースの UI はクライアント環境への依存度と機能性がトレードオフとなっており、依存度を低くしようと思えば使える機能は非常に限定されてしまう、という欠点があります。クライアントをガッチリ握っている Microsoft としては、思いっきりクライアント環境に依存する代わりに極めてリッチな UI を提供する、というアプローチはある意味王道と言えます。

しかしそう考えていくと、「それってちょっと前に流行った Client/Server システム (いわゆるクラサバ) とどこが違うの?」という気がしてしまいます。C/S 時代も、クライアント側 UI は VB 等を用いてペタペタ form 部品を貼付けていくだけで作成することが出来ました。また、バックエンドシステムとの間は、ODBC を使って RDBMS 中立を保ちつつデータをやりとり、というのが定番でした。

それら過去の仕組みに対して InfoPath では、XML という中立なデータ構造外部化形式が挟まっていることによって、Client-Server 間のみならず、Client 内に閉じたデータも中立的に、抽象化された形で扱うことが出来る、という点が新しいのかな?構造化された情報自体をユーザが意識しやすくなっている点が革新的?確かにかつてのシステムではユーザが扱っている情報の構造全体を明確に意識することは難しかったですが、反面あえて見せないことでシステムに最適化された形のハンドリングも可能だったわけです。

それに、いわゆる C/S システムから Web ベースシステムへの大きな流れを作った原因の一つである、「クライアント環境への依存度」1はまた元の状態に戻ってしまいますよね?いくら XML がシステム中立なデータ構造とはいえ、その中身に何らかの意味を与え動作させる以上、それを読んで動くプログラムのバージョンにまったく依存しないように保つことは至難の技のように思えます。比較的後方互換性が重要視されている Web ブラウザの HTML レンダリングですら、バージョン間非互換性には皆泣かされてきているわけで。

単なる「リッチなコントロールが使える XML オーサリングツール」という存在としては、実はかなりレアだったりしますから、価値あるものだと思います。マルチメディアを扱える特定業務向け XML オーサリングツールを Java (Swing+JAXP) で作っているのを見ていたことがありますが、やっぱりそれなりにめんどくさそうでしたから…。

すなわちそういうことなのかな?上記記事の「もはやクライアント・アプリケーションを開発する必要はない」っていうのが言い過ぎなだけ?

追記。クライアント環境への依存性、という点では、XML Schema という標準準拠なデータファイルを用意するだけで最低限のフォームは自動生成出来るようですね。でも、妥当性チェックなどの少し突っ込んだ処理を記述するためにはやっぱり JScript や VBScript を用いるようで、この辺は結構微妙。

XML Schema (+妥当性チェックのための独自ロジック) を用意するのと、例えば Struts で入れ物の JSP+form オブジェクト+Validator クラスを用意するのって、前者の方が圧倒的に簡単、ってことは必ずしもない気がするがなぁ。

歩きタバコ

会社帰り、団地に向かう道を歩いていると、歩きタバコしている人を小走りに追い抜く若い女性を見かけ。うーん気持ち分かるなぁ。
体調がいい時はあんまり気にならないけど、すごく疲れている時とかって結構ツライんですよね。しかも帰る方向が一緒だったりするとずっと煙を吸わされちゃったりして。タバコを吸う人にはこういう感覚はよく分からないかもしれませんが、例えて言えば口臭が超臭い人の吐く息を家に歩いて帰る間中吸わされているような感じ、かなぁ。言葉は悪いですが…。

First | Prev | 418 | 419 | 420 | 421 | 422 | Next | Last