MIRACLE
メールサービス申込 ユーザー登録 パートナー情報
お問い合わせ FAQ サイトマップ
MIRACLE LINUXの特長 製品紹介 サービス案内 購入 サポート 技術フォーラム

プロフィール

吉岡 弘隆 - よしおか ひろたか

日本OSS推進フォーラム ステアリングコミッティ委員
OSDL Board of Directorsを歴任
カーネル読書会主宰

2000年6月、ミラクル・リナックスの創業に参加。
95年~98年、米国OracleにてOracle RDBMSの開発をおこなっていた。
98年にNetscapeのソースコード公開(Mozilla)に衝撃をうけ、オープンソースの世界に飛びこみ、ついには会社も立ち上げてしまう。
2008年6月取締役CTOを退任し一プログラマとなった。

ミラクル関連リンク

採用情報

サイト検索

2008年9月

  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30        

« 2006年8月 | メイン | 2006年10月 »

第67回カーネル読書会、ビデオ公開

第67回カーネル読書会のセミナー部分のビデオを公開した。今回は

お題: glibc malloc について
発表者:小崎さん

malloc関数はlibcの中でもっとも使用頻度が高い関数の一つでありながら、そ
の実装の詳細は意外なほど知られていません。

Unix誕生当初のプログラミングスタイルでは、ほとんどのデータはスタックと
グローバル変数に格納されており、mallocの使用頻度は低かったようです。し
かし、今日ではGUI、スクリプト言語、C++といったmallocを多発するソフトウェ
アが極めて一般的になり、mallocの性能の重要度は増しています。

こうした点に注目して、素朴な malloc では何が問題だったのか。また、
glibc malloc がどういった点に注力してチューニングされているのか。といっ
た点を説明できれば。と思います。

資料はYLUGのホームページからダウンロードできる。

ビデオ撮影、編集、Googleへのアップロードはびぎねっとの伊藤さんのご尽力による。どうもありがとうございました。

梅田望夫氏との対談イベントもそうだったのだが、こうやってカーネル読書会とか各種勉強会、セミナーとかをどんどん無償でネットワークにアップロードするというスタイルが一般化するとまた違った可能性が広がっていくようでいて大変面白い。

内容はmallocに関する技術的な詳細の説明である。mallocという関数は厳密にいえばCのライブラリ関数なので、カーネルのシステムコールではないのだが、一般アプリケーションから非常によく使う関数の一つであり、カーネル読書会の題材としてはぴったりのものである。メモリ管理というのはまさにカーネルの最も重要な機能の一つなので、カーネルやライブラリがそれをどのように実装しているかを理解することは大切である。

オープンソースなので実装の隅々までオープンに議論できるのがうれしい。カーネルの専門家ではなくても、アプリケーション開発者の立場から、いろいろ質問したり、突っ込みを入れたりできるのがうれしい。カーネル開発者(ライブラリ開発者)にとってみれば自分が提供するサービスがどのように利用されているかの声を聞けて双方にとって有益な情報交換になる。

今回もmalloc/freeのコストについてRubyの笹田さんがRubyでのメモリ管理の観点から細かい突込みを入れていたが、OSとアプリケーション(この場合はプログラミング言語の実装)の境界を越えて、いろいろ議論できるのが楽しい。

いっそのこと、カーネルやライブラリのレイヤではなく、もう少し上のレイヤ(例えばスクリプト言語とかRDBMSとか)で自前のメモリ管理機能を持ってがしがし最適化するのもありなんではないかというような議論も当然でる。ライブラリは汎用化しなくてはいけないので、ある用途に徹底的に最適化することはできないがRubyならRuby、PerlならPerl、あるいはPostgreSQLならPostgreSQLなりのメモリ管理システムを持ち、カーネルに独立して徹底的にメモリ管理を最適化する。キャッシュミスを削減したりマルチコア、マルチスレッドに最適化するなどいろいろなアイデアが出てきそうである。

このような議論は、カーネル、ミドルウェア、スクリプト言語といった縦串をまたがった議論になる。オープンソースなので自由にその境界線を設定できる。一つの場所に集い自由に議論をする。そこにソースコードがあるからこそそれが自由にできるのである。

小崎さんのブログ、
革命の日々!
カーネル読書会で講演してきました

未来のいつか/hyoshiokの日記
第67回カーネル読書会

Linux Kernel 2.6.18とCache Pollution Aware Patch

9月20日に最新のLinuxカーネルが公開された。最近ではだいたい3ヶ月程度で新バージョンが公開されているというペースである。

  2.6.12  2005/06/17
  2.6.13  2005/08/29
  2.6.14  2006/10/28
  2.6.15  2006/01/03
  2.6.16  2006/03/20
  2.6.17  2006/06/18
  2.6.18  2006/09/20

実はこのバージョンには、わたしが書いた cache pollution aware patch というのが入っている。パッチそのものは昨年の今頃に書いたもので、すぐにAndrew Mortonのmmツリーと呼ばれるものにはマージされたのであるが、Linus Torvaldsの本家のツリーにはなかなかマージされていなかった。

Cache Pollution Aware Patchというのは、一言で言うと、コンピュータの中央処理装置(CPU)にはキャッシュというメモリアクセスを高速化するハードウェアが付いているが、ちょっとしたトリックを使って、その処理をさらに高速化するというものである。

コンピュータはムーアの法則によって約18ヶ月で半導体の集積度を倍に向上させてきた。CPUの処理速度もそれに比例して年々向上してきた。メモリの速度はCPUの処理速度の向上に比べ遅いペースで向上してきているので結果としてCPUから見てメモリアクセスというのは遅い処理に見えてくるようになった。

