ユメのチカラ

memcached Night in Tokyo #1

先日開催された memcached Night in Tokyo #1 というのに参加してきた。

http://groups.google.com/group/memcached-ja/web/memcached-night-in-tokyo-1

夕方6時開催という昨今の勉強会としては早めの開始時刻なので、あたふたと会社を出た。場所は原宿である。おされな場所である。浮足立つ。ということはどうでも良くて会場であるmixiに初めていったのだが綺麗なオフィスであった。

memcachedというのは、データベースに対する分散メモリキャッシュ技術みたいなもので昨今のWebではよく利用されている。国内ではmixiでの事例がよく知られている。

http://ja.wikipedia.org/wiki/Memcached

この話を初めて聞いたとき、うーん随分乱暴な話だな、RDBMSでやるべき仕事だろ、そーゆーことはと思った。由緒正しいRDBMSではこーゆーのはいかんだろう的なことを思った。しかし発想の転換というかちょっとしたハックというか、実際memcachedのソースコードは6千行位のきわめてシンプルな実装になっていて、MySQLとかスケールしねーよなあとか思っていたハッカーが自分の問題を素早く解決するために作ちゃったという感じなんだろうな、などとも思う。作ってみたら思いのほかいい感じで使いやすくて、どんどん適用事例も生まれ、ソースコードもオープンなので、米国あたりのWeb2.0系企業でがしがし使われるようになったと。

昨今OSやらRDBMSやらアプリケーションサーバやらWebサーバやらありとあらゆるものがオープンソースなので、どこで問題を最適化してもよくてRDBMSの上にちょっとしたキャッシュをおいて擬似的に高速化をはかってみたというのがmemcachedなのだろうなと思う。

mixiでは135台のmemcachedサーバを利用していて(この数もすごいな、国内最大級かな)、メモリを3GBほどわりあてているらしい。マシンはPentium 4との事なので発熱とかもすごそうな気がする。

KLABの安井さんのお話はmemcachedのreplicationだった。memcachedはシステムが死ぬとデータが消失するので、リプリケートをして永続性を持たせたいなあというお話である。永続性とかフェールオーバーとか信頼性とか、そーゆー事を言いだすと、話がどんどん複雑になるのでmemcachedとは相性が悪いのではないだろうかと思うのだけど、どうなんだろう。この手の話も昔からあって、本当の信頼性を求めるなら完全二重化とか、そーゆー話になるのだけど、コストと拡張性のバランスも必要で、さらにはスケーラビリティをどうするかという問題もあって難しい。また非同期の更新だとどうしても原子性をどう担保するかという問題もある。いっそのこと楽観的にやっちゃて、矛盾が発生したらリトライという感じでもいいのかもしれない。

すずききよたか(kiyotaka)さんのお話はmemcachedの利用をいろいろな角度からしていた。まあ、消える可能性のある汎用DBというのは言いえて妙である。Solarisで運用しているので、Solarisのお友達を募集していた。困っている事を自分から晒すというのは勉強会メソッドとしては黄金のパターンかと思う。そして同志と出あう。memcachedを使っているだけではなくSolarisで使っているという同志の結束は固そうに見えた。

mixiの長野(kazeburo)さんは大規模事例で、特にがりがりチューニングをしているという感じではなかった。

はてなの田中(stanaka)さん、30台のcore2 quad メモリ8GBで運用している。それぞれにはXenでmemcachedサーバとアプリケーションサーバを起動しているらしい。こちらも特にチューニングしているという感じではなかった。

mixiの前坂(tmaesaka)さんはmemcached Binary Protocolの解説である。こーゆープロトコルの設計の話は好きだ。速度命だし。テキストのプロトコルだとパースデコードのコストがかかるのであらかじめ定義したバイナリのプロトコルで高速化をはかろうというお話である。バイナリプロトコルであればインジェクションは簡単ではないのでセキュリティ向上にもつながるよ。

固定長のヘッダ(16バイト)+可変長のオマケのフィールドというデータ構造になっている。

http://code.sixapart.com/svn/memcached/branches/binary/server/doc/protocol-binary.txt

opcodeが1バイトなので要素256個の配列で命令実行ルーチンが書ける。デコードのコストは表引きだ。これがASCIIテキストだとstrcmp(command,"hogehoge")みたいなものを延々コマンドの数だけ書くはめになって、コマンドの数に比例したデコードコストがかかったりする。(まあパーフェクトハッシュ関数とか書けばいいのだがカジュアルに命令を追加したりとかはいろいろ面倒なので、結局はstrcmpで延々比較という泥仕事になる)

opcodeを固定長にするというのは王道中の王道のテクニックである。CISCに対するRISC的なアプローチと言ってもさしつかえない。

まあ、そんなことを思ったのだが、この手の古典的な高速化のテクニックというのは昔からずうっと変化していなくて、再発見、再発明が延々繰替えされているような気もする。

温故知新なのである。

でもって現在の実装についてちゃんとoprofileとかでミクロのプロファイリングを取って、チューニングをはじめたという事ではなく、なんとなく直観でぐわっとやっているらしい。まあ、それでもいいっちゃいいのだけど、ちゃんとベンチマークを定義して、oprofileなどでプロファイリングをして、ボトルネックを数字で示し、チューニング大会をするというのが正しい大人の姿である。

いろいろ設定準備とか大変だとは思うが、一度そのような環境を構築してしまえば、開発の最中、運用時等々貴重なデータを入手でき、パフォーマンスデバッグ(チューニング)のインフラになる。開発のプロセスに組込むというお作法は重要だ。なかなか実践するのは難しいが。

プロファイリングしてチューニングをする。王道中の王道だ。

まあ、こーゆーことをお酒を飲みながら、わいわいがやがや語るというのも勉強会の醍醐味でもある。

おまけ：

ソースコードはgithubで公開されているのでためしにゲットしてみた。

$ time git-clone git://github.com/tmaesaka/memcached.git
Initialized empty Git repository in /proj/memcached/.git/
remote: Counting objects: 1602, done.
remote: Compressing objects: 100% (472/472), done.
remote: Total 1602 (delta 1161), reused 1537 (delta 1108)
Receiving objects: 100% (1602/1602), 592.77 KiB | 237 KiB/s, done.
Resolving deltas: 100% (1161/1161), done.

real    0m4.901s
user    0m0.612s
sys    0m0.084s

memcached.c の dispatch_bin_command() はバイナリプロトコルのディスパッチルーチンであるが、だめじゃん。

switch(c->cmd) {
    case PROTOCOL_BINARY_CMD_VERSION:
略
とかしている。ここは表引きだろう。しかもc->cmdの定義はuint8_tではない。だめじゃん。深入りしないことにした。

プログラマ一年生のパッチと大物ハッカーのコード

「取締役退任。生涯一プログラマ宣言。」には大変な反響をいただいた。ここに記して御礼の気持ちとさせて頂く。トラックバック、ブックマークコメントなど可能な限り読んだ。過分のおほめ、励ましの言葉にあずかり、大変光栄に思う一方で厳しいお言葉も頂戴し皆様のご期待にそうよう一層精進していきたいと思った。

さて、プログラマ一年生である。最近では、MID (Mobile Internet Device)の開発にいそしんでいる。CPUもIntel Centrino Atomプロセッサだ。

ソフィアシステムズ Peartree用OS Asianux Mobile Midinux 2.5Jである。
http://www.sophia-systems.co.jp/ice/intel/Atom/PEARTREE/

インストーラを作っているのだが、先日ブートローダ(syslinux/extlinux)のバグに遭遇しそれを直すパッチを作成した。メーリングリストに報告したのが、7/2 18:35:14 PDT(米国西海岸夏時間)である。それに対する返事が、同日19:57:02 PDT(米国西海岸夏時間)、一時間ちょっとで、さっそく取り込んでくれた。その返事も素早いが、それだけではなく、リファクタリング(コードの改良)もしてくれた。

So it does (although the *real* problem is the lack of the stat and
device number comparison.)  I just applied a (slightly different) patch
to this and pushed it out as 3.71-pre3; could you try it out?

よしおかの超訳：バグだね(本当の問題はstatと装置番号の比較がなかった事だけど)。この問題に対するパッチ(ちょっと変更したコード)を適用し、それを3.71-pre3にいれておいた。試してみてくれる？

バグのあったコードは下記の部分である。細かい理解は必要ない。単にパターンマッチをして、上のif文と下のif文が対称じゃないことがわかればいい。

  if ( (mtab = setmntent("/proc/mounts", "r")) ) {
    while ( (mnt = getmntent(mtab)) ) {
      if ( (!strcmp(mnt->mnt_type, "ext2") ||
            !strcmp(mnt->mnt_type, "ext3")) &&
           !stat(mnt->mnt_fsname, &dst) &&
           dst.st_rdev == st.st_dev ) {
        devname = mnt->mnt_fsname;
        break;
      }
    }
  }

  if ( !devname ) {
    /* Didn't find it in /proc/mounts, try /etc/mtab */
    if ( (mtab = setmntent("/etc/mtab", "r")) ) {
      while ( (mnt = getmntent(mtab)) ) {
        devname = mnt->mnt_fsname;
        break;
      }
    }
  }

マウントされているファイルシステムのうち、ext2/ext3ファイルシステムを検索しているのであるが、上の部分は/proc/mountsで検索し、それがみつからなければ/etc/mtabで検索している。コードをじっくり眺めてみれば、下の部分のwhile(){...}で

      if ( (!strcmp(mnt->mnt_type, "ext2") ||
            !strcmp(mnt->mnt_type, "ext3")) &&
           !stat(mnt->mnt_fsname, &dst) &&
           dst.st_rdev == st.st_dev ) {

という比較がすっぽり抜けおちている。まあ、わかってしまえばトリビアなバグなのであるが現象としては謎であった。

なので、さっそくquick and dirty hackで下記のパッチを先のメーリングリストに投げたのである。

--- extlinux.c.orig    2007-02-10 20:47:08.000000000 +0000
+++ extlinux.c    2008-07-02 15:20:20.000000000 +0000
@@ -708,8 +708,13 @@
     /* Didn't find it in /proc/mounts, try /etc/mtab */
     if ( (mtab = setmntent("/etc/mtab", "r")) ) {
       while ( (mnt = getmntent(mtab)) ) {
-    devname = mnt->mnt_fsname;
-    break;
+        if ( (!strcmp(mnt->mnt_type, "ext2") ||
+              !strcmp(mnt->mnt_type, "ext3")) &&
+             !stat(mnt->mnt_fsname, &dst) &&
+             dst.st_rdev == st.st_dev ) {
+       devname = mnt->mnt_fsname;
+      break;
+    }
       }
     }
   }

7行追加のパッチである。まあ、素人目にはこれで一件落着である。

個人的には、ソフトウェア変更における、修正量最小化の法則、修正個所局所化の法則にのっとっているので、美しくはないかもいれないが、quick and dirty hackとしては合格点かと思った。

メンテナのちょっと変更したパッチというのが下記だ。

diff --git a/extlinux/main.c b/extlinux/main.c
index 0edce5a..819f74b 100644 (file)
--- a/extlinux/main.c
+++ b/extlinux/main.c
@@ -801,6 +801,32 @@ static int validate_device(const char *path, int devfd)
   return (pst.st_dev == dst.st_rdev) ? 0 : -1;
}