最近のプロセッサだとメモリへのアクセスは200〜300クロック程度かかる。CPUクロックが2GHzのマシンだと1クロックあたり0.5nsec(ナノ秒=10億分の1秒)なので、100nsec〜150nsecかかる。それでも随分速いように思えるが、レジスタへのアクセスが2クロック程度なので100倍程度遅いことになる。

そこで、遅いメモリとレジスタの間にキャッシュと呼ばれる容量は小さいけど高速のメモリを置き、メモリアクセスを高速化する。1次キャッシュ(L1と呼ぶ)はインテルのPentium 4だと8KB(キロバイト)で202クロック程度でアクセスできる。キャッシュにデータが載っていればメインメモリにアクセスするより10100倍程度速くアクセスできる。

キャッシュのサイズは小さいので、どのようなデータをキャッシュに載せ、どのようなデータをキャッシュに載せないのかが性能を左右することになる。必要なデータがキャッシュにある時、それをキャッシュにヒットしたとよび、キャッシュにない時、キャッシュミスしたとよぶ。

性能を向上させるためには、いかにしてキャッシュミスを減らすか(キャッシュヒットを増やすか)というのが重要になってくる。

どのようにキャッシュにデータを載せるかというアルゴリズムは広く研究されている。通常はCPUがメモリにアクセスする時、まづキャッシュに当該データが載っていないか調べ、載っていればキャッシュからデータをとってきて(速い)、載っていなければ、メモリにアクセスし(とても遅い)、キャッシュに載せる。わざわざキャッシュに載せるのは、一度アクセスされたデータは近い将来またアクセスされるかもしれないので、それを期待してとりあえづキャッシュに載せておくのである。これを時間的局所性があると言うが、これは思いのほか上手くいく戦略である。

またメモリからキャッシュにデータを載せる時、アクセスするメモリの周辺のデータも一緒に持ってくる。Pentium 4の場合、64バイトないし128バイトをキャッシュに載せる。これはあるデータにアクセスしたらその近傍のデータにもアクセスする可能性が高いと仮定していて、そのような性質を空間的局所性があると言うが、これも思いのほか上手くいく戦略である。

メモリアクセスのスピードとCPUの性能向上のギャップは年々拡大傾向にあるので上手にキャッシュを利用するアルゴリズムは益々重要になってきている。

さてCache Pollution Aware Patchなのであるが、キャッシュポルージョン(cache pollution)というのは、キャッシュにデータを載せる時、キャッシュのサイズは限られているのでキャッシュ上のデータを捨てないといけないが、その時、すぐに利用される有効なデータを追い出してしまい、結果としてすぐにキャッシュミスを発生させるような状況をさす。

時間的な局所性がない(すぐに再度アクセスされない)データをキャッシュに載せるのはキャッシュポルージョンを発生させるのでよろしくない。

時間的な局所性があるのかないのかというのは通常はなかなかよくわからないのであるが、今回のパッチの作成にあたっては、oprofileというカーネルプロファイリングツールを利用して、カーネルのどこでキャッシュポルージョンが発生しているかを特定した。厳密に部位を特定できたのでパッチの作成そのものはそれほど困難ではなかった。

インテルのPentium4/Xeonプロセッサはデータをアクセスする時にキャッシュをバイパスする命令がある。今回のパッチではカーネル中のキャッシュポルージョンを発生している部分でキャッシュをバイパスする命令を利用しキャッシュポルージョンを効果的に削減した。

iozoneというベンチマークを利用した性能評価ではwrite()システムコールにおいて約10%の性能向上が確認できた。

Linux Kernel 2.6.18
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.18.tar.bz2
http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.18

Cache Pollution Aware Patch (わたしが作ったパッチ)
http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c22ce143d15eb288543fe9873e1c5ac1c01b69a1

未来のいつか/hyoshiokの日記
cache pollutionに関する記述がいくつかある。
http://d.hatena.ne.jp/hyoshiok/searchdiary?word=cache%20pollution

2005年度オープンソースソフトウェア活用基盤整備事業
「OSS性能・信頼性評価/障害解析ツール開発」
OS層
〜CPUスケーラビリティ評価編〜
http://www.ipa.go.jp/software/open/forum/development/download/051115/OS-cpu.pdf

訂正:L1キャッシュのアクセスを20クロック程度ではなく、2クロック程度と訂正しました。L1キャッシュとメモリのアクセスの性能比は100倍程度になります。

大規模ソフトウェアをgdbを利用して微視的視点から理解をする

たまたま講読している php-dev というPHPの実装を日本語で議論するメーリングリストで「mbstring の新関数」というスレッドがあった。新規にmb_list_encodings_alias_names()という関数を追加したらしいのだが、既存のmb_list_encodings()とどう違うのかどうかという議論がわきおこっている。

ここでは、mb_list_encodings()を題材にどうやってphpの実装を理解していくか、そのプロセスを記述してみたい。もちろんこの方法がベストであるとか、この方法でなければいけないとか、いつでもこの方法が適用可能だなんてことを主張するつもりは一切ないが、一つの例として大規模ソフトウェアの微視的理解方法を理解いただきたい。

1) mb_list_encodingsがどこで利用されているかを知る。

$ cd /usr/src/php-5.1.4
$ time find -type f|xargs egrep -l mb_list_encodings_alias_names

real    0m21.909s
user    0m0.088s
sys    0m0.606s

新規に追加された関数mb_list_encodings_alias_names()は現在のバージョンでは利用されていない。(あたりまえだ)

$ time find -type f|xargs egrep -l mb_list_encodings
./ext/mbstring/mbstring.c
./ext/mbstring/mbstring.h
./ext/mbstring/.libs/mbstring.o
./sapi/cli/php
./libs/libphp5.so
./.libs/libphp5.so

real    0m0.450s
user    0m0.180s
sys    0m0.248s

既存のmb_list_encodingsは、mbstring.{c|h}で利用されている。。*.oとかもgrepでひっかかる。実行時間が最初は21.909秒、今回は0.450秒で激減しているのは、ページキャッシュに当該ファイルが載ってしまったためと考えられる。

2) ソースファイルを読む。mbstring.c

/* {{{ proto array mb_list_encodings()
   Returns an array of all supported encodings */
PHP_FUNCTION(mb_list_encodings)
{
    const mbfl_encoding **encodings;
    const mbfl_encoding *encoding;
    int i;

    array_init(return_value);
    i = 0;
    encodings = mbfl_get_supported_encodings();
    while ((encoding = encodings[i++]) != NULL) {
        add_next_index_string(return_value, (char *) encoding->name, 1);
    }
}

3) 実行してみる。

$ php -r ' print_r(mb_list_encodings());'
Array
(
    [0] => pass
    [1] => auto
    [2] => wchar
    [3] => byte2be
    [4] => byte2le
    [5] => byte4be
    [6] => byte4le
    [7] => BASE64
    [8] => UUENCODE
    [9] => HTML-ENTITIES
    [10] => Quoted-Printable
    [11] => 7bit
    [12] => 8bit
...
)

4) デバッガで実行する。

ブレークポイントをどこに設定するか?

当該ソースコードは
PHP_FUNCTION(mb_list_encodings)
となっていて、PHP_FUNCTION()というマクロを利用してmb_list_encodings()を定義している。PHP_FUNCTIONの定義を丹念におっていけば、どのように展開されていくかが分るのだが、もっと直接的な方法でしる。

先のfind |xargs egrepというイディオムで当該関数を含んだファイル一覧が得られたが、いくつかのバイナリファイルにも含まれていることがわかる。そこで力づくで

$ strings ./sapi/cli/php|egrep mb_list_encodings
zif_mb_list_encodings
mb_list_encodings

とするとzif_mb_list_encodings()がどうも当該関数名だということがわかる。

(gdb) b main
Breakpoint 1 at 0x82824e0: file /usr/src/php-5.1.4/sapi/cli/php_cli.c, line 581.

取り合えづmainにブレークポイントを設定した。

(gdb) b mb_list_encodings
Function "mb_list_encodings" not defined.
Make breakpoint pending on future shared library load? (y or [n])

予想どおりmb_list_encodingsという関数はない。

(gdb) b zif_mb_list_encodings

Breakpoint 2 at 0x8102931: file /usr/src/php-5.1.4/ext/mbstring/mbstring.c, line 2327.

ビンゴである。

実行する。

(gdb) run -r ' print_r(mb_list_encodings());'
Starting program: /usr/local/bin/php -r ' print_r(mb_list_encodings());'
[Thread debugging using libthread_db enabled]
[New Thread -1208068416 (LWP 4872)]
[Switching to Thread -1208068416 (LWP 4872)]

Breakpoint 1, main (argc=3, argv=0xbfe1e994)
    at /usr/src/php-5.1.4/sapi/cli/php_cli.c:581

(gdb) c
Continuing.

Breakpoint 2, zif_mb_list_encodings (ht=0, return_value=0xbfe1e580,
    return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
    at /usr/src/php-5.1.4/ext/mbstring/mbstring.c:2327

当該ブレークポイントで停止した。

スタックフレームを見ると呼び出し系列が一目瞭然でわかる。

(gdb) bt
#0  zif_mb_list_encodings (ht=0, return_value=0xbfe1e580,
    return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
    at /usr/src/php-5.1.4/ext/mbstring/mbstring.c:2327
#1  0x082222a8 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe1e580)
    at /usr/src/php-5.1.4/Zend/zend_vm_execute.h:200
#2  0x08221c8d in execute (op_array=0x950635c)
    at /usr/src/php-5.1.4/Zend/zend_vm_execute.h:92
#3  0x0820057c in zend_eval_string (str=0x950635c "\004", retval_ptr=0x0,
    string_name=0x841e72f "Command line code")
    at /usr/src/php-5.1.4/Zend/zend_execute_API.c:1116
#4  0x082006c8 in zend_eval_string_ex (
    str=0xbff0f932 " print_r(mb_list_encodings());", retval_ptr=0x0,
    string_name=0x841e72f "Command line code", handle_exceptions=1)
    at /usr/src/php-5.1.4/Zend/zend_execute_API.c:1150
#5  0x082831b2 in main (argc=3, argv=0xbfe1e994)
    at /usr/src/php-5.1.4/sapi/cli/php_cli.c:1181

10_1 あとはステップ実行なりなんなりして微視的な理解を深めるだけである。

ここまでに到達するのに30分とかからない。

hyoshiok 2.0

技術がまったくわかっていない上司と最先端の技術をやすやすと使いこなす部下という凸凹コンビによる最強のチームワークが日本のお家芸みたいなもので、部下は部下で、「ったく、上は全然わかっちゃね〜」といい、上司は上司で、「近頃の若いやつは」と言う。デスマーチだなんだといいつつも、どーにかこーにか物はできあがって予定調和の世界である。この上司という人、技術はわかっていないフリをするのだが実はそんなことは百もお見通しで、プロジェクトを成功させるのは技術(だけ)ではなくて、人だということをしっかり理解している。部下に「ったく、しょーがねーなぁ」とぶつぶつ言わせるのはモチベーションをキープさせるための巧みな作戦で、部下はその作戦にまんまとのかっちゃっているのである。上司は技術はわからないが人は見ているのである。

そうすると、上司部下の凸凹コンビで、上司のパターンを技術力、人間力で分類すると4つになる。すなわち、1) 技術力もあり、人間力もある、2)技術力はあるが、人間力はない、3)技術力はないが、人間力はある、4)技術力も人間力もない。

4)のパターンの人はマネージャという職には向かないので、なんかの間違いでなっちゃったわけで、これはここではあまり深入りしないで、1から3のパターンについて考えてみる。