+#ifndef __KLIBC__
+static const char *find_device(const char *mtab_file, dev_t dev)
+{
+  struct mntent *mnt;
+  struct stat dst;
+  FILE *mtab;
+  const char *devname = NULL;
+
+  mtab = setmntent(mtab_file, "r");
+  if (!mtab)
+    return NULL;
+ 
+  while ( (mnt = getmntent(mtab)) ) {
+    if ( (!strcmp(mnt->mnt_type, "ext2") ||
+         !strcmp(mnt->mnt_type, "ext3")) &&
+        !stat(mnt->mnt_fsname, &dst) && dst.st_rdev == dev ) {
+      devname = strdup(mnt->mnt_fsname);
+      break;
+    }
+  }
+  endmntent(mtab);
+
+  return devname;
+}
+#endif
+
int
install_loader(const char *path, int update_only)
{
@@ -808,11 +834,6 @@ install_loader(const char *path, int update_only)
   int devfd, rv;
   const char *devname = NULL;
   struct statfs sfs;
-#ifndef __KLIBC__
-  struct mntent *mnt = NULL;
-  struct stat dst;
-  FILE *mtab;
-#endif

   if ( stat(path, &st) || !S_ISDIR(st.st_mode) ) {
     fprintf(stderr, "%s: Not a directory: %s\n", program, path);
@@ -848,35 +869,17 @@ install_loader(const char *path, int update_only)

#else

-  if ( (mtab = setmntent("/proc/mounts", "r")) ) {
-    while ( (mnt = getmntent(mtab)) ) {
-      if ( (!strcmp(mnt->mnt_type, "ext2") ||
-           !strcmp(mnt->mnt_type, "ext3")) &&
-          !stat(mnt->mnt_fsname, &dst) &&
-          dst.st_rdev == st.st_dev ) {
-       devname = mnt->mnt_fsname;
-       break;
-      }
-    }
-  }
-
-  if ( !devname ) {
+  devname = find_device("/proc/mounts", st.st_dev);
+  if (!devname) {
     /* Didn't find it in /proc/mounts, try /etc/mtab */
-    if ( (mtab = setmntent("/etc/mtab", "r")) ) {
-      while ( (mnt = getmntent(mtab)) ) {
-       devname = mnt->mnt_fsname;
-       break;
-      }
-    }
+    devname = find_device("/etc/mtab", st.st_dev);
   }
-
-  if ( !devname ) {
+  if (!devname) {
     fprintf(stderr, "%s: cannot find device for path %s\n", program, path);
     return 1;
   }

   fprintf(stderr, "%s is device %s\n", path, devname);
-
#endif

   if ( (devfd = open(devname, O_RDWR|O_SYNC)) < 0 ) {

ちょっとどころの騒ぎではない。全面改訂。随分コード量が増えている。

元のコードでは、if文でext2/ext3の比較をくりかえしていたのを、ばっさりカットして、find_device()という関数にまとめた。

そのおかげで、下記のように本体はすっきりした。

  devname = find_device("/proc/mounts", st.st_dev);
  if (!devname) {
    /* Didn't find it in /proc/mounts, try /etc/mtab */
    devname = find_device("/etc/mtab", st.st_dev);
  }

繰り返しをまとめるという基本中の基本である。ext2/ext3への比較などはfind_device()という新規に作った関数に閉じこめている。すっきりリファクタリングである。

syslinux一年生のコードをリファクタリングまでしてとりこんでくれたのである。

わたしは、著者のH. Peter Anvin (超大物カーネルハッカー)に会ったことも話したこともない。彼は、見ず知らずのどこの馬の骨ともわからない人間のパッチを軽やかに咀嚼して取り込んだのである。

ここまで一時間ちょっと。

オープンソースそしてバザールモデルというのはとてつもないソフトウェア開発方法論である。

まだまだ学ぶ機会に満ちている。素晴しいではないか。愉快ではないか。

gitによるコード。http://git.kernel.org/?p=boot/syslinux/syslinux.git;a=blobdiff;f=extlinux/main.c;h=819f74b5308bac7540fcdb580f94f93cde28d82e;hp=0edce5a597b65dfeb04764aa84582ce1e18dcfd7;hb=537164d509a4227416f6ac5b44c0030d6c79cb41;hpb=2b7251b3905e58ef5c34bb4b009ae537eb1b9333

メーリングリストでのやりとり。http://syslinux.zytor.com/archives/2008-July/010245.html
http://syslinux.zytor.com/archives/2008-July/010247.html

Googleを支える技術

Googleという不思議なサービスを提供するそのコンピュータシステムの内側に公開された資料だけを利用して迫った良書である。

Internetの向う側のGoogleというシステムについて、われわれは日々利用しているにもかかわらず殆ど何も知らない。少なくともわたしは技術的な側面について殆ど何も知らない。神秘的な、都市伝説的なもの、例えば、20%ルールとか、そんなことぐらいしか寡聞にして知らない。

本書はGoogleの分散ストレージ(GFS/BigTable/Chubby)、分散データ処理(MapReduce/Sawzall)、運用コスト、開発体制などについて公開された論文などを引きながら解説している。

コンピュータシステムというのは極論すれば、いかに速くするか、いかに安くするかという2軸で発展してきたようなものだから、Googleという巨大システムをどのようにエンジニアリングするかという観点からもこの速くすること、安くすることの実務的な教訓というのは大変興味深い。

RDBMS(関係データベース管理システム)というソフトウェアは多量なデータをいかに格納し、検索するかという観点から開発発展してきたものだが、Googleは、それを地球規模の巨大システムに実装したものと言える。

わたしが本書で最も興味を引かれたものは、分散ストレージや分散データ処理の話ではなく、運用コストの章であった。そしてわたしはこの章が本書の最もユニークなところでしかも最も重要なところかと思う。

フツーのプログラマが計算コストと言うときアルゴリズムの計算量の事を指す場合がおおいと思うが、計算にいくらかかっているかという観点から議論するということは、あまりないと思う。

ムーアの法則のすごいところは、18ヶ月で半導体の集積度は倍になる、すなわちコストが半分になると言い切って、フツーのプログラマにそれを意識させたことである。コストが半分になるのだから、それを意識したプログラミング、すなわちメモリがどんどん増えていく、あるいはメモリがどんどん安くなることを前提としたプログラミングが正しいこととされた。そのようなパラダイムでソフトウェアサイエンスは進化していったようなものである。

コンピュータの高速化の流れも、ムーアの法則にのとって、クロックを高速化する事によって、命令セットアーキテクチャを変更する事なく、様々な実装上の工夫によって、高速化していった。ソフトウェアにとっては、ほとんど何もしないで高速化していったわけであるから楽な時代であったと言える。

ところがクロックをどんどん上げて行くことによって、電力消費量もそれに比例してどんどん増加していって、発熱の問題などが顕在化してきた。そこで、クロックを上げることによる高速化ではなく、マルチコア化等による高速化などが必要になってきた。同様に消費電力あたりの性能を上げるための様々な工夫が必要になってきた(←今ここ)

計算機の消費電力は電気代というお金になる。Googleが利用している計算機は、2000ドル〜3000ドル程度の普通のIAマシンのようであるが、その消費電力が増加の一途をたどり、年間運用コストがそれを上まわるかどうかという事である。

電気代だけではなくてデータセンターの建設費、効率的な電力消費設計などがコスト負担にどんどかかってくる。プログラマは昔はムーアの法則をメモリ空間の増大などと一次元的に考えていればよかったが、今後はメモリ空間はまあそこそこあるとして、消費電力をどう効率的に利用するか、省電力プログラミングが求められてきているような気がする。

消費電力を半分にできれば運用コスト(電気代)は半分になるし、ばかでかいデータセンターの建設も先送りにできる。サーバー機の重要なコストファクタが電気代というのが常識になってくるとプログラマのプログラミングパラダイムも随分変化してくる。

速くするだけではなく、電気代を節約する速さが求められるのである。

モバイル機器なんかは電池の持ちが商品価値そのものを決めたりするので、もっと重要である。バッテリーのサイズが半分になればデザインの自由度も随分増すだろうし、なにより軽くできるし、ハードウェアコストも安くできる。プログラムが物理的なデザインに影響を与えるのである。

プログラマがもっとコストなどの側面に意識を持つべきだと思うのだが、その意味で本書の第5章などは大変興味深くかつ意義深いと思う。

省電力プログラミングというパラダイムをそろそろ真面目に考えないといけない時期である。

Googleを支える技術 ……巨大システムの内側の世界
サポートページ
http://gihyo.jp/book/2008/978-4-7741-3432-1/support

Happy Hacking Diary(著者：西田圭介氏の日記)
http://d.hatena.ne.jp/nishidakeisuke/20080428

Papers Written by Googlers
http://research.google.com/pubs/papers.html

未来のいつか/hyoshiokの日記(電気代)
http://d.hatena.ne.jp/hyoshiok/searchdiary?word=%c5%c5%b5%a4%c2%e5

未来のいつか/hyoshiokの日記(省電力)
http://d.hatena.ne.jp/hyoshiok/searchdiary?word=%be%ca%c5%c5%ce%cf

勉強をしなおす

いくつになっても勉強だ。昔とった杵柄。錆びたナイフを研ぐ。

という事で日頃なにげなく使っているEmacsのマニュアルを再読する事にした。会社の机の上にO'reillyの Learning GNU Emacs、Writing GNU Emacs Extensionsそして竹内監訳のGNU Emacsマニュアルがある。竹内監訳のGNU Emacsマニュアルの初版は1988年2月である。20年前である。いくら何でも日進月歩、秒進分歩のIT業界の時間感覚でなくても古すぎるだろうと思わなくもないが、機能がテンコ盛のEmacsにはversion 18ころの古典的な、基本機能をおさらいするには、サイズ的にも丁度いい感じである。

正直に告白すると、Emacsを日々使っているが自分で拡張を書いたりelispで手間仕事をちゃかちゃか片付けるという事はほとんどしていない。何かのきっかけでもないとマニュアルを読みかえすということもほとんどしない。ぐぐればどーにかなる。だけど、一見時間がかかると思えても基本にたちかえってみることは悪い事ではない。

今使っているEmacsは22.1.1だ。Ubuntu 8.04にデフォルトでついてくるやつである。10数年Emacsを使っているけど全然使いこなしている感じがしない。ちゃんと基本にもどって勉強しなおしてみよう。きっと新しい地平線が見てくるに違いない。

ソフトウェアの作り方を考える

「開発工程を別々に担当してはいけない」は思いのほか多数のブックマークを頂いた。コメントやブックマークを拝見しながらあれやこれや考えた。わたしの飛躍する思考というか雑な議論で辟易している方もいらっしゃるかとは思うがもう少しお付き合いいただければ幸いである。

わたしの経験は、このブログの読者の皆さんはご存知かもしれないが、ソフトウェア製品の開発経験に偏っている。米国系ハードウェアベンダーでコンパイラやRDBMS製品を開発していた。その後西海岸のソフトウェアベンダーに転職してそこでRDBMS製品の開発に従事した。そしてOSSの可能性を信じてミラクル・リナックスの設立に参加したのが約7年前である。顧客向けアプリケーション、例えば社内システム構築（人事、財務、購買などなど）の経験はない。

さて先の「開発工程を別々に担当してはいけない」ではいろいろな論点をごった煮風に突っ込んだものだから分かりにくくなったので、いくつか細かく分けて考えてみる。

人月のワナ。

多くの人が指摘しているようにソフトウェアの価値をかかった工数（人月）で評価するというのはまるっきりナンセンスである。熟練者が一ヶ月で作成できるものを初心者が6ヶ月かかったとすると、後者に6倍お金が払われるか、それだけの価値があるか。もちろんない。

この場合の正しくは、ある実装した価値、通常は機能で近似するかと思うのだけど、それに見合った価格が支払われるべきである。単位機能を実装する工数が少なければ少ないほど、利益があがるので、ソフトウェア開発における生産性向上のインセンティブが発生する。人がソフトウェアを作る以上、一人一人の専門性、技術を向上させることに高いインセンティブが発生する。企業にとっても、未経験者（安い人材）を雇用し、その利ざやで稼ぐのではなく、より専門性の高い人間を雇用し、その生産性の高さで利益をあげることに、そして教育やトレーニングに投資すること（生産性や品質の向上に繋がる）に合理性が発生する。

ソフトウェアである機能を実装するために、設計、プログラミング、テストという工程があったとして、それを工程ごとに分離して、それぞれを単能化することによって生産性を向上するという、古典的な工場モデルがソフトウェア生産に適用可能なのか。ひたすらネジを取り付けるだけの自動車工場なんていうのがいまどきありうるのか。ソフトウェアの設計とプログラミングそしてテストというのがそもそも分離可能な工程なのか？

わたしは、そのような工程を単純に分離することは難しいし、分離することは専門性を高めることには繋がらないと思っている。分離することによって、生産性が向上するという証拠もほとんどみたことがない。ソフトウェアを実装する能力を高めるためには、渾然一体のプロセスである、設計、プログラミング、テストを等しく経験しなければならないと考えている。その経験を積むことによって一人一人の専門性すなわち生産性が向上していくと考えている。

テストとプログラミングをするものは分けるべきだと言う議論ももちろんあるが、ここでいうテストは実装の妥当性を評価するいわゆる内部テストに相当する部分で、仕様の妥当性を検証する統合テストあるいは受け入れテストのところではない。昨今ではテスト駆動型開発という手法で広く取り入れられている方式である。

ということで、工程分離することによって生産性が向上するという可能性が少ない、むしろ悪化すると考えている。一方で機能による分離では生産性向上がみこめると考えている。

ITゼネコンうんぬんかんぬんはまた別のお話なのでいつの日か別にお話することにしたい。

開発工程を別々に担当してはいけない

古典的なウォータフォールモデルでは、ソフトウェア開発を要求仕様分析、概要設計、詳細設計、実装(コーディング)、内部テスト、統合テスト、運用、保守みたいな工程にわけ、通常は各工程を別々の人が担当するというような方法がよくおこなわれている。

特に、要求仕様の分析、概要設計などは上流工程などとよばれていて、詳細設計、実装とは別の人ないしは組織が担当する。実装とかテストは下流工程などとよばれている。

よくあるパターンとしては元請けが上流工程を、下請け、孫請けが実装やテストなどを担当し、人月単価も下流の方が安い。

ウォーターフォールモデルでは各工程毎に成果物(仕様書や各種ドキュメント、プログラム)が大量に生産される。各フェーズ毎に定義された成果物がそろってから次のフェーズに移行するというのが建前なので、各フェーズでのドキュメントはどうしても冗長になりがちである。

一度固定した文書は次のフェーズで変更するとなると、手戻り工数が莫大になってしまうので、通常は、前工程で決めたことは、後工程で変更はしない。後工程で変更しないという前提で文書を作るので、いろいろ長期間にわたって検討などをするのであるが、実装してみないとわからない事などもいっぱいあるので、なかなかそうは上手くいかない。

実装してみて、できたものは最終ユーザからみると使えないものでも、仕様書に明記されていたものをその通りつくっている限り実装者(製造)の責任ではない。

大量な文書を作るし、各フェーズのレビューの工数も重いので開発スピードは遅くなりがちで、当初予定していた利用環境やユーザの要求というのも時間とともに変化するので、実装が終了した時点では仕様そのものが陳腐化するという事もすくなくない。ひらたく言うと、一生懸命つくっていたのに使えないものができてしまったということである。

ユーザアプリ開発、SI(System Integration)の現場では、おおかれすくなかれ上記のようなパターンがあって、それに元請け、下請けという産業構図がはめこまれていて、元請けが大手ベンダー、下請け、孫請けが中小ベンダーという風になっていたりする。大手がゼネコンの立場になって、多くの下請け、孫請けを使って大規模システムを構築する場合、いろいろな意味あいを含めてITゼネコンといったりする。

工程を別々に担当することによって、数々の問題が発生する。

通常は上流の方が単価が高く、下流の方が単価が安いので、だれも下流をやりたがらない。下流工程は結果として単価の安い経験の浅いエンジニアをつけることになる。工程は通常、組織によってわぎりにされているので、下流工程の作業をやる人がノウハウをためて上流作業をになうという機会がない。元請けはいつまでたっても元請けだし、孫請けはいつまでたっても孫請けである。孫請けの経営者も経営者で、単価は安くても、とりあえず人の分だけ売上があがるので、大手にぶらさがっていれば食いっぱぐれない。そのため経営の緊張感はない。利益率は低いがどうにか食っていける。というような構造がある。

下流にいけばいくほど単価のたたきあいになるので経験豊富なベテランを配置することが難しくなり、若年層エンジニアを使いすてることにならざるをえない。いわゆる35歳停年説である。

業界全体としてエンジニアを使い捨てにすることには百害あって一利もない。にもかかわらず、抜本的な対策、方策がとられているようには見えない。

なぜなんだろう。

わたしには、この工程によって作業を分担するという方法が諸悪の根源であるように思えてならない。小さい会社が何十人もエンジニアを集められないので元請けになれないという事情があるというのは百歩譲ってあるとしよう。大規模な開発をするため何社かで共同作業が必要だったとしよう。その場合の分担を工程ごとに輪切りにするのではなく、機能ごとに縦に切る事を提案したい。

つまり、ある機能について、一社ないしは一人が仕様の決定から設計、実装、内部テストまで担当するのである。キモは設計者と実装者は同一人物とするのである。これを分離しない。

なんでこんなことを言うかというと、実装と設計は不可分で、実装をしてみて初めて気がつくこと、設計をしてみて初めて気がつくことなどがあり、実際の設計と実装というのはいきつもどりつのプロセスである。このいきつもどりつがない限り、いい実装などはできはしない。設計と実装を分断している限り、しょぼい設計としょぼい実装にしかならない。初めから完璧な設計などはないのである。完璧な設計でない以上、しょぼい実装しかうまれてこないのである。

工程を分離するのは悪なのである。

工程を分離するために専門性が蓄積されない。より高度な実装を作成するインセンティブも発生しない。

『「渡された仕様書を実装するサラリーマンプログラマ」の悲哀』にあるのは工程を分離されたプロジェクトの悲哀であって、サラリーマンかどうかは無関係である。

わたしはソフトウェア工場というコンセプトそのものを否定するつもりは毛頭ない。工学的なアプローチによってより品質の高い(バグ密度の低い)ソフトウェアをより少ない工数で生産するということは可能であると思う。QC活動のような方法論ですら有効な場面は少なくないと思う。

しかしXPで実践されているようなベストプラクティスの多くは工程の分離ではなく設計と実装の渾然一体となったプロセスである。

日本のソフトウェア開発の現場の国際競争力のなさというのがあるとしたら、ITゼネコンをよしとした、上流下流工程を是認したソフトウェア生産方法論にあるのではないか。そこに構造的な問題があるのではないかと思うのである。人月で工数をはかる事がやりだまにあがっているが、根本的な問題は、工程を分離して、下請けにだすというソフトウェア生産方法であると思う。

ちなみに、米国のソフトウェア製造業では(マイクロソフトもオラクルも)、設計する人がコードも書くのである。それが一般的な姿である。わたしの場合(DEC時代もオラクルの時)も、そうであった。

プログラマの仕事はプログラムを読むことである/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/10/post_9db7.html

Intelのマニュアルを読む

Intel 64 and IA-32 Architectures Software Developer's Manuals　は下記にある。
http://www.intel.com/products/processor/manuals/index.htm

どれから読んだらいいか、よく分からないということであれば、 Volume 1: Basic Architectureをざっと見て、 Volume 3A: System Programming Guideに行くというのがオーソドックスかと思う。インストラクションセットの解説（ Volume 2A/2B）は辞書的に必要な命令について適宜参照するという形になる。

マイクロアーキテクチャについてざっくり知りたい場合は、Intel 64 and IA-32 Architectures Optimization Reference Manualの第2章がコンパクトにまとまっている。

最近のCoreマイクロアーキテクチャやPentium 4やXeonのNetBurstマイクロアーキテクチャについて紹介されている。

Coreマイクロアーキテクチャのところを読むと、In Orderのフロントエンドが4つの命令デコーダが、命令をμOPに変換し、Out of Orderの実行コアに送り、サイクル当たり6個のμOPを実行し、In OrderリタイアメントユニットがμOPの実行結果をサイクル当たり4つプログラム順に変換する。なんてことが書いてある。

14段のパイプライン、3つのALUなどなど。

フロントエンドには、BPU(Branch Prediction Unit)、Instruction Fetch Unit、Instruction Queue、Instruction Decoder、Stack Pointer Tracker、Micro-fusionなどの機能がある。機械語をμOPにサイクル当たり4つ変換する。

実行コアはフロントエンドから供給されるμOPをOut of Orderで実行する。renamerによって、レジスタ名を大量にあるマイクロアーキテクチャの内部レジスタ名に変換する。（いくつ内部レジスタがあるかは記されていない）。Reorder buffer (ROB)はμOP実行結果を保持する。ROBは96個のエントリを持つ。Reservation Station (RS)はμOPのすべてのソースオペランドがそろうまでキューに並べスケジュールする。RSは32個のエントリを持つ。

実行コアがサイクル当たり最大6個のμOPを同時に実行するというようなことが書いてある。その他メモリアクセスをどのように高速化しているかなど興味深いお話満載である。ぜひ原文にあたって欲しい。

wired society

3連休でブログネタも尽きたことだしなにを書くかなどと考えていて、趣味のインテルのマニュアルを読んでいたところ、割り込みと例外の章（Intel 64 and IA-32 Architectures Software Developer's Manual Volume 3A: System Programming Guide, Part 1）をたまたまめくっていたのでそれについて書こうかなと思ったのだが、急に気が変わる。

昔ウェブ人間論を読んだ時に書いた感想をたまたま読んで、ああ、インターネットは人々と結線(wired)したのだなあなどと再確認した。http://blog.miraclelinux.com/yume/2006/12/post_2666.html

Wiredという雑誌があったけど（今もあるのかな？）、日本語版も出ていたがいつのまにかになくなってしまった、インターネットは我々を結線したというのが非常にインパクトがある概念だった。

世界がインターネットで繋がっている。

すげーぞ、それはというワクワク感であった。

ハッカーがなぜプログラムを書くかという問いかけに私自身まだ明確な回答は持たない。持たないが、自らの自由意志でプログラムを書く多くのハッカーを知っている。給与を貰うプロのハッカーから100％自由意志で誰からも拘束されないでコードを書くハッカーまで様々な人たちがいることを私は知っている。

なぜハッカーはプログラムを書くのか。

21世紀の謎である。しかし、インターネットのおかげで彼らはインターネットに結集した。インターネットは彼らを結線した。

それによってとてつもない価値の再生産が始まった。

結線された社会はそうでない社会よりも幸せなのか。ハッカーはその社会にどのような役割を演じるのか。

疑問はつきない。









下記はボツにした原稿。もったいないのでそのうち使うかもしれない。

割り込みは現在実行中のプロセスとは独立に発生する。例外は現在のプロセスの実行によって引き起こされる。例えばゼロ除算とかページフォルトとかは例外である。

割り込みも例外も発生するとそれに対応したハンドラを起動し様々な処理を行なう。例外の場合、ゼロ除算とかは当該プロセスに通知して実行を終了するものから、ページフォルトのようにOSによって適切に処理されるものまで様々なものがある。

IA-32の場合は、おなじみの下記のマニュアルの第5章を参照のこと。

Intel 64 and IA-32 Architectures Software Developer's Manual Volume 3A: System Programming Guide, Part 1
http://www.intel.com/products/processor/manuals/index.htm

リアルタイム系OSの場合、割り込み処理を一定時間で処理することを保証しなければいけないのでなかなか大変である。

Latencyの隠蔽

プログラマたるものコンピュータの基礎的な知識は必要だと多くの人は言うのだけど、じゃあどこまでが必須でどこまでがオプション（？）なのかというと明確な線引きがあるわけではない。まあ、Kernelとかコンパイラとかをゴニョゴニョする人はCPUのキャッシュがなんたるかくらいは理解していないといろいろ大変かと思う。

時間と空間を交換するというのはコンピュータだけの世界ではない。街のコンビニだって、店頭に並んでいるものはすぐにアクセスできるけど、店頭にないものはすぐにアクセスできないので、在庫量がある一定水準を下回ったら発注のトリガーがかかる。コンビニはその発注サイクルがデパートとかに比べれば異様に多いので、クロックを上げて性能を出すPentium4みたいなものである。発注単位も非常に小さくて、それこそ弁当一個でも平気で発注しちゃうという感じである。在庫をほとんど持たないので、キャッシュミスした時のペナルティは、そのまま機会損失である。倉庫のようなディスカウントストアもあるが、そちらの発注単位はでかくて、大きな空間が必要なので土地のコストが安い郊外に立地している。

アクセスコストとメモリコストの差に注目して記憶領域を階層化するのは、CPUキャッシュだけではなく、メインメモリとディスクキャッシュなどでも行われている。

CPUのレジスタとメインメモリアクセスの速度は100倍くらい違うので、性能を意識する場合CPUキャッシュがどのようなメカニズムで働いているかを十分理解しないといけない。

メモリアクセスは遅い(ユメのチカラ)で指摘したとおり、メモリアクセスが遅いことを前提にいろいろなチューニング方式が考えられるが、一番単純なのは、プリフェッチである。

順アクセスの場合、次にアクセスされる番地が予想できるので、その番地にあらかじめアクセスしておく。そうすれば実際にそのデータが必要になったときにはキャッシュでのアクセスになるので、メモリアクセスを待つと言うことはない。例えばメモリアクセスに200クロックかかっていて、L1キャッシュのアクセスが2クロックだったとすると、L1キャッシュヒットだと残りの198クロックを無駄に待つ必要がないのでより高速な処理ができる。

あるメモリにどのようにアクセスするかはプログラムを書いた人が知っているはずなので、プログラマが陽にヒントとして与えてもいいし、コンパイラがそれを何らかの方法で認識し、積極的にプリフェッチをかけるというのもある。

最近のプロセッサだとメモリアクセスのパターンを見て、順アクセスを検知すると自動的にプリフェッチをする場合もある。投機的なメモリアクセスである。

あらかじめ準備をしておくというのがlatency隠蔽の基本的な考え方である。

もう一つの方法は、時間がかかる処理と並行して、別の処理を実行するというもので、直列に処理をすすめると、長いlatencyを持つものを待たないといけないので、スループットが上がらない。そこで並列に処理できるものをどんどん処理していくという考え方である。

入出力もlatencyが大きいので、入出力と並行して別の処理をするというものである。

スーパースカラなプロセッサは同時に複数の命令を処理するので、そーやって、スループットを向上させたり、latencyを隠蔽したりする。

Computer Architecture: A Quantitative Approach（David A. Patterson, John L. Hennessy ）を読んで、基本的な概念をおさらいしたいところである。(下記）

機械語ではマシンの挙動は理解できない。(未来のいつか/hyoshiokの日記）
http://d.hatena.ne.jp/hyoshiok/20070916#p1

山勘で分岐先を実行することを投機的実行と呼ぶ（ユメのチカラ）
http://blog.miraclelinux.com/yume/2007/09/post_6814.html

Model View Controller

Smalltalkでの実装が元祖とされているが、データと手続きをつかさどるModel、表示をつかさどるView、ユーザーの入力（イベント）を処理するControllerという要素に分離し設計実装するソフトウェアモデルである。

Web系のアプリケーションの設計では定番のパターン。

正直言うと、そっち方面の経験も土地勘も乏しいので理屈の上ではわかっていても自分の血となり肉となっている感じはしない。

メモリアクセスは遅い

多くのプログラマにとってメモリアクセスの速度を気しなければならない状況というのはめったに無いが、OS、ライブラリ、コンパイラ、RDBMSなどの実装をする時には意識をしなければならない場合がある。

IA-32 Intel Architecture Optimization Reference Manual (order number 248966) をひもとくと6章にOptimizing Cache Usageというのがある。

マイクロベンマークの定番 lmbench http://www.bitmover.com/lmbench/ では、一次キャッシュ(L1)や二次キャッシュ(L2)を測定してくれる。例えば、わたしが利用しているノートだと、L1が1.776nsでL2が5.3490ns、メインメモリアクセスが139.4nsである。

Memory latencies in nanoseconds - smaller is better
    (WARNING - may not be correct, check graphs)
---------------------------------------------------
Host                 OS   Mhz  L1 $   L2 $    Main mem    Guesses
--------- -------------  ---- ----- ------    --------    -------
asianux2. Linux 2.6.9-3  1700 1.776 5.3490  139.4

クロック数でいうと、L1が3クロック、L2が9クロック、メインメモリが237クロックくらいになる。

L1とメインメモリでは2桁のアクセス速度の差がある。CPUのクロックはムーアの法則によって18ヶ月で倍になると言われていたが、その間のメモリ速度の向上は数%で、年々そのギャップは広がる傾向にある。

近年、性能向上のためのクロック数の向上は消費電力の上昇をまねいたため、性能向上のためにはクロック向上ではなくコア数の増加という傾向になりつつある。それにしても、CPUの速度向上にくらべてメモリ速度の向上ペースは低いので、そのギャップの拡大はおわっていない。

昔はCPUのクロックと同じ速度でメモリにアクセスできたが、現状では100倍程度遅いことを覚悟しないといけない。

性能を極限まで追及する時には、そのキャッシュの振舞いを理解する必要がある。リストをたぐるような操作はアドレスが連続していないので最悪毎回キャッシュミスをひきおこし、メインメモリにアクセスする必要が生じる。従って速度が2桁遅くなる。一方配列を順アクセスする場合は最初の一回はキャッシュミスをおこすがその後はキャッシュにデータがあるのでメインメモリにアクセスしなくてすむので高速な実行が可能になる。

リストやハッシュはキャッシュに厳しいが配列はキャッシュに優しい。

リスト処理の場合は次にアクセスするところ(nextポインタの指しているところ)が分るので、あらかじめプリフェッチをしておけばlatencyを隠蔽できる。

Rubyの RejectKaiji2007で発表したRubyのキャッシュミスを削減した話はキャッシュミスをプリフェッチで削減するというアイデアを実装したものである。

RejectKaigi2007
http://blog.miraclelinux.com/yume/2007/06/rejectkaigi2007.html

一方プリフェッチというのは今あるデータを追い出して新しいデータをキャッシュに置くという事であるから、追い出されたデータがすぐに必要になるとキャッシュミスを発生させる場合がある。これをcache pollution(キャシュ汚染)という。ページのスラッシングみたいなものである。なんでもかんでもプリフェッチをしてキャッシュにのせればいいというものでもない。

そのアイデアを元に作ったのがcache pollution aware patchである。

Linux Kernel 2.6.18とCache Pollution Aware Patch
http://blog.miraclelinux.com/yume/2006/09/linux_kernel_26_2c2c.html

CPUのクロック数の上昇は消費電力の増加をまねくのでマルチコア化が進展しているという事は先に記した。マルチコア化が進展するとプロセッサ間の同期をどうとるかがますます重要になってくる。その実装としてスピンロックがある。スピンロックはメインメモリにフラグを用意して、そのフラグをセットできたものがロックを取得でき、セットできなかったものはセットできるまでループで待つという単純な同期方式である。

あるフラグがセットされているかを毎回メインメモリに見にいくという処理は、バスをロックして、アトミックにそのフラグをセットできるかを確認することだから非常にコストがかかる。バスをロックするので他のCPUは別の場所にアクセスしようとしてもアクセクを待たされるのでスケーラビリティもでない。(100nsから200ns位メインメモリアクセスにはコストがかかることを思い出してほしい）

マルチコアになってキャッシュに優しいロック方式あるいはロックなしの同期方法が求められている所以である。

メモリアクセスにまつわるバイナリハックの場所はまだまだいっぱいある。

mixiのスケーラビリティ

mixiの生みの親“バタラ氏”が語るMySQLの意外な利用法

サービス開始から3年余りで会員数が1000万人を超えたSNSの「mixi」。そのシステムはOSSで構築されており、データベース管理システム（DBMS）には「MySQL」を使う。急増するトラフィックをさばくために負荷分散を重ねた結果、現在ではサーバ1000台以上が連なる超分散システムへ。その中でMySQLが果たす役割とは。http://techtarget.itmedia.co.jp/tt/news/0709/12/news01.html

という記事があった。

日記だけで4億件。サーバは1000台以上。アクティブユーザは6割を超える。すさまじい規模のサービスである。すべてOSSで構成されていて、自社開発のコードでサービスをささえる。

当初一人のユーザから始まったサービスも2ヵ月後には1万人を超え、さらに半年ほどでデータベースをサービスごとに分割（水平分割と呼んでいる）し負荷対策した。しかし1年4ヶ月で100万人を超える会員数の増加は、それだけでは持たず各種IDごとにテーブルを分割している。これを垂直分割と呼んでいるが、DBMS的にはテーブルを水平方向に切っているので水平分割と呼ぶのが正しい。垂直分割というのは通常は列を縦に切ることをいう。例えばあるテーブルに（ID、A、B、C）列があったとして、それをテーブル１（ID、A、B）、テーブル２（ID、C）などと分割することを垂直分割という。

それはさておき、ユメのチカラでもmixiのスケーラビリティは何度か取り上げた。昨年の7月第65回のカーネル読書会でバタラさんに発表してもらったときのレポートである。下記二つをあわせてお読みいただきたい。

５００万倍のスケーラビリティ
http://blog.miraclelinux.com/yume/2006/07/post_7ad0.html

システムを1ユーザから500万ユーザまで約2年半でスケールアップしたというお話で、苦労話満載の非常に興味深いものであった。様様な試行錯誤をへて現在のシステムにいたっているが、1ユーザから500万ものユーザをサポートするなどというスケーラビリティはあらかじめ設計されていたものではない。問題にぶつかるたびに一つ一つ問題を解決していって今に至るということである。この500万倍のスケールアップと言うのは本当にとてつもないことである。そのとてつもないことを飄々とこなしているバタラさんのお話が興味深かった。

LiveJournalのアーキテクチャ
http://blog.miraclelinux.com/yume/2006/07/livejournal_a718.html
こちらはmixiが利用している、mod_perlやmemcachedなどのコンポーネントの話で、それはLiveJournalと同様のアプローチである。

大規模Webサービスを提供するためには、様々なレイヤーでの経験が必要になって、ネットワーク、データベース、OSなどなどどんどん深堀をしていく必要がある。OSSの場合はすべてホワイトボックスなので、やろうと思えばいくらでも深堀をすることができる。それはサービス提供者にとっては価値を生み出す源泉となる。

フリーソフトウェアの価値観

80年代に消滅しかけたハッカー倫理を実現するコミュニティは、リチャード・ストールマンの孤軍奮闘ともいうべき活動によって細々とだが生き延びていた。

リチャード・ストールマンはソフトウェアは私有すべきではないという信念のもとFSF (Free Software Foundation)を立ち上げ、GNU (GNU's Not Unix)　というUnix互換のOSを作ろうとしていた。エディタ（emacs)、コンパイラ(gcc)、shell script (bash)、デバッガ(gdb) などなど様々なフリーソフトウェアを精力的に開発し、公開していった。

MITのAI研究所はLispマシンの商用化によって壊滅的な打撃をうけていた。優秀なハッカーたちは高給で商用Lispマシンベンダに雇用され、ソフトウェアの共有は、知的財産権の名の下に不可能になった。DECがPDP-10のサポート中止した結果、彼らのよりどころであるITSの未来も閉ざされた。

リチャード・ストールマンは占有ソフトウェアを書くくらいならウェイターにでもなったほうがましだ、だけどそれは自分の才能を浪費することになる、と後に語っている。

しかしながらリチャード・ストールマンの不屈の精神と努力によって80年代のGNUプロジェクトは着々と成果をあげていた。OSカーネルを除いては。

そして90年代Linuxが登場する。当時フリーのPC UnixといえばBSD Unixを移植した386BSDなどいくつかのライバルがいたことにはいたが、BSD陣営はAT&Tとの訴訟問題を抱えていたし、開発方式も、ごく少数のコアメンバーによる開発という従来型の方式で、爆発的に普及するまでにはいたらなかった。

Linuxはそれらのソフトウェアとまったく異なる手法で開発されている。Linuxの開発は、ごく初期の段階から、大勢のボランティアたちがインターネット上で共同作業する形で進められていった。誰かがすべてを監視するワンマン体制によって維持されていたわけでもない。Linuxカーネルのクオリティはリリースを毎週行い、数日中に寄せられてくる何百と言うフィードバックを素早く反映して次のリリースを行なうという無邪気なほどに単純なアップデートを頻繁に繰り返すことで維持されていったのである。このようにリリースを極めて頻繁に行なうことで、Linuxカーネルに次々と追加されたコードの善し悪しは、進化論的に淘汰されていった。そして、この開発方式が成功したことに驚かぬ者はいなかった。中略。真のプログラマたちが活動の場とするインターネットが社会の主流に躍り出たおかげで、彼らの文化そのものも表舞台でもてはやされるようになった。
（真のプログラマたちの国ーー概略史、オープンソースソフトウェア、倉骨彰訳）

リチャード・ストールマンのはじめたフリーソフトウェア運動はリーナス・トーバルズという若者ハッカーとインターネットの勃興によって新しい形で再出発したのである。彼は古きよき時代を知る最後のハッカーであったが、インターネット時代の最初のハッカーはリーナス・トーバルズと言ってもいいと思う。

ビル・ゲイツに代表される、ソフトウェアのコピーなんてとんでもない、独占的な所有権を持つことで、開発投資を回収し、利益を得て技術革新を促進するのだ、という考え方は、ビジネスモデルとしては非常に分かりやすく、結果として彼を世界一の金持ちにし、マイクロソフトを世界一のソフトウェア企業にした。

ソフトウェア商用化は結局のところハッカーにとっても大きな影響をあたえ、ソフトウェアの印税を貰って金持ちになるという誘惑に多くのハッカーたちは抗えなかった。80年代から90年代のソフトウェアベンチャーはビル・ゲイツモデルのコピーと言えるだろう。

しかしながらハッカー倫理に象徴的に語られている、情報公開が善で、コンピュータは世界を良く出来るという考え方は、人がなぜプログラムを作るのかという根源的な問いかけに、もちろん経済的な成功（金持ちになりたい）もあるにはあるけど、それ以外の動機もありうるのだということを示した点で興味深い。

Red Hatが株式公開をしたとき、梅田望夫は

レッドハットの勃興は、貪欲で力強い資本主義がオープンソースという怪物をもぐいっと飲み込んでしまった瞬間であった。「あどけない顔をした天才たち」は、あっと言う間に資本主義に飼いならされたのである。
資本主義に飼いならされたLinux。199ページ。シリコンバレー精神。梅田望夫

と記している。確かにフリーソフトウェアあるいはオープンソースが資本主義（ビル・ゲイツモデル）に飲み込まれたという空気もあった。

しかし、8年経ってみて、周りをみわたしてみると、情報公開は善で、コンピュータによって世界を変えてやるということを本気で思って実践している若きプログラマたちを沢山発見できる。

確かに彼らはリチャード・ストールマンほどフリーソフトウェアと声高には主張しないが、彼らは彼らが作ったプログラムによって世界になんらかのインパクトを与えることをモチベーションとしている。もちろん、経済的な動機が全くないといえばウソになるかもしれないが、それがトッププライオリティではない。

ビル・ゲイツに代表される知的財産権をたてにとったモデルと、フリーソフトウェア・オープンソースに代表されるハッカーモデルとで、どちらがより価値を継続的に生み出すのか。ハッカー的価値観を持った方法論というのが注目されている所以である。

先日開催されたITproチャレンジにはそのような若手ハッカーが集まっていたことを付記しておく。

ITpro Challengehttp://itpro.nikkeibp.co.jp/ev/challenge/index.html
http://itpro.nikkeibp.co.jp/article/Watcher/20070906/281310/

オープンソースソフトウェア　彼らはいかにしてビジネススタンダードになったのか
http://www.law.co.jp/okamura/OpenSource_Web_Version/Web_version991206.html
Web版は無償で公開されている。

第2章、真のプログラマたちの国―概略史、エリック・S・レイモンドを参照。

ハッカー倫理/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/09/post_972f.html

ビル・ゲイツの手紙/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/09/post_af17.html

ITpro Challenge/未来のいつか
http://d.hatena.ne.jp/hyoshiok/20070907#p2
ITpro Challengeその２/未来のいつか
http://d.hatena.ne.jp/hyoshiok/20070908#p2

ITPro Challenge無事終了/404 Blog Not Found
http://blog.livedoor.jp/dankogai/archives/50908309.html

チューニング

パフォーマンスチューニングというのも非常に重要な問題だ。黒魔術のようなかんじもしなくもないが、ヨタ話をいろいろ書いてみる。

性能の問題が表面化した場合、やみくもにパラメータをいじくりまわして問題を悪化させてしまう場合があるが、そーゆーことは避けたい。

何が問題なのか、定量的なゴールを明確化しないと、単なる感覚論になってしまって不毛な時間をついやすことになるので注意が必要である。

パフォーマンスチューニングの参考書はいろいろあると思うので適宜みつけだしてほしいが定番のこれはというのは、あるようでいてよくわからない。データベースのチューニングという題材での書籍はいろいろあるがいかんせん製品特有のTipsにかたよったものが多くてあまり汎用性がなかったりする。Oracleのパラメータを勉強するというのはそれはそれで必要なのだけど、わたしが目指しているものとちょっと違う。

ここでは一般的なアプリケーションのチューニングくらいの軽いノリのお話をする。

チューニングするくらいだから性能に満足していないという前提であるが、性能に特に不満がないのなら無理をしてチューニングする必要はない(当たり前だけど)。

性能とはここでは速度の事を言うことにするが、それ以外でもメモリ消費量だとか、ディスク消費量だとか別の次元でのチューニングというのもありえる。

CPU、IO、メモリなどはCPU時間、IO時間などを計測すれば、どこがボトルネックになっているかわかる。ロック競合の場合、CPUやIOはまだまだ余裕があるのにスループットが出ないなどの現象がでたりする。

いずれにせよ現状を正確に理解することが第一歩になる。

CPUボトルネックの場合、アルゴリズム、データ構造の改良などが必要になるが、そのまえに定量的な測定がかかせない。

速度を計測する基本は、時計である。実行にどれだけかかったかを計測する。それこそストップウオッチからはじまって、Linuxでは time コマンドを利用したりする。アプリケーションからであればgettimeofday()なんかを利用する。もっと精度をほしければTSC(time stamp counter)を利用するとよい。

実行プロファイルをとる。

linuxの場合oprofileが利用できるので、それを使おう。

ユメのチカラでは下記のエントリーが参考になる。

Rubyのプロファイリング
http://blog.miraclelinux.com/yume/2006/10/ruby_0b0e.html

実際にrubyの実装を題材にoprofileで計測し、ボトルネックを発見した事例を示している。

コードを読むな、理解しろ
http://blog.miraclelinux.com/yume/2006/10/post_e3d6.html

上記の性能チューニングのお話のまとめである。パッチの作り方も含めて事例を示している。ボトルネックを発見できれば、比較的簡単に解決策は見つかる。

もうすこし本格的なカーネルチューニングは以下である。

Linux Kernel 2.6.18とCache Pollution Aware Patch
http://blog.miraclelinux.com/yume/2006/09/linux_kernel_26_2c2c.html

2.6.18に採用されたカーネルパッチは下記のプロジェクトで作ったのだが、iozoneというベンチマークを実施し、oprofileでCPUキャッシュミスを計測した。そのボトルネックの部分についてカーネルパッチを作成し、効果を検証した。

キャッシュミスを発見するのはoprofileを利用すれば簡単にできる。ただ、その現象を解決するカーネルパッチの実装は(自分にとっては)簡単ではなかったが、パターンを発見したので今後同様の現象であれば、同じ方式で解決できる。

詳細については下記の報告書を参照されたい。

2005年度オープンソースソフトウェア活用基盤整備事業
「OSS性能・信頼性評価／障害解析ツール開発」
OS層
〜CPUスケーラビリティ評価編〜OS-cpu.pdfをダウンロード

カーネル読書会のおしらせ(第79回)

日時：8月23日、18時半開場、19時ころ開始
会場：ミラクル・リナックス、セミナールーム

お題：Fault Injectionについて
発表者：美田さん
Fault Injection はエラーをわざと起こし、通常テストすることが難しいエラー処理の部分をテストするためのフレームワークです。このしくみや使い方の説明、これまでにこれを使って検出したバグなどについて話す予定です。

18:30頃、開場
         Lightning Talks
19:00頃、お題開始
20:30頃、懇親会開始

場所はいつもの、ミラクル・リナックス社セミナー会場地図
http://www.miraclelinux.com/corp/about/maps_google.html

今回は一人5分の LT (lightning talks) も募集します。
LT発表希望の人は直接わたしまでメールでお題をください。

開場した後は、だらだらと自己紹介やらLTやらをやりますので、時間の許す限り早めに来た方が面白いお話をきけるかもしれません。

会場で、ピザとビールの懇親会つき。（予定価格1000円）
懇親会参加希望の方は、懇親会参加と明記してください。

登録はいつもの宴会君
http://utage.org/enkai/
宴会コード kernel070823

会場の都合で35名で締切ます。

LL魂

夏の祭典。LL Spirit (LL魂)  に行ってきた。

個人的な感想など。

昨年のLLゴングのパイプ椅子は、おじさんには拷問に近いものがあったが、今年のホールの椅子は適度に座り心地もよく快適であった。実行委員会の皆様、ご苦労様でした(ぺこり)。

和田先生は、あいかわらづお元気そうでなによりだった。ステーブンレビーのハッカーズの話からはじまって(この本はハッカー倫理を知るうえで重要なテキストなのである)、ハッカーズ大辞典などを紹介しつつ、ハードウェアハック(微分機械(？)って何みたいな)のお話など、大変楽しい講演であった。帰宅してから先の2冊を本棚からとりだしパラパラめくったのは言うまでもない。

しかし、オレ様言語の作り方でパネルディスカッションができちゃうほど日本という地域にはオレ様言語をつくっている人がいっぱいいるのね。すげーな、本音できたよ。という感じである。

学校でコンパイラの作り方とかは習うけど、オレ様言語を作ってしまえというような危険思想をうえつけられるということはまあない。オトナの事情というやつで、研究職に進む人には、言語では論文とおらないよ(これが殺し文句)、企業に行く人には、言語では食えないよ(これも殺し文句)。大抵はそれであきらめるのが良い子の姿である。

それにもかかわらづ、わらわらとオレ様言語一派が勃興しているのは、やはりRubyのまつもとさんの影響に違いない。諸悪の根源はまつもとである。

オレ様言語どころかハリボテOSと称してオレ様OSまで作ってしまう輩もわらわら居て、日本という地域の将来を深く憂えるものである。(これはまた別の話)

人の話を聞いていると、なかなか楽しそうである。オレ様言語という自分が神の立場になって、すべてを決定する世界観こそプログラミングの醍醐味のような気がしなくもない。(いかんいかん、だんだん危険思想にそまりつつある)。しかし寝る間もおしんでそんなことをしたら、体に悪そうだ。睡眠不足におちいりそうだ。仕事にも影響があるかもしれない。と考えるのがフツーのオトナである。

自分の世界観をオレ様言語に投影するというのは、これはやってみたものだけしかわからない快感があるらしい(伝聞)。危険な世界だ。麻薬みたいなものである。(とは言っても麻薬をやったことがないので、よくわからないのだけど)

自分も高校生くらいのときに、なんの役にたつのかわからないただプログラミングが楽しいというだけのプログラムを作っていたわけだが、モノ作りの原点というか何かを作りたいという欲求に素直になればオレ様言語作りというのも究極の趣味のような気がしないでもない。プログラミングを目的にしちゃいかんと、一方のオトナのわたしが囁くのであるが、一方のチョイワルオヤジ(死語)のわたしが気持ちイイことして何が悪いと囁くのである。和田先生なんて、一生(？)好きなことをやっていて世間から後指をさされていないではないか、そんな生き方もあるではないか、などと思ってしまう。

しかし、ただでさえ時間がないのに、人生のプライオリティのなかで、こーゆー無限地獄の趣味を持ってしまっていいのだろうか(オトナの判断)。しかし、金はかからないし、ギャンブルにあけくれて家庭崩壊ということではないし、まあいいんではないだろうか(悪魔のササヤキ)。と揺れ動くオヤジ心なのである。

LL魂というのは人の魂をわし把みにしてぐわんぐわん揺振るイベントなのであった。

恐しいイベントである。

(通勤電車の中でニヤニヤしながらオレ様言語を妄想していたというのはナイショである。)

LL Spirit 感想。トラックバックリスト
http://karetta.jp/article/blog/ll-spirit/132858/trackbackList#trackbackList

Ottawa Linux Symposium 2007 (ols2007) まとめ

というわけで、Ottawa Linux Symposium 2007 (ols2007)を総括してみる。

出席者は750人程度で、昨年より微妙に減少しているのは、kernel summitを併設しなかったからと言われているが、本当のところはよくわからない。それでも、2.6.22にパッチを出した約800人中、少なくとも100人以上は参加していたわけだから、地球最大のlinuxの技術会議と言っていいだろう。

企業からの参加者も多くて、発表者の所属をざっとみるとIBMとIntelがさすがに両巨頭である。まるっきり個人で発表しに来ているというのはあまりいないようだ。昨今は企業がスポンサーになって開発を主導しているという流れをあらわしている。

アマチュアスポーツからプロスポーツへギアがかわりつつあるという感覚かもしれない。プロスポーツになるともちろん得られるものもあれば失なわれるものもある。インディーズからメジャーレーベルでデビューする事によって得られるものと失なわれるものみたいなものなのかもしれない。もちろんわたしはメジャーレーベルでデビューした経験がないのでよくわからないけど。

いづれにせよ、プロになって、技術がより高度化、専門化した部分は確実にあって、発表の中にも、これってIntelの中の人じゃないと、ちょっと手が出せないよなあというものもいくつかあった。

一方で企業とコミュニティとのかかわりというと、やはり個人的にはカーネル読書会の席でいろいろ勝手を言ったTOMOYO Linux BOFが印象深かった。日本にとじこもっちゃいかんいかんいかん。ばんばん(机を叩く音)。Ottawaに行くべきだ、LKMLにデビューすべきだ、アップストリームにマージするべきだ、などと人様に向って大変エラソウな事を言ってOttawaまでひきづり出したTOMOYOチームの皆様の健闘には大きな拍手をおくりたい。余計なお世話みたいなものではあるが、結果としてTOMOYOの皆様が少しでも楽しんでいただけたら望外の喜びなのである。ご苦労の方が多かったみたいで、若干もうしわけない気もしないわけではないが、まあ、この経験が共有されるということは非常に価値が大きいので、ご容赦いただければ幸いである。

まだまだ日本の企業はコミュニティとのかかわり方についての経験値がたりないと思う。実感として。英語の壁もあるかもしれないが、本当のところ英語の問題ではなくコミュニケーションの問題なのだけど、それは経験をつんで、失敗と成功を重ね自ら獲得しないといけない。擬似的な経験値を積むのにカーネル読書会はいろいろな意味でいい場所なので、どしどし利用してほしいと強く思った次第である。

http://tomoyo.sourceforge.jp/wiki/?OLS2007-BOF

TOMOYO Linux
http://blog.miraclelinux.com/yume/2007/02/tomoyo_linux.html

企業発OSSのコミュニティアライアンス戦略
http://blog.miraclelinux.com/yume/2007/02/oss_446d.html

OLS 2007 (3) -- TOMOYO Linux BOF
http://blog.miraclelinux.com/yume/2007/06/ols_2007_3_tomo.html

人月の神話と大聖堂とバザール

人月の神話を先日読みかえしたので、今度は「大聖堂とバザール」を読みたくなる。「大聖堂」で自分のはてな日記を検索してみると

蕎麦屋
http://d.hatena.ne.jp/hyoshiok/20060808#p1

大聖堂とバザール
http://d.hatena.ne.jp/hyoshiok/20040622#p2

というのを発見する。前者はどうでもいいよた話であるが、後者はそのものズバリという感じのものである。

山形浩生のCathedralを伽藍と訳すのは、どう考えても誤訳に近いと思う。世間では「伽藍とバザール」でとおっているが、わたしはあくまで「大聖堂とバザール」というタイトルにこだわる。人月の神話での挿絵は伽藍ではなく大聖堂だと思う。「大聖堂とバザール」に対するわたしのコメントを書く前に紙面が尽きてしまった。（うそうそ）

なぜソースコードを読むのか？／ユメのチカラ
http://blog.miraclelinux.com/yume/2006/08/post_3771.html

人月の神話

Frederick Phillips Brooks Jr., "The Mythical man-manth: essays on software engineering", Anniversary edition. フレデリック・Ｐ・ブルックス Ｊｒ．「人月の神話」新装版、狼人間を撃つ銀の弾はない。滝沢徹他訳

わたしが紹介するまでもなくソフトウェア開発の古典中の古典である。先日の「情報システム学会(ISSJ)、情報システムのありかたを考える会」での発表のために、久し振りに読みかえしてみた。

原書は1975年に出て、長いこと読み継がれてきて、今だにその指摘は古びていない事に驚かされる。16章からは、初版以降に書かれた論文、評論になるが、やはりこの書の本質は、初版時点で書かれた1章から15章であろう。

第1章「タールの沼」。大規模システムプログラム開発がタールの沼にはまってもがき苦しむ、恐竜やマンモスみたいなものだと記している。今でも、そのようなプロジェクトは枚挙に暇がない。ソフトウェア開発の難しさを端的にあらわしている表現である。

「新聞を読んでいると、二人のプログラマが改装ガレージで、大開発チームが最大限の努力で作り上げたものを凌ぐ重要なプログラムをいかにして作成したか、という記事をたまたま見つけることがある。(中略)
それなら、どうしてソフトウェア産業の開発チームはそうしたひたむきなガレージ二人組にすべて取って代わられてしまわないのだろうか」(第1章、4頁)

ソフトウェア製品とプログラムの作成の本質的な違いは、前者にはマニュアル、教育、サポート、継続的なアップデートなどがついていて、後者は単なる実行可能なプログラムというところにあり、前者を製作するにはプログラムを作るより大変な工数がかかるということにある。

ソフトウェア工学の歴史は、大規模なソフトウェア製品をいかにしてタールの沼にはまらないようにして作るかという歴史に他ならない。

「ソフトウェア産業がガレージ二人組に取って代わられてしまわない」というBrooksの指摘はある面、正しかったが、一方でインターネットやオープンソースソフトウェア(OSS)の発展は、「ガレージ二人組に取って代わられた」事例のようにも見れる。

1975年の時点で、世界(地球)規模のソフトウェア開発環境は存在しなかったし、それを見通すということは、Brooksであっても不可能である。しかし21世紀になって、地球規模のコラボレーションが可能になり、コミュニティによる開発というのが、ソフトウェア産業を取って代わるほどの影響力を持ちはじめているという点は指摘してもいいと思う。

確かに単一の銀の弾丸はなかったかもしれない。しかし、インターネットというメディアとコミュニテーによる開発というのは、「ガレージ二人組」が世界にインパクトを与える可能性がある事を示した点で意義深いものである。

Brooksはプログラミングがなぜ楽しいかという事も記している。

• 物を作り上げる純粋な喜び
• 他の人々に役立つものを作ることの楽しさ
• 複雑なパズルのような組み立て部品を完成させ、それが巧妙に転回するのを眺めるおもしろさ
• つねに新しいことを学ぶという喜び
• 非常に扱いやすいメディア(媒体)で作業する喜び。その上、プログラムというのは、詩人の言葉と違って、現実に動いて働きだす

一方で、プログラミングの苦しさも記している。

• すべて完璧にこなさなくてはならない。呪文の一字一句たりとも正しくなければ、魔法は使えない。
• 壮大なコンセプトをデザインするのは楽しいものの、シラミの卵ほどの微細なバグを見つけ出すのはそれこそ単純労働だということである
• あれほど長い間苦労してきた製品が完成時(またはそれ以前)には時代遅れに見えてしまうことである

OSSにかかわる多くの人は、プログラミングに楽しさを見いだしている。一方でプログラミングの苦しさを上手に回避している。一人で膨大な単純作業をやるのは苦しいが、コミュニティで開発すれば、それも苦ではないという事かもしれない。喜びは参加者の分だけ倍増し、苦しみは参加者の分だけ割引かれる。

Brooksの「人月の神話」は読めば読むほど味がでてくる名著である。

まだ読んでいない若い技術者にはぜひ読んでほしいと思う。強くお勧めしたい。

情報システム学会(ISSJ) 情報システムのありかたを考える会

情報システム学会の「情報システムのあり方を考える」会に参加した。

オープンソースソフトウェアの潮流というタイトルで小一時間ほど放談をさせていただいた。特に目新しい事を述べたわけではないが日頃考えていることを好き勝手にお話しした。いろいろなコメントをいただいたが、皆様どのような印象をおもちになったか興味深いところである。

OSSの可能性として、日本のこれから会社を停年退職するシニアエンジニアの皆様が、コミュニテーベースの開発に参加する事をわたしは期待している。日本の重厚な人材の集みを利用した世界貢献であり、それによって、日本という国が、単に経済的に豊かなだけではなく、人という宝があり、技術的にも優れているということを示す大変なチャンスだと思う。それは世界からも尊敬されるような日本モデルになるのではないだろうか、というような妄想を語ったのだが、諸先輩がたにはどう映ったのだろうか。おかしなやつだと思われただろうか。

だけど、わたしのようなおかしな奴が少しでも増えてくれば、少子高齢化の社会もちょっとはおもしろ可笑しく過せるし、何よりも団塊の世代とよばれる人々の楽しみも少しは増えるのではないだろうか。コミュニティの構成員が増えることは悪いことではないしベテランの参入は間違いなく良いことだし、それによって、コミュニティの価値も高まる。誰も損をしない、みんなが得をするモデルだと思う。

まあ、放談は放談で、「情報システムのあり方を考える」会にどれだけ役にたったか多いに疑問ではあるが、「情報システム」作り方としてコミュニティによるバザール開発みたいなモデルがあるということはご紹介できたのではないかとも思ったりする。

この発表のためにBrooksの「人月の神話」を久し振りに読んで、Brooksのパラダイムとは全く異なるソフトウェア開発パラダイムがあるということを自分自身再確認した次第である。

追記：参考までに発表用スライドをアップロードした。issj.pdf(発表用スライド)をダウンロード

カーネル読書会のめざすもの

YLUG(横浜Linux Users Group)のカーネル読書会FAQページがあまりにも古いので更新しようと思ったのだが、どっから手をつけていいやら。

この手のFAQは個別のエントリに回答を重ねて更新する事はもちろん可能なのだが、ロードマップというかカーネル読書会をなぜ開催したいと思ったのかとか、なぜ続けているのかとか、どうしたいのか、とかいう明確な意志の表明なんかがあるといいかもしれないと思った。企業のビジョンステートメントみたいなものである。

おいおい、たかが趣味の世界でビジョンステートメントはいくらなんでもやりすぎだろう。大袈裟すぎやしないか、という声もある。そう思う人もすくなからづいそうだ。わたしもそう思わなくもない。

コミュニティ(？)のビジョンとかミッションというのは通常明文化されないし、されたためしも(ほとんど)ない。LinusのJust For Funという書籍は、ある意味その手のものかもしれないけど例外である。あ、StallmanのGNU Manifestというのがあるなあ。これは例外中の例外だ。

まあ、楽しいから続けていたら続いちゃったというのが本当のことであるが、どうせなら試しに、カーネル読書会にまつわる「よしおかの野望」を明示しておこうと思う。

わたしは、90年代中頃、シリコンバレーの大手データベースベンダーでRDBMS(リレーショナル・データベース管理システム)の開発をしていた。シリコンバレーのフリーペーパーには各種ユーザー会や勉強会の日程が載っていて、その量とバラエティに圧倒された。プログラマとしてプロフェッショナルな道を歩むために、ぜひその手の会合に出ようと思った。機会をみつけて参加したいと思った。たまたま参加した、SVLUG(Silicon Valley Linux Users Group)の活気、熱気には圧倒されたことを鮮明に覚えている。

会社の壁とか人種とか国籍とか性別とか年齢とか、そんなもの一切合切関係なく、ひとつのことについて自由に語りあっている場というのが、どんなにか素晴しいかというのを実感した。

99年に日本に帰ってきて、自分の生活圏にそーゆー場があったら素敵だなと思った。

これからはオープンソースでしょ。みたいなノリもあった。

自由命みたいなノリもあった。

自分が勤めている会社とは対極にあるムーブメントにしびれていたのである。

日本に帰って、たまたまYLUGというのを発見し、早速メーリングリストに参加した。特に会費も会則もないのが気にいった。時々宴会をしているらしい。楽しそうである。

そこで、カーネルのソースコードを読む宴会(？)というのを提案したところ、あれよあれよという間に参加者が集まって第一回のカーネル読書会が開催されたのである。

前半の勉強会形式のディスカッション、後半の宴会という黄金のパターンも第一回で確立された伝統芸みたいなものである。

当初は結構地味にソースコードを追っていたのであるが、何度もやるとさすがにあきるし、準備も大変なので、もちっとお気楽に行こうということで、お題提供者が適当にお題を披露する形式になった。

第８回から場所を渋谷マークシティのサンブリッジのセミナールームにうつしてそれが2001年末まで続き、その後天王町(保土が谷)OSDLジャパンの会議室で2004年にOSDLが引越すまでお世話になった。その後、固定した会場をもたない流浪の旅がはじまったのだが、NTTデータ、ミラクル・リナックス、日本SGI、日本HPなどおかりして開催し現在にいたる。
YLUG年表参照（http://www.ylug.jp/modules/pukiwiki/index.php?history）

時々出張か〜ねる読書会というのをやって新規参加者のリクルーティングをやっているのだが、なかなか思うように参加者が増えない。特に若い人と女子が少ないというのが構造的な問題だと認識している。やはり新規参加者が少ないとマンネリ化してしまうし刺激が少ない。

YLUG年表を見ると、よくもまあこんなにバラエティのあるお題を継続してやったなあと思う。発表者と参加者の皆様に心より感謝したいと思う。また会場を提供していただいた関係各位にも深く感謝したい。どうもありがとうございました。(ぺこり)

一つ一つの発表に思い出がつまっている。どれも大変楽しかったし、勉強になった。多くのことを学んだ。感謝につきない。そんなこんなで現在まで続いているのである。

と、ここまで書いていて、歴史を振り替えるところで力が尽きてしまって、「よしおかの野望」を記すまでには行かなかった。カーネル読書会のめざすところは次に記すことにする。(続く)

Community Based Development

オープンソースソフトウェア(OSS)の力はバザールモデルとして知られるコミュニティによる開発(Community Based Development)だと思う。

OSSの特徴としてフリーなライセンス(利用、変更、再配布の自由など)があげられる事が多いが、それはあくまで必要条件であって、十分条件ではない。ライセンスをフリーにしたからと言って、コミュニティが自然発生するとは限らない。商業ソフトウェアベンダは自社製品をプラットフォームとするために、あの手この手を使ってコミュニティを形成しようとするが、それには相当なコストと時間がかかる。

大雑把にソフトウェアを分類してみる。

最初のカテゴリは、プログラム。これは実行可能なソフトウェアで、趣味で作ったり学校の課題で作ったりする小規模なものとする。規模も小規模でせいぜい大きくても数千〜数万行程度のものである。おもちゃのプログラムに毛がはえた程度のものだ。もちろんサポートもなんにもないし、商業的な価値を見いだすことも難しい。

その次は、ソフトウェア製品。これは商用、非商用にかかわらず、ある程度のドキュメントと、利用者がついて、継続的に修正、改良されているソフトウェアである。製品というと商用のイメージがつきまとうが、他にいい名前を思いつかなかったので、とりあえずソフトウェア製品とここでは言うことにする。ブルックスはプログラミングシステム製品と呼んだが、わたしにはちょっとピンとこなかったので、ここではソフトウェア製品と呼ばせてもらう。非商用のソフトウェア製品というのが、ブルックスの時代(60〜70年代)には一般的ではなかったが、オープンソースの時代になって、星の数ほどでてきた。

最後は、ソフトウェアプラットフォーム(プラットフォームと略すことにする)。多くの利用者がつき、その上で重要なアプリケーションが稼働するようになる。あるいは、そのソフトウェアに依存するようなソフトウェアが多数生まれてくる。Linuxはまさにプラットフォームである。コンパイラのgccもプラットフォームと呼んでもさしつかえないと思う。商用製品で言えばデータベース管理システムのOracleもプラットフォームと呼べるだろう。そしてプラットフォームにはコミュニティの形成、存在が必要不可欠なのである。

上記の分類はあくまでざっくりとしたイメージで各カテゴリに明確な線引きがあるわけではない事をあらかじめお断わりしておく。

成功したOSSを見てみると、一人のプログラマの趣味からはじまったプログラムが、ある日誰かに発見され、利用が口コミで広がり、ドキュメントなどが整備されていって、それとともに、利用者、開発者コミュニティなどが自然発生的に生じ、ソフトウェア製品と言ってもいいほどになり、その後、そのソフトウェアを前提としたプログラムないしソフトウェア製品が次々と出てきて、商用サポートやトレーニングを提供する企業や、解説書の出版などがあいつぎ、プラットフォームの地位を確立するという発展をとげている。

Rubyというプログラミング言語を例にとると、93年にまつもとゆきひろ(Matzと呼ばれている)が自分の趣味で楽しいから自分用プログラムを作ったのが発端である。fjというインターネットのNewsシステムで発表され徐々にひろまっていったのが90年代後半である。最初のRubyの参考書が出版されたのが、99年で、英語の書籍は2000年である。2001年には初のRuby Conferenceが米国で開催され、2004年にはRuby on Railsという開発フレームワークが発表され、現在大ブレーク中という事である。

Rubyの開発は、当初はまつもとが一人で行なっていたが、徐々にメーリングリスト等でのバグの指摘、パッチの投稿など、まつもと以外の貢献の比率が増えてきて、より先進的な機能を実装するプログラマや、Sun MicrosystemsやMicrosoftに代表する大企業の開発者の参入など、開発者の層もひろがってきている。

Rubyはまつもとゆきひろが開発したソフトウェアであるが、徐々に彼以外の開発に関する影響力が増えているというのも事実である。

Rubyはプラットフォームと呼んでもさしつかえないだろう。プラットフォームには健全な開発者および利用者のコミュニティが存在する。

先日のRubyKaigi 2007のキーノートスピーチ(感動的な素晴しいスピーチであった)でDave Thomasは、コミュニティが、その発展によってどのような影響を受けるか、そしてどのように対処するべきかということをユーモアを交じえて熱く語っていた。
http://jp.rubyist.net/RubyKaigi2007/Log0610-S5.html

Rubyは成長している。ティーンエイジのように気難しいが、親はその健全な成長を望んでいる。Rubyにはまつもとゆきひろ(Matz)とコミュニティというよい両親がいる。コミュニティは素晴しい。最近ではRubyはデートもしている。Rubyに迫りくる危機というのもある。爆発的な成長が新しい人を沢山呼ぶ。Rubyのお作法を理解していない人達もいっぱい来る。新しい人々を歓迎する準備をしよう。彼らから学ぼう。

愛に満ちたスピーチであった。成功したオープンソースソフトウェアはコミュニティに依存している。開発はコミュニティに依存している。新規参入者も排除されない懐の深さがある。分断の危機もあるが、それを乗り越えたコミュニティは強い。Rubyコミュニティはまさにそのような岐路にいる。

これは奇跡である。まつもとゆきひろという人間のパーソナリティがそれを可能にした。

Rubyはコミュニティによって開発されているというと、まつもとは相当違和感を持つかもしれないが、もはや彼の力の及ばないところで車輪が動きはじめているというのも事実なのである。彼が最も影響力のある人物である事は間違いないのだが、ティーンエイジのようにRubyは一人歩きをはじめて、その流れは、もはやまつもとですらコントロールできないところまで来ているのである。

コミュニティをコントロールする事は誰にもできない。しかし強い影響力を持つことができる。影響力はコミュニティに対する深い愛と貢献によって得られる。現時点で、最も影響力の大きいのは彼であるが、彼の右腕と呼べる何人かのハッカーが育ってきているのも事実ではある。

わたしはRubyの成長のプロセスを見て、かつてLinuxが発展していった姿に重ねあわせて見た。まつもとはLinusになる必要はないしなるべきではないとは思うが、linuxがたどってきた道はRubyのコミュニティにとっても大変参考になると思う。

RubyKaigi 2007には400人強の参加者があった。世界中から集まった。今後はSIベンダーやハードウェアベンダーのネクタイを締めたおじさんたちもいっぱい参加するようになるだろう。

Rubyのお作法、OSSのお作法を知らない傍若無人なやからも大挙することであろう。しかし、たとえそうであってもlinuxが上手に立ち回ったように、Rubyも上手にいなすと思う。

Community Based Developmentの奇跡である。ビジネスパーソンはこの価値の創造メカニズム、ソフトウェア開発方法論について理解を深めた方がいいと思う。わたしのミッションは、彼らにCommunity Based Developmentの革新性、有効性、持続可能性についてを伝えて、この波に参加することが彼らのビジネス(経済的な利益)にも繋がりうるということを理解させることである。

コミュニティは新しい人達の参入を歓迎することによって、さらに学び発展する。

愛だよ、愛。

6年前、アメリカでfirst Ruby Conferenceで私が受けたStanding Ovationを今年は日本でDave Thomasに返すことができてとても良かった、という話。

こういう話を聞くにつれ、Daveのキーノートは本当に感動的だったんだなあ、と思う。ただ単に「面白い話」では、人の心は動かない。彼が真摯に愛について語ったからに違いない。

Matzにっき

日曜のDave Thomasの講演の時に総立ちになったとき、思い起こしたのはもちろんあの日のことでした。Dave Thomasへのstanding ovationは、6年の歳月を経て、海外のRubyistからもらった賛辞に対しての、日本のRubyistからのお返しを象徴するものだと思います。2001年は40〜50人くらいだったように記憶していますが、2007年は約400人もの参加者がいました。ほぼ10倍です。ここまで大きくなったのは、6年もの間、まつもとさんと内外のRubyistたちが行ってきた努力や貢献の賜物以外の何物でもないでしょう。海外への普及の最重要人物であるDave Thomas氏に対し、残念ながら（とてもとても残念ながら）同席できなかったまつもとさんに代わり、盛大な拍手を返すことができたのは、Ruby communityにとって非常に意味のあることだったと思います。

6年後のStanding ovation/思っているよりもずっとずっと人生は短い。

ムーアの法則を理解すること（その２）

アーキテクチャの設計寿命でもふれたが、Alpha AXPのアーキテクチャの設計ゴールは下記のとおりであった。
http://blog.miraclelinux.com/yume/2007/02/post_e9f1.html

   1. 高性能
   2. 寿命が長い事
   3. VMSとUnixが動くこと
   4. VAXおよびMIPSからの容易なマイグレーション

１と２については達成されたと考えていいだろう。３および４はDECが当時おかれていた状況から考えてまっとうな設計要求である。しかし、このゴールはDECという会社が消失してしまった以上達成はかなわなかった。

高性能のアーキテクチャを設計することは緻密なエンジニアリングを行っていれば、（もちろん簡単ではないが）達成不可能ではない。むしろ容易な範疇にある。

本当に難しいゴールと言うのは、マーケットに求められているものをタイムリーに提供し市場で受け入れられることである。こればっかりはエンジニアリングチームばかりではどうしようもない。マーケティング、営業、サポート、等々全社的な活動となる。企業の総合力が問われているのである。

世界で最高速のマイクロプロセッサを作っても売れなければなんの価値もないのである。こう言ってしまうと身も蓋もないが市場経済というものはそういうことである。

世の中で最も利用されているマイクロプロセッサのアーキテクチャはIA32である。命令セットに直交性がなかったり、CISCの典型的なアーキテクチャではあるが、互換性をキープしながら性能向上を図ってきた。

IA32の性能向上のアイデアは先行した多くのRISCマシンに見られるがそれを集大成しバイナリコンパチビリティをかたくなまでに守ってきた。

64ビット拡張ではIntel IA64があるが、Alpha同様、以前のアーキテクチャ（この場合はIA32）と互換性がない。今にいたるまでIA64の市場は広がっていない。

世界最大のマイクロプロセッサベンダであるIntelの力をもってすらアーキテクチャの移行というのは容易ではないのである。

マイクロプロセッサの命は命令セットであり、それを変更することはソフトウェアの重さから考えて容易ではない。結局、『増加したトランジスタ(向上した集積度)をどう使うか』という問題に対する回答は、互換性の維持に使われる、といういささかユメのないことになるのである。

多くのコンピュータアーキテクトがこの問題にチャレンジして、屍の山を築いてきた。汎用プロセッサのエリアでは、互換性が最も重要な設計ゴールとなっているのである。

このゲームのルールを変えるには勝負する土俵を変える必要があってゲームや携帯などの組み込み系から攻めていくというのが当面の流れかと思う。

一方でオープンソースがソフトウェアの重さ（膨大なソフトウェア資産の慣性）を軽くすることができるのだろうか？新しいチャレンジがそこにはあるような気がする。

ムーアの法則を十分理解した上での新しいソフトウェア設計、製造、保守のモデルとしてのバザールモデルへの熱い期待である。

ムーアの法則を理解すること/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/06/post_e653.html

ムーアの法則を理解すること

Matzにっき (2007-05-30)
インテル：「ソフトウェアもムーアの法則に従う必要がある」 - CNET Japan
http://www.rubyist.net/~matz/20070530.html#p07

「今まではハードがどんどん高速化してきたので、ソフトウェアの皆さんは(マシンのアップグレードで)自動的に性能向上を享受できていましたが、これからは諸般の事情でそういうことはできなくなります。ソフトウェアの皆さんもご協力を」という話。

っていうか、最初からそういう風に言ってほしいものだ。

このブログの読者ならご存知かと思うが、わたしは昔DEC (Digital Equipment Corporation)という会社に勤務していた。わたしがエンジニアリングのイロハを習った会社である。VAXそしてAlpha AXPというコンピュータ史に残るアーキテクチャを開発した会社でも知られている（若い人は知らないかもしれないけれど）。商業的にはその後コンパックに売却され、コンパックはHPに売却され今はその名はない。

さて、そこでソフトウェアエンジニアとしてのキャリアを積んでいったのであるが、そのエンジニアリングコミュニティは間違いなくムーアの法則をコミュニティとして理解していた。(マルチプロセッサ向けソフトウェアパラダイムとは、マルチプロセッサ向けソフトウェアパラダイムとは？(その２)を参照のこと)

Alphaの開発チームはVAX開発チームの後継で、ある意味DNAを受けついでいるのだが、当時の論文(90年ごろ)で、マイクロプロセッサのスケーラ ビリティを、クロックの向上で10倍、アーキテクチャの進歩で10倍、マルチプロセッサで10倍、10x10x10=1000倍の性能向上を達成するとか しないとか書いてあって、感心したのを覚えている。

http://blog.miraclelinux.com/yume/2007/01/post_ab8c.html

アーキテクチャの設計寿命で紹介した論文をふたたび引用する。1992年の論文であることに注意されたい。
Alpha AXP Architecture
by Richard L. Sites
http://www.hpl.hp.com/hpjournal/dtj/vol4num4/vol4num4art1.pdf

The remaining factor of 10 will come from multiple processors. A single
system will contain perhaps ten processors and share memory. We therefore
designed a multiprocessor memory model and matching instructions
from the beginning. This early accommodation for multiple processors
also distinguishes the Alpha AXP architecture from many other RISC
architectures, which try to add the proper primitives later.

今後15年から25年のレンジで性能向上をはかるためにクロックレートで10倍、それ以外の設計要素(投機的な実行、Out of Order、スーパーパイプライン、スーパースケラー等々)で10倍、そして残りはマルチプロセッサ技術で10倍、合計10*10*10=1000倍のスケーラビリティを確保する、という事である。

この論文が発表されたのは92年でAlpha AXPの開発が開始されたのは88年あたりだからAlpha AXPチームは約20年前には、間違いなく今後の性能向上にはマルチプロセッサの技術が必要になるというビジョンを持っていた。

商用OSはSMP性能でのボトルネックを発見し修正するという地味な作業を延々おこなってきたし、ミドルウエア(RDBMSなど)もSMPでの性能向上に力をそそいできた。今後も益々SMPの重要性は増すであろう。

そして、ソフトウェアコミュニティでも、それを理解する必要がどんどん増しているのである。

つい最近までハードウェアの性能向上にあぐらをかいてソフトウェア側の性能向上の努力というのはほとんどなかった(というのは言いすぎかもしれないけれど)。汎用的な性能向上という点から言うと進歩はゆっくりしていると言っても過言ではない。

ムーアの法則をもう一度よく理解する必要がある。

そして、もう一つ重要な点、増加したトランジスタ(向上した集積度)をどう使うかについては、後に記す(かもしれない)。

インテル：「ソフトウェアもムーアの法則に従う必要がある」
http://japan.cnet.com/news/biz/story/0,2000056020,20349605,00.htm

アーキテクチャの設計寿命/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/02/post_e9f1.html

マルチプロセッサ向けのソフトウェアパラダイムとは/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/01/post_ab8c.html

マルチプロセッサ向けソフトウェアパラダイムとは？(その２)/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/01/post_95e7.html

マルチプロセッサとマイクロカーネル/ひら
http://d.hatena.ne.jp/hira_sosuke/20070604/1180968495

技術は会社のものではない。みんなのものだ。

技術は会社のものではない。みんなのものだ。

プロプライエタリな世界に長くいると、上のようなことを言うと、こいつおかしいんじゃないかと思われてしまうが、オープンソースの世界にどっぷりつかっていると、「技術は会社のものではない。みんなのものだ。」というのはおかしくともなんともない。至極普通のことと思う。

企業がオープンソースに関わるとき「技術は会社のものではない。みんなのものだ。」ということを理解できているかどうかというのが成功のポイントになるような気がする。理屈の上では理解していても企業、組織として理解できているかは別の話である。

例えば、オープンソースソフトウェアを共同して改善する場合、そのプロセスそのものを公開できるか。密室で改善するのではなく、公開のメーリングリストなどでオープンに議論しながらパッチを作るとかを、最初っから実践できるか。そもそも開発を公開のメーリングリストでするという発想があるかないか。開発ポータルをsourceforgeのような公開サイトで行うということが自然にできるか。

わたしの野望はそのような行動原理を理解する会社や組織を少しでも増やして多くの人たちと共同でオープンソースの開発をする土壌を作ることである。それを日本という地域でやりたい。なかなか道は遠いのであるが不可能ではないと思っている。（よしおかの野望）

第74回カーネル読書会

今回は趣向をかえてPostgreSQLとSELinuxの組み合わせ〜

日時：5月7日(月)、18時半開場、19時ころ開始
会場：ミラクル・リナックス、セミナールーム

お題：SE-PostgreSQL : OSとRDBMSのセキュリティポリシーの統合
発表者：海外 浩平さん
内容：SE-PostgreSQLは、PostgreSQLにSELinuxとの連携による細粒度の強制
      アクセス制御機能を組込み、Linux kernel と RDBMS を統合されたセ
      キュリティポリシーの下で動作させるものです。
      今回の読書会では、SE-PostgreSQLの特徴/機能や実装、コミュニティ
      との連携についてご紹介します。

18:30頃、開場
19:00頃、お題開始
20:30頃、懇親会開始

場所はいつもの、ミラクル・リナックス社セミナー会場地図
http://www.miraclelinux.com/corp/about/maps_google.html

開場した後は、だらだらと自己紹介やら小ネタやらをやりますので、時間の許す限り早めに来た方が面白いお話をきけるかもしれません。

会場で、ピザとビールの懇親会つき。（予定価格1000円）
懇親会参加希望の方は、懇親会参加と明記してください。

登録はいつもの宴会君
http://utage.org/enkai/
宴会コード (kernel070507)

会場の都合で35人程度で締め切ります。早めに登録してください〜

Web2.0時代のソフトウェア開発のスピード

最近、あるWeb2.0系の会社の方たちと勉強会をしているのだが、その勉強会もさることながらその後の懇親会でのユルイ会話が面白い。ていうか、勉強会の後の懇親会が好きでやっているのだろうとかいう突っ込み。否定しません。というか、飲み会に大義名分をつけるために、勉強会と称しているのだろう＞自分

それはともかく、いろいろ面白いお話を伺う。

Web2.0系のサービスってのは、やってみないと分からない類のものが多いのでともかく思いつきでも何でもとりあえづやってみる。だめだったら考え直す。そーゆースタイルらしい、極論すると。

古典的なウォータフォールモデルでのソフトウェア開発だと、だめだったら考え直すなんていうアバウトなことを言ってはいけないという前提で物事が進むから、ともかく石橋を叩きつつ確実に確実に事をはかる。それはそれで確立されたスタイルなので、間違いではないが、プロジェクトを開始した時点と終了するころには、回りの環境もごろって変わっているだろうし、顧客の要求も全然違っている事も少なくはない。開発期間が年単位だと、顧客要求の変化というのは致命的なリスクであることは間違いない。

アジャイルな開発だと、取り合えづ動くものを作りそれをどんどん改良していく。その改良のプロセスの中で顧客の要求にどんどん合わせていく。

ところで、新しいサービスはどうやって作るんですか、どっからアイデア得るのですか、とか言うことをその飲み会で聞いてみた。

以下はわたしの中の脳内変換された会話。（括弧の中はわたしのなかの反応）

Web2.0：そうですね、飲み会ですかね

よ：え、え？（アイデアを飲み会で出すとかそーゆー事かなあ？）

Web2.0:金曜日に飲み会するんですよ。（ふむふむ）。で、そこで仕事の話とかになったりするんだけど、結構サービスのアイデアとかでたりするんですよ。（ふむふむ）。それでみんなであーだこーだ言っているうちに、ブレーンストーミングみたいな感じになって、どんどんアイデア膨らむんですね。（なるほどね）。金曜日の飲み会だから、朝まで飲んじゃうこともあって、そーゆー時はそのアイデアをすぐにでも実装したくなるじゃないですか。（え？）。そうするとそのまま会社に戻っちゃたりするんですよ。（まさか）。みんな近所に住んでいたりしますしね。（げげ、そーゆー問題でもないだろ）。それで一気にコーディングとかはじめちゃったりして、（ぐは）、そんでもって、取り合えづ、月曜日にみんなで評価して、面白そうだったら、それでサービスデリバーっすよ。

よ：金曜日の飲み会のアイデアを月曜日にサービス開始？？

Web2.0：ま、そんな感じっすかね。

やばい、全然ついていけない。

テストカバレージ

先日Ottawa Linux Symposiumに論文のproposalがとおったという話を書いたが、論文を鋭意執筆中である。今回crackerjackというリグレッションテストのフレームワークをうちの若手のkyagiさんがばりばり作ったのであるが、それから呼ぶbtraxというカバレージ測定ツールがこれまた凄い。これは日立の藤原さんというハッカーが実装したのだけどなかなか金銭ではなく琴線に触れるツールである。

ハッカーのバイブル、IA-32 Intel Architecture Software Developer's Manual, Volume 3: System Programming Guideの15章はおなじみのDebugging and Performance Monitoringである。わたしもhardmeterを実装する時は読みに読んだ。マニュアルがボロボロになるまで読んだ。お疲れ様、マニュアルである。

Intelのマニュアルは4半期から半年に一回くらいアップデートしていて手元にあるハードコピーは16版目のやつだ。

15.5からLast Branch Recordingのお話である。Pentium 4/Intel Xeonプロセッサは分岐、割り込み、例外を記録するハードウェアメカニズムを持つ。LBR(Last Branch Record)に最後の分岐、割り込み、例外の情報を記録する。このブランチレコードにはどこから(branch-from)と、どこへ(branch-to)の命令アドレスの情報を保持する。そしてその情報をBTM(Branch trace messages)としてシステムバスに流す。そのBTMをメモリ常駐のBTS(Branch Trace Sotre)に保持する。というような仕組みである。

さて、ハードウェアが分岐命令についていろいろ情報を提供してくれるというのはわかった。

これを使うとどんなことができるのか。

例えば、if (A) then x else y; みたいなコードがあってxを実行したのか、yを実行したのかのトレースがとれる。

テストプログラムの網羅性を議論する時、条件分岐で、どっちのパスも実行、試験した方がいいわけだが、そのカバレージを測定できるのである。

テストカバレージでC0カバレージというのは、命令網羅率とも言われていて、命令を実行したかしなかったかを問う。if(A) then x;みたいな文については条件Aが成立した時に命令を網羅したことになる。

テストカバレージでC1カバレージというのは、条件網羅率とも言われていて、条件(真と偽がある)を網羅したかを問う。if(A) then x;は条件Aが成立した時だけではなく条件Aが成立しなかった時も実行しないと網羅率100%にならない。

高級言語レベルでの網羅率測定はgcovなどのツールを利用すれば簡単に測定できる。linux kernelのカバレージを測定するためにはパッチが必要でLTP(linux test project)のcoverage 分析プロジェクトというのがgcov-kernelパッチを公開している。http://sourceforge.net/project/showfiles.php?group_id=3382
http://ltp.sourceforge.net/coverage/lcov.php
しかし、いかんせんカーネルパッチというのが敷居が高い、お手軽ではない。

そこでbtraxである。btraxは、カーネルパッチも必要ないし、別途カーネルを構築する必要もないので日頃利用しているカーネルの分岐網羅性などを測定するのにうってつけである。

さらに今回のbtraxは機械命令レベルでの分岐網羅性を計測するのでgcc/gcovよりも粒度がより小さい(すごい)。しかもハードウェアレベルで計測するのでオーバヘッドが小さいはづである(多分)。

ソースコードとの対比をすれば未実行のところが一目瞭然である。
http://btrax.sourceforge.jp/

こーゆー良いツールはどしどし紹介して利用したいと思う。

リグレッションテスト

プログラムを変更した際、予想外の影響があらわれる事があり、それをリグレッションあるいはディグレードと呼ぶ。そのようなリグレッションを発見する事を目的に作られたテストがリグレッションテストである。

リグレッションテストのコンセプトは非常に単純なのであるがその効果は絶大であり商用ソフトウェアの開発現場では日常的に利用されている。しかしながらOSSの世界では必ずしも利用されているとは限らない。Linuxについて言えば公式のリグレッションテストというのは残念ながら存在しない。バザールモデルの特徴である多くの目玉によってピアレビュー、テスト、運用によって問題点が発見される。

Linuxの場合、何か新機能を追加したいと思った人は、LKML (Linux Kernel Mailing List)にRFC(Request for Comments)という提案をメールし議論を開始する。多くのカーネルハッカーによって、その仕様および実装案についてレビューがおこなわれる。いろいろな突込みが活発におこなわれる。議論がだいたい収束しつつあるとサンプル実装というかPOC(Proof of Cencept)実装がパッチの形でLKMLに投稿される。そのコードも多くの人達にレビューされる。興味を引かない提案は無視される。コメントもつかない。コードに対する質問やコメントに対しては、メールでやりとりをし、実装上の問題については、再度パッチの形で回答する。何度かやりとりをするうちにパッチは洗練していく。ラフなコンセンサスがまとまるとAndrew Mortonのmm-treeと言われているカーネルに取り込まれる。コンセンサスがとれない場合は無視される場合がある。いろいろな環境で、実際に利用され意図しない副作用等がないか確認され、有用であるというコンセンサスがとれればLinusのKernelにとりこまれる。長い道のりである。

上記のプロセスは多くの人の目玉によるレビュー、検証に依存するのが特徴と言えば特徴である。

変更点はChangelogやgitのコメントに残るのだけど、それによる副作用がどうあるのかは、明示的に書かれる事は少ない。仮に書かれたとしても、何百もある変更点の中から自分に関連する副作用を発見することは現実的ではない。ミドルウェアの実装をしている人は結果として、随分後に、自分に影響がある変更を認識して、途方にくれたりする。

一方で副作用のある変更を一切禁止するというのも現実的ではない。それはOSSの進化や発展を阻害するし、OSSそのものの価値を殺すことになる。

進化の速度を減速しないまま、影響度の大きい意図しない副作用を早期に発見し、その影響を最小限にしたい。意図する副作用であっても、それによるメリットが大きければ、痛みをともなっても導入することが全体の利益になったりするので、その影響範囲についてもなるべく早い段階で議論をしたい。

そのような問題意識に答えるのがリグレッションテストなのである。

リグレッションテストによって、ある程度自動的に前のバージョンとの動作の違いを発見する。動作の違いというのは、必ずしも悪いことではなくて、バグ修正、新機能の追加、性能向上など積極的に変更する価値のあるものもある。そのような動作の違いによって利益を得る人も入ればアプリケーションに影響がある人もいる。全体でみて利益の方が大きければその変更を受けいれるし、影響が大きければ、その動作の違いを最小化する方法をとればいい。その議論のきっかけになるのがリグレッションテストによって発見される動作の違いなのである。

リグレッションテストは開発者と利用者のコミュニケーションツールになるのである。

Linuxのリグレッションテストが広く利用されるようになれば(われわれの願望である)、カーネル開発者とミドルウェア開発者が、それを媒介してプラットフォームの動作について議論できるようになる。ミドルウェア開発者は問題点の指摘をそれを再現するテストによっておこない、カーネル開発者はリグレッションが発生していない事をリグレッションテストによって担保する。パッチの提供者はピアレビューだけではなくカーネルリグレッションテストを通す事を要求されるようになるというイメージである。

カーネル開発者はカーネルの変更がミドルウェアに悪影響をおよぼさづに大胆に行えるようになり、ミドルウェア開発者は安定したカーネルを手にいれられるようになる。

テストという退屈な仕事が楽で楽しい仕事になる。

crackerjack project http://sourceforge.net/projects/crackerjack/

MySQLのマルチコアスケーラビリティとLinux

スラッシュドットの情報。FreeBSDとLinuxでsysbench(MySQLを利用している)の結果が出ている。結論から言うと8コアのAMD64のマシンでスレッド数を上げていくと8スレッドまではLinuxでの性能が良かったが、それ以上になるとがたっと性能が劣化して、FreeBSDのSMPngの実装が勝つ。

下記を参照してほしい。
http://jeffr-tech.livejournal.com/6268.html

MySQL 5.0.2xではSMPスケーラビリティに問題があることは、われわれの性能評価でもあきらかになっていたが、(例：MySQLに対応した評価ツールDBT-1を利用したハードリソース変更によるパフォーマンスへの影響の考察を参照)、OSのSMPスケーラビリティ問題というよりMySQLの実装上の問題だと考えていた。

linux 2.6.18/2.6.20.1上でMySQL 5.0.27(これはスケーラビリティ上の問題が顕著)と5.0.33(スケーラビリティの問題を若干解決した)を評価したグラフを見ると、あきらかにFreeBSD-ULEの実装と比較して、linuxはスケーラビリティの問題がある。スレッド数がコア数(8)を越えたあたりから性能が急激に劣化する。

Linux Kernel Mailing Listでも早速話題になっていて、(http://www.ussg.iu.edu/hypermail/linux/kernel/0702.3/0299.htmlからのスレッドを参照)、Linuxのスケジューラの問題という認識になりつつある。

特に、SMT(IntelのHyperthread)やMC(Multicore)用のスケジューラが悪さをしていそうである。http://www.ussg.iu.edu/hypermail/linux/kernel/0702.3/1142.html

CONFIG_SCHED_SMTとCONFIG_SCHED_MCをオフにした結果が下記に出ている。
http://www.ussg.iu.edu/hypermail/linux/kernel/0702.3/1133.html

http://www.ussg.iu.edu/hypermail/linux/kernel/0702.3/1133/transactions.png

若干現象が良くなっているが抜本的な解決にはなっていない。

MySQLで発見された現象が正しく理解されれば、遠くない将来に問題は解決されるだろう。

いろいろな人がいろいろな評価をしたり、知恵を出したり、コメントしたり、バザールモデルの醍醐味である。

勝手に性能評価(Lingr編)

週末にLingrを利用したチャットイベントがあったそうだ。[JTPA] Lingrイベントの顛末/My Life Between Silicon Valley and Japan

昨日のオンラインサロンは、参加者が集まるにつれてLingrが重くなってしまって残念ながら中止となりました。

実のところLingrの実装がどうなっているかは全く知らないのだが、何百人もわらわら集まってチャットをやろうという心意気が楽しい。素晴しい。やってみてスケールしなかったというのも主催者側は若干凹むかもしれないが、それもいい経験で、むしろそーゆー得難い経験を得られたと考えた方がいい。

Lingrの開発者の江島さんは、梅田さんのブログで再挑戦を表明しているので楽しみにしたい。

さて、今回の経験から江島さんら実装者の皆さんは何を学んだのだろうか？ぜひ情報公開をしてほしいと思うのだが、わたしだったらどうするか勝手に記してみたい。

わたしはネットワーク方面には全く土地勘はないのだけど、システム回りとRDBMSあたりだったら若干の経験があるので、いくつかの教訓めいたことを。

サーバーアーキテクチャの再点検、改善などをあげているが、負荷テストをまづやりたい。そこで、vmstat/iostatをおこない、CPUボトルネックになっているのか、IOボトルネックになっているのか、メモリボトルネックになっているのか、あるいはRDBMSがボトルネックになっているのかをみきわめる。

IOボトルネックなのに、CPUを追加しても意味がないし、CPUボトルネックなのにディスクを追加しても意味がない。何がボトルネックかを定量的に把握するのが一番である。

しかし、vmstatなどではシステム全体の負荷はわかってもどのプロセスに最もコストがかかっているのかという微視的な視点でのプロファイルはわからないので、oprofileを利用してシステムのどこで最もコストがかかっているかプロファイリングする。DBサーバに負荷がかかっているとしたらキュエリの実行プランを出して、適切な検索プランになっているか検討する。

負荷テストで現状の定量的な把握をおこないボトルネック解析、およびそれの対処を実装し、再度定量的に計測する。それを所望のゴールになるまで繰り返す。

上記のテストを繰り返している間は、機能はフリーズして、バグフィックス以外はチェックインしてはいけない。大規模な実験の前にバージョンアップをするというのは最もやってはいけない手なのだけど、外野(わたしの事)は勝手な事を言えるのでここの部分は聞き流してほしい。

vmstatでカーネルのCPU利用率を測定し、それが20%を越えていたらカーネルの処理にコストがかかりすぎなので、システムの実装を見なおした方がいいかもしれない。一方ユーザのCPU利用率が90%以上ならば、アプリケーションプログラムの実装を見直すいい機会になる。

どちらもoprofileのデータがチューニングする時によいヒントを提供するのでそれを利用したい。

1000クライアントを一つのPCサーバでサービスするというのは結構しんどいのではないかと想像するけど実装がどうなっているのか全く知らないので情報公開をまちたいと思う。(Lingr and Comet - 技術解説編)

いずれにせよ、データを取れデータを。(oprofileならなお可)

2月6日の追記：

「梅田サロン中止のお詫び、およびアーキテクチャ変更についての技術詳細レポート」という顛末が公開されている。

http://blog.japan.cnet.com/kenn/archives/003556.html

アーキテクチャの設計寿命

「マルチプロセッサ向けソフトウェアパラダイムとは？」で、

Alphaの開発チームはVAX開発チームの後継で、ある意味DNAを受けついでいるのだが、当時の論文(90年ごろ)で、マイクロプロセッサのスケーラビリティを、クロックの向上で10倍、アーキテクチャの進歩で10倍、マルチプロセッサで10倍、10x10x10=1000倍の性能向上を達成するとかしないとか書いてあって、感心したのを覚えている。
http://blog.miraclelinux.com/yume/2007/01/post_ab8c.html

と書いたのだが、先日たまたま下記の論文を発見した。

いまはなきDEC の技術論文集(digital technical journal)の第４巻第４号がAlpha AXPの特集号である。目次を参照されたい。

Alpha AXP Architecture
by Richard L. Sites
http://www.hpl.hp.com/hpjournal/dtj/vol4num4/vol4num4art1.pdf

この論文はDECのエンジニアリングスピリットが凝縮されている。

アーキテクチャゴールとして下記の4つをあげている。

1. 高性能
2. 寿命が長い事
3. VMSとUnixが動くこと
4. VAXおよびMIPSからの容易なマイグレーション

3、4はマーケットからの強い要請であるが、純粋な技術的なチャレンジは１の高性能と２の寿命が長い事ということになる。

アーキテクチャの寿命というのを15年から25年くらいに設定して、その期間に設計上の限界となりそうなものを注意深く避けている。

例えば32ビットのメモリアドレスは間違いなく当時の設計上の限界だったので64ビットにした。

We also considered how implementation performance should scale over 25 years. During the past 25 years, computers have become about 1,000 times faster. Therefore we focused our design decisions on allowing Alpha AXP system implementations to become 1,000 times faster over the coming 25 years.

過去25年をふりかえってみるとコンピュータは1000倍速くなった。そこでAlpha AXPシステムの実装が次の25年で1000倍速くできるように設計の決定に注力した。

In our projections of future performance, we reasoned that raw clock rates would improve by a factor of 10 over that time, and that other design dimensions would have to provide two more factors of 10.

クロックレートは10倍、それ以外の設計要素で10*10倍と推測している。

10*10倍するための設計要素の一つは、multiple instruction issue(同時に複数の命令を実行する)で、もう一つは、マルチプロセッサである。

そこでアグレッシブなmultiple issueを妨げる要素を徹底的に排除する。例えば、コンディションコード、グローバルな例外、ストリングレジスタ、遅延分岐、正確な演算例外、等々の従来のアーキテクチャにみられた要素を排除している。

また共有メモリマルチプロセッサのモデルを当初から想定している。厳密なメモリへの書きこみ順は共有メモリマルチプロセッサでは性能を限定するので、それを仮定しない。例えば、メモリA、メモリBの書きこみは、他のプロセッサからはA、Bの順ではなく、B、Aの順で見えるかもしれない。これにより高性能な共有メモリマルチプロセッサの実装が可能になる。

などなど、当時知られていた性能上の問題になりそうなものを徹底的に排除した設計になっている。

Alpha AXPが発表されてから15年。その開発はDECにとって最大のプロジェクトであった。DECという会社はなくなってしまったが、Alpha AXPで開発された、高速化技法は今も生き残っている。コンピュータアーキテクチャの設計寿命というのは正しく設計されれば15年〜25年と長いのである。