プロジェクトを遂行するのは人であって機械ではない。この当たり前の事実を今一度確認しよう。価値を生産するのは人であり機械ではない。どのようにして人がモチベーションを高め、あるいはモチベーションを下げるか、わかっているようでいてわかっていないが、動物的な勘として人を鼓舞する力をもっている人と不得意な人がいるのは、皆さんご承知のとおりである。

とはいうものの、PMBOKをはじめとする科学的(ここでいう科学的というのは第三者によって再現可能なプロセスに定式化されているという程度のニュアンスである)な手法というものはあって、世の中より上手くいく確率の高い手法というのが知られている。ベストプラクティスとか経験則とか言うものもある。

先程の技術力はないけど、人間力があるという凸凹コンビの上司は、人を動かす天才で、経験と勘によってPMBOK的な手法を何らかの方法によって獲得しちゃった人なのかもしれない。あるいはPMBOK的な手法は使わづに、「ちょっと一杯帰りに行こう」というコミュニケーション1.0的な古典的な日本のサラリーマンお家芸が得意なのかもしれない。

そーゆーネバッコイ人間関係が性にあわないという部下というのも当然いるので、そうすると古典的なコミュニケーション手法ではなかなか人間力を発揮できなくて、難しい立場においこまれる。

カーネル読書会のセミナー+ピザパーティという形式は(勉強会のデファクトスタンダードと言っても過言ではない(笑))、日本人のセミナーでは質問できないという奥ゆかしい(?)性格を逆手にとって、ピザパーティの時につっこんだ議論をしてくれという実に人間力に溢れた企画運営なのである。ピザパーティに突入する前のセミナーの時にガンガン質問してもいいんだよ、ここで質問力を実践的に高めてくれという訓練の場でもあるんだけど、質問しているのはいつもわたしを含め数人なので、効果があるかどうかよくわからない部分もある。話がづれた。

技術は現場にある。微視的な積み重ねである。人間力にあふれた凸凹コンビの上司はそれを本能的にか意識的にかそれを理解している。若手に技術的な決定権を委譲する。若手によちよち歩きでも実践させる。あぶなっかしくてもそれをやらせる事で技術者として一歩成長する。その機会を提供する。

技術をわからないフリをしても人間を見ている。技術者を大切にするということは人間を大切にするということである。そうすると2)の技術力はあっても人間力がない上司というのはプロジェクトにとって微妙に難しい立場にいるというのがわかる。2)の人は技術一筋でがんがん行った方が本人も幸せだし周りも幸せである。

で、凸凹コンビの話にもどるのだけど、わたしの場合は、技術力をどんどん尖らせていったらどうなるかみたいな感じできたわけで、人間力は正直いかがなものかという空気がなくはない。オープンソースでバザールモデルをまわすには人間力というか人としての魅力がなければにっちもさっちもいかないのだけど、実のところバザールモデルの頂点に立ったことがないので経験値が不足しているのは否めない。でも、よく考えてみたらカーネル読書会も一つのコミュニティなわけで、それを7年あまりまがりなりにも回してきたという事をみれば、意外といけているかもと自画自賛しちゃったりする。意識して人間力をたかめれば、hyoshiok 2.0とバージョンアップできるかもしれない。ふむふむ。それって仕事にも絶対プラスに反映できると思うし、今までのコミュニティでの経験を生かし、技術者を大切にする、すなわち人間を大切にする組織を設計し実装するという凸凹コンビの上司になろうと思った。hyoshiok 2.0 の決意表明である。

雑種路線でいこう
技術大国日本を育み押しつぶした国家総動員体制の亡霊

アンカテ(Uncategorizable Blog)
技術大国日本を食い物にしたのは誰だ!

アンカテ(Uncategorizable Blog)
オープンソースはわからないくていいから部下のことを理解しなさい

U-20プログラミングコンテスト

U-20プログラミングコンテスト

U-20(20歳以下)プログラミングコンテストの入賞作品が発表になった。わたしも審査員の一人なので入賞作品についてじっくり拝見させていただいた。

メディアの反応
「曇りガラスに描いた絵から水滴がぽたり」--経産省の20歳以下限定プログラミング・コンテスト,最優秀賞決定(日経ITpro)

ITのある教室:U−20プログラミングコンテンスト 優秀作品決まる(MSN毎日インタラクティブ)

今回も力作ぞろいで審査は非常に楽しかった。プログラミングの原点を教えてもらった感じだ。なぜ人はプログラムを書くのだろう。プログラミングコンテストに応募するU-20のあなたたちはプログラミングが好きで好きでたまらないのだろう。三度の飯よりも好きなのかな。審査会の席で、「今回のプログラムを作ってみてよかった点は何ですか」と質問したところある応募者が「自分の作ったプログラムを友達に見せたら、すげーと感動してもらった事がよかったことです」と答えていたのが強く印象に残っている。プログラムが自分を表現するメディアになっていて、自分と友達をつなぐ架け橋になっているというような感じなのだろうか。

ゲームやお絵描きツールやプログラミング言語やらいろいろなジャンルの力作があつまって最優秀作品を選ぶのには大変難しかった。寿司と焼肉どっちが素晴しいかを選ぶようなものである(例えが変ですいません)。

仕事で眠いプログラムを作っている人達はU-20のプログラマの作品をじっくり観賞していただきたい。プログラムを作る楽しさ、喜び、プログラムを使って友達をびっくりさせる感覚などなど、表現としてのプログラミングの、テクニックとしてはまだまだ稚拙な部分があるかもしれないが、可能性を感じさせる作品になっている。

わたし自身は審査員として今年で3回目となるのだが、毎回非常に楽しく審査をしている。はてなで書いた日記も参照のこと。
(http://d.hatena.ne.jp/hyoshiok/20060425#p1 http://d.hatena.ne.jp/hyoshiok/20051005#p1 http://d.hatena.ne.jp/hyoshiok/20041002 http://d.hatena.ne.jp/hyoshiok/20040829)

オープンソースの生産性

オープンソースは技術革新を促進しないのか?

オープンソースの生産性はサルまねだから高いという議論があったが、誰も反駁しないのでいくつかのデータをあげることにする。先日エンタープライズOSSというカンファレンスでMichael Tiemann氏(OSI会長)の講演を聞く機会があった。(ログはこちらにおいた)

User Innovation Toolkits (von Hippel, 2002)という研究を引用して、1)85%の技術革新はユーザー主導であった、2)5/6の技術革新はproprietaryだと失敗する、3) webのような技術革新はproprietryモデルでは不可能である。オープンソースは技術革新をドライブするエンジンである。

OSSの力
sourceforge.netには120万人の登録ユーザーがいて、10万のプロジェクトがある。2002年と2005年のFLOSSの調査によると約50万人のOSS開発者が週に11時間以上OSSに関与している。これは週500万時間に相当する。その動機は1)楽しいから2)スキルの向上3)社会にとって有意義だから。マイクロソフトは61000人の従業員がいるので週500万時間に相当するためには、週80時間働かなければいけない。マイクロソフトは年間60億ドル研究開発に投資をしている。週500万時間だとすると一時間あたり25ドル以下になる。マイクロソフトはセキュリティ上の問題を修正するのに20億ドルも使っている。

ソフトウェアの品質
平均的なソフトウェアの欠陥は千行あたり20〜30個と言われている。2004年の時点でLinux kernelは570万行だったので、10万個以上の欠陥があるはづであるが、985個しか発見されていない。2005年までに全ての重要なバグは修正されたが複雑度は4.7%上昇しただけだった。2006年32個の別のOSSプロジェクトを計測したが、最悪(PHP)のプロジェクトですら通常のものより50倍良かった。

まとめるとOSSは、通常のソフトウェアよりも欠陥が少なく、世界最大のソフトウェア会社よりも開発力があり、技術革新を促進している。

gdb/xemacs/cscopeの使い方

プログラムの状態は変数の値の変化によって変化していくわけだが、変数は、宣言され、値を代入され、参照されるなどして利用される。
ポインタによって字面では変数が登場しなくても参照、変更される事もあるので油断禁物である。
またグローバル変数が嫌われるのは、ソースコードを局所的に調べていてもその代入、参照の範囲がつかめないからである。別のディレクトリに格納されている見た事も聞いた事もないファイルで変更されていて、当該ディレクトリをgrepしただけでは発見できなかったりする。
ローカルな変数ならばソースコードを静的に読解していけば、宣言、代入、参照それぞれが局所化しているので簡単に理解できる。
変更の影響もローカル変数ならば局所化されているがグローバル変数だとどこに影響が発生するかよくわからないのである。

6

さてブレークポイントを設定し、そこで実行が停止したとする。最初の仕事はその関数がどこから呼ばれているかの確認である。btと打つとスタック情報を表示する。バックトレース(back trace)でbtとなる。

7 8

 

次に変数の値を表示する。その変数になじみがなければ、どこで宣言されているか、どこで代入されているか(初期化されているか)、どこで参照されているかを、ざっと見る。代入されないで参照されるのはバグの元なので注意が必要である。一方、代入されているのに参照されないのもバグの元なのでじっくり確認する。Cの場合は宣言されないで利用されるのはコンパイルエラーになるので、実行時には通常は宣言がされていないということはない。

9

 

変数がどこで利用(宣言、代入、参照)されているかを調べるにはfind|xargs egrepという力技もソフトウェアの規模が小さい時は悪くないが、さすがに大規模なソフトウェアだと時間がかかってしまって精神的なストレスがたまる。そこでクロスリファレンスツールのcscopeの登場である。

xemacsとcscopeで対になって使うと百人力である。cscopeのtarballを展開して cscope/contrib/xcscope/ にファイル(xcscope.el)があるのでxemacsのパスのとおっているディレクトリにおく。

あとは、注目する変数について、どこで利用されているかをブラウジングしつつ、値を確認(print)していく。これを繰り返すのである。

ユメの続き

先日の対談イベントの話を延々続けてもうしわけないのだがもう一つ蛇足ついでに書かせていただきたい。

9月1日にイベントをやって、その日のうちにログをアップする方はいるは、日経ITproの高橋さんには詳細なレポートを夜中に掲載していただいた。プロフェッショナルの方のレポートでは最速である。その後、怒涛のようにブロガーの皆さんの感想、コメント、批評が続き、音声ファイルのアップYouTubeへのアップになる。

梅田さんのエントリーには今現在142のはてなブックマークと12のはてな日記での言及がある。高橋さんの記事には193のはてなブックマークと6のはてな日記での言及があり、現在も増加中である。当初は、はてなではYouTubeの画像が張れなかったのだが(わたしの日記では当初から張れていた)、伊藤さんが素早く「はてなダイアリーに YouTube が貼れる」と実装してしまう。(伊藤さんが実装したのかどうかは実はよく知らないのだけど、少なくても、はてなの誰か)
弾さんも弾さんで「1998年じゃ遅すぎる」、「サルでも生産性が上るオープンソース」、「サルが『オリジナル』を越えるとき」の三部作から「サルマネだってただじゃない」、「javascript - youtube selector + 勝手に添削」でYouTubeの張り方まで教えていただいている。はてなのブックマークで注目度を見てみると、38/5161/1238/419/019/0、それぞれ、はてなブックマーク数/はてなでの言及数となる。
皆さんの感想、コメント、批評を楽しく読んでいるのだが、(普通これほどまでに反応がないので)、おおむね好意的だけど、やはり批判的なコメントもある。それも一切合切含めてその反響を感じてみると、1)対談イベントに参加した方が一次情報として発信、2)日経ITProなどのメディアを見ての感想、言及、3)YouTubeないし音声ファイルを見聞きしての感想、言及、4)それらの感想への言及と二重三重へと輪がひろがっていくのを当事者として経験できたのは貴重であった。メディアを見ての感想なんかは、ああそういう解釈をするのかぁ〜という他人事の感想を持ってしまって自分の口から出たものではないという感じを持った。

多くの感想、コメント、批評は可能な限り目を通しているつもりだが、印象に残ったのは、やはり個人的なものである。あえて二つ言及させてほしい。

Dude...
Who knows hacker is
http://www.sssg.org/blogs/naoya/archives/609
『僕は当日ボランティアスタッフとして参加したので、対談を見たのはわずか5分くらいでした。そのときはちょうど、1998 年のネットスケープのソースコード公開の話をされていました。(映像でいうと 3 of 9 です)1998 年といえば、ちょうど初めてコンピュータプログラミングの勉強していた学生のときでした。当時、僕はネットスケープのブラウザを愛用していて、そのソースコードを公開されたと知ったときはびっくりして、このブラウザのソースコードを見れるんだと思って、こぞってダウンロードしたことを今でも覚えています。当時は、インターネットの回線スピードも 128kbps で、約 20 MB くらいのソースコードを一生懸命ダウンロードしました。やっとダウンロードして、展開したあとあまりの量の多さにどうやってみようとどうやってコンパイルするのだろうかと思っていたら、当時吉岡さんがソフトウェアデザイン誌でモジラの解剖という記事をみつけて Windows 上でコンパイルしたことを覚えています。あれから、約8年オープンソースはあいかわらずの勢いですごいスピードで進化しています。』

当時わたしはネットスケープのソースコードに熱狂して「モジラの解剖」というソースコードの解析をテーマとした日記のようなものを書いていて、それを題材にソフトウェアデザインに記事を書いたのである。あの熱気を誰かに伝えたくて日々書いていたのだけど、それを読んだ人と8年後に巡り会えるというのもインターネットの奇跡かなあと感慨深いものがあった。

また、
aide-memoire d’Hidekoji
http://d.hatena.ne.jp/hidekoji/20060903/p1
『対談イベントの後にちょこっとだけ梅田さんや吉岡さんとお話する機会があったのですが、普段Blogや本でしか知りえない方と直接お会いしている状況が何か不思議な感じで面白かったです。ちなみに、吉岡さんには10年くらい前まだ吉岡さんがU.S Oracleにいらした際に、ファンレターのようなメールを出したことがあって、その話をしてみたら、何か感慨深そうに(?)されていました。ちょっとほろ酔いの吉岡さんが人を不幸にするような*2仕事のやり方は間違っている!モノ作りは大手のベンダーにいなくても「はてな」のような会社でバリバリできるのだ!と強く語っていらしゃっていたのがとても印象的でした。』

失礼ながらhidekojiさんのメールは全く記憶にはなかったのだが若い人が新しい事にチャレンジする時、わたしの基本的なスタンスとしては「がんがんやっちゃえ〜」という根拠のない(?)励ましみたいなエールをおくったりするのだが、そのような趣旨のメールを返信したらしく若干気恥ずかしくもあり不思議な感じがした。今回のボランティアスタッフは梅田さんのJTPAツアーの参加者で十数名の中に二人も縁のある人がいたことを大変不思議に思うとともに、ブログもそうだけど何かを発信していればポジティブなものもネガティブなものも含めて自分に戻ってくるのだなあと感慨深かった。

カーネル読書会に参加したいという若い人もいたし出会いのつみかさねでC今の自分がいるのだなあと実感した次第である。

梅田さん、ボランティアスタッフの皆さん、参加者の皆さん、そして多くの感想、コメント、批評を頂いた皆さん、どうもありがとうございました。

はてなというへんな会社の作り方

梅田氏との対談イベントで一番面白かったところは最後の10分かと思う。それまではオープンソースのある意味で言うと昔の話でシリコンバレーのビジネス風土とかあんまり関係のないお話を延々続けてしまって若干凹み気味なのだけど、最後の10分は取りあえず聞きたいこと(山のようにある聞きたいことのほんの数%)を聞けたのでよしとしたい。

詳しくはYouTubeの映像を見ていただくとして、普通のことをしていたら普通の会社になってしまう。mixiとは別の方向で行く。という趣旨のお話は面白かった。この路線がどうなるかは常識では計り知れないけれど、そうである分がんばってほしい。はてなにとって成功というのはどんなことを言うのだろうか?上場とかそういうことでないというのはなんとなく想像できるが、ではいったい彼らは何を目指しているのだろうか?

もう少し突っ込みたかったが時間切れになった。

1998年とはなんなのか?

対談イベント(「シリコンバレーのビジネス風土」と「オープンソースの思想」)というのはまことに不思議な経験である。何が飛び出すかわからない。観客はなうてのブロガーと梅田望夫さんのファン100人強。一列目に陣取ってちゃちゃを入れる人もいる。「シリコンバレー精神」(ちくま文庫)の出版記念イベントでもある。

1998年では遅い。そりゃそうなのだ、1998年はフリーソフトウェアをビジネスマンが発見しそれをオープンソースソフトウェアというブランドにした年なのだから。弾さんはLAMPをあげているがLAMPというラベルをつけるのですらオープンソースソフトウェア以降の話である。せめてGNU emacsくらいを持ってきて欲しかった。

GNUプロジェクトが始まって約20年、Linuxが15年、オープンソースが約8年である。

1980年代にGNU manifestを読んで、正直心を揺り動かされなかった。インターネットには強く心を揺さぶる何かがあったがGPLの思想を理解するまでにはいたらなかった。それが今ではコードを書くならGPL以外ありえないなあなどと言っているのである。

Linux World Expo/Tokyo基調講演「OSS進化論」で自分のポジションについて記した。GNUプロジェクトが発足した当時、インターネットが一般的でなかったこと。インターネットの勃興とXMosaicのこと。Netscapeの決断とOSSの登場のこと。フリーソフトウェアとオープンソースソフトウェアの違い。そしてソフトウェア開発モデルとしてのバザールモデルの革新性。

そして98年以前のOSS紀元前はバザールモデルが前提としているブロードバンドインターネットはなかったしコミュニティの規模も限られていた。

まあ、若い世代にとってはOSSなんてのは当たり前の空気のようなものなので、それを今さらすごいすごいと言っているのはおじさんの戯言みたいなものなのかもしれないけど。

オープンソースの生産性が高いというお話については別の機会にまとめたいと思う。

梅田望夫氏との対談イベント:「シリコンバレーのビジネス風土」と「オープンソースの思想」

 本日(9月1日)、梅田望夫さん対談イベントをします。どんなイベントになるか今から楽しみであるが、ここでもおって報告をするので注目しておいてほしい。トラックバックや感想をお待ちしています。(日付の間違いを訂正した。ちなみに9月4日はわたしの誕生日です)

9月2日

やりました、対談イベント。オープンソースの話が多すぎた。もっと、梅田さんにはてなの話とかベンチャーの話を聞けばよかったと反省している。

YouTubeでの映像。

はじめに (1/9)

    * http://www.youtube.com/watch?v=t2-Uk_cIctc

エンジニアから見たシリコンバレー精神 (2/9)

    * http://www.youtube.com/watch?v=TxUtXWBIyyo

オープンソース体験 (3/9)

    * http://www.youtube.com/watch?v=jlEsYXXVFgI

5年前を振り返って (4/9)

    * http://www.youtube.com/watch?v=YHnaTZqtcoE

オープンソースとビジネス (5/9)

    * http://www.youtube.com/watch?v=uFf5byohb94

オープンソース組織とオプティミズム (6/9)

    * http://www.youtube.com/watch?v=5okpPOedisE

インターネット企業とオープンソース (7/9)

    * http://www.youtube.com/watch?v=ttbBd1KJ-JE

「ウェブ進化論」発刊後に変わったこと (8/9)

    * http://www.youtube.com/watch?v=-Rsq6Y-rDWo

はてなについて (9/9)

    * http://www.youtube.com/watch?v=J1F52qmDEXc

感想は今晩あたり追記予定。

近況/対談ログ

http://d.hatena.ne.jp/pekeq/20060901/p1

kawasakiのはてなダイアリ

http://d.hatena.ne.jp/kawasaki/20060901/1157108577

日経ITpro高橋信頼

http://itpro.nikkeibp.co.jp/article/NEWS/20060902/247043/

9/3/06ちょっと長い追記:

思い返してみるといろいろ補足したい部分が出てくる。対談イベントというのはライブセッションだからそのライブ感が面白いのであるが、一方で文字でいろいろ記したくなるものもある。

今回の対談イベントのコンセプトは、シリコンバレーのパロアルトあたりのバーで梅田望夫と雑談していたことをしらふではあるけど観客の前で再現するみたいな感じである。

Linuxの会社をやっている人間が「OSSっていまだによく解らない」なんてことは普通は公言しない。少なくとも、日本で商売をしている以上、「OSSとビジネス」については日本で一番よく理解している者みたいな顔はしている。それが対談で「OSSってよく解らないよね」「そうだ、そうだ」みたいな話をしているのである。ライブというのは恐ろしいものだ。

自分の発言を再度聞いてみて(今回はJTPAツアー参加者の皆さんがボランティアとなって、会場の設定、懇親会の準備、録画、録音、ネットへのアップロードすべてをやっていただいた、感謝したい)、いくつか補足する。

「シリコンバレー精神」のプロローグで『第III章「マイクロソフトとリナックス(Linux)」は、マイクロソフトの独禁法違反裁判の行方に注目が集まり、同時にLinuxという摩訶不思議な知り者が勃興してきた時期(一九九八年から九九年頃)に書いた「手紙」を集めた。この五年間で私がいちばん驚き、心から興味を持った対象はLinuxだった。とても不思議な出来事のように思えたし、世界の構造を変えてしまうほどの可能性の芽に出会った気がした。Linuxユーザーグループのミーティングにも潜入してみたし、リーナス・トーバルスを自宅に訪ねて話も聞いた。でも怒涛のような企業家主導型経済に飲み込まれるようにしてLinuxが資本主義に飼いならされていくさまを見て、期待感は失望感に変わっていった』(15頁~16頁)と記している。

2000年春ごろ出張で梅田にシリコンバレーで再会しいつものようにバーで飲みながらそのような話をしたのを思い出す。彼の言葉に反発しつつ十分に反論できない自分がいた。わたしの直感としてはオープンソースと言うムーブメントはそんなにやわなものではないと思っていたが彼を論破するような材料を持っていなかった。

当時、梅田はわたしに「オープンソースがこのIT産業のゲームのルールを変えるようなとてつもないものであると感じたものはいったいなんだったか?われわれは共同幻想を見ていたのか?」というようなことをいった。「オープンソースの前後で何が変わったのか?マイクロソフトのやっているゲームとどれだけ違うのか?まったく違わない。単にソフトウェア開発方法論という意味で、オープンソースあるいはバザールモデルといってもいいが、それは新しいバリエーションを生み出したにすぎない。いや、バザールモデルですら、昔からあったではないか?となるとオープンソースが生み出したものはいったい何なのか?」

彼は続けた。「Red HatやVA LinuxそしてCaldera、これらのIPOは、この高度に発達した資本主義の世界では、オープンソースが例外的に理想郷を創造するということはありえないということをはからずも証明したのである」

オープンソースによって世界を変えるというのは、それでは幻想だったのか?

5年たってみて確かにオープンソースベンチャーと呼ばれる企業はあのITバブル時にIPOの熱狂に沸いていた。VA Linuxの当時のCEO Larry Augustinが登場するドキュメンタリ(REVOLUTION OS)でもその熱狂が伝わってくる。そしてバブルは崩壊した。

しかし、LinuxもApacheもMySQLもPerlもPHPもいまだにハッカー達によって開発されている。OSS企業というのがいくつも登場したしOSSにまつわるビジネスも盛んであるが、オープンソースのコミュニティはそのような企業があろうがなかろうが価値を生み続けてきたのである。何が変わって何が変わらなかったか?

ハッカーは今も昔もコードを書く。その現象は全く変わっていない。自分の興味の赴くままにコードを書く。いいコードは広く受け入れられるし、そうでないコードは忘れ去られる。そのメカニズムも全く変わっていない。

コミュニティでは多くのコードを書きリスペクトされているプログラマが影響力を持つ。コミュニティの統治のメカニズムも全く変わっていない。

著名なハッカーの何人かは大手企業やOSS企業に雇用されそこから給与を貰うようになった。あるいはOSSビジネスで収入を得るようになったものもいる。OSSにまつわるビジネスが発生したことが大きな変化である。80年代末世界で始めてCygnusという会社がGNUソフトウェアのサポートビジネスを開始したが、2000年前後から大手企業の参入、Red Hat社のIPO等々でOSSビジネスが離陸した。

コミュニティの統治のメカニズムやハッカーがコードを書くメカニズムというのは資本主義が影響を及ぼすほどやわではなかったのである。

gdbの実践的使い方

「大規模ソフトウェアの効率的な理解(その123456)」などという大袈裟なタイトルでブログを書いたが、今回は一気に実践編ということでフリーソフトウェア定番のデバッガ gdb の実践的使い方について記す。

プログラマの日々には、プログラムを書くためのエディタ、プログラムをコンパイル(あるいは実行)するためのコンパイラ(あるいはインタプリタ)、そしてプログラムを理解するためのデバッガという三種の神器が必須である。

この定番はわたしの場合xemacs/gcc/gdbである。前々職(DECという会社に務めていた)の場合、それぞれプロプライアトリな物を使っていたので微妙に異なるがやることは一緒である。

gdbは何のために利用するかというと、プログラムを理解するために利用する。デバッガなんだからデバッグのために利用するというのは、gdbの底力の半分も利用していないと言ってさしつかえない。

gdbはプログラムを動作させてその動的な振舞いを逐一追って理解するための道具なのである。

よくプログラムをデバッグするとき出力(C言語ならばprintf())を埋め込んでやる人がいるが、それはお勧めしない。お勧めしない理由は多分101以上あるが代表的なものを順不同で言えば、

  •   printf()の副作用で、printfを挿入した時と、挿入していない時で実行結果が異なる場合がある。
  •   printfを埋め込んだおかげでバイナリが異なってしまい、ダンプやスタックを追うのが困難になる。
  •   複数のバイナリを管理しなければいけないのでコストがかかる。間違ってprintfを埋め込んだ版を本番用にインストールしてしまうかもしれない。
  •   printf版は徹底的にテストされないので、バグが残っているかもしれない。セキュリティホールになる可能性がある。

printfデバッグは百害あって一利なし。

でもやるやつは後をたたない。

それはgdbの使い方を十分伝承していないからである。gdbを使いこなせればprintfデバッグの呪縛から(多分)のがれられる。例外はLinux Kernelのように定番のデバッガがない場合で、その場合は泣く泣くprintk()というのを埋め込んでデバッグする必要があるかもしれないが、今回はふれない。

トップダウンアプローチ(巨視的理解)

gdbの起動は簡単だ。

  gdb program

main()があるプログラムならとりあえづ、そこにブレークポイントを設定し実行する。

  (gdb) break main
  (gdb) run

そうするとmain()で一時停止する。ステップ実行をしたい場合はnext(n一文字だけでもOK)である。nは関数の中にもぐっていかないので、中身まで実行の様子をみたいのならstep(s一文字でもいい)する。

変数の値を見たい場合は print である。プログラムの理解のプロセスは、適当な位置にブレークポイント(b)を設定して、そこまで実行(r)し、変数の値を確認(p)する。これの繰り返しである。

xemacsのスクリーンショットを添付したので参考にしてほしい。デバッガの部分とソースコードの部分が表示されている。run の後にコマンドオプションをわたしている。
3
実行を再開するのは continue (c)である。そうすると次のブレークポイントまで全速力で実行する。ブレークポイントにたどりつく前に実行が終了(正常か異常かはとわず)する場合がある。

プログラムを理解するプロセスは、ブレークポイントで変数の確認をし、再実行をくりかえす、ということになる。ソースコードも同時に表示されるので、その前後のソースコードをじっくり読んで字面から理解を深めつつ、実際の変数の値を確認し、動的な側面からの理解をする。自分の予想と違う値であれば、それ以前にどこかでその変数の値を変更した場所(代入等)があるはづなので、そこまで遡って理解をする。ソースコードから追ってもいいし、ブレークポイントを実行順のより前に設定し、最初から再実行してもいい。

これを繰り返し理解を深めていく。

gdbを利用したソースコードの理解というのは必ずしもデバッグ(プログラムの不具合の修正)だけではなく、ソースコードを効率的に読む時にも利用できる。

gdbはソースコードの理解を助ける偉大なツールなのである。

会社情報 採用情報 個人情報保護方針 商標等取り扱い事項 English
Copyright(c)2000-2006 MIRACLE LINUX CORPORATION. All Rights Reserved.