Re: 私の peephole 最適化

xhlメモに触発されて久しぶりにプログラミング関連の記事。ほとんどの項目はxhlメモで網羅されてしまっているが、いくつか自分がやることを追加してみる。

ライブラリのソースを読む
特にSTLを使っている場合。STLの内部で実際どのようにコードが走るのかを知ることで糸口が見つかる場合がある。自分の例では、使っていたSTLが自分と思っていたのと違う動作をしていたという例があった。

メモリアロケーションに注意
STLのsetやmapを多用しているとヒープからのメモリの確保や解放が頻発する。アルゴリズムのコアな部分でこれが起きると、下手するとアロケータが何割かのCPU時間を使うこともあるので注意が必要。動的メモリアロケーションがアルゴリズムの本質上どうしても必要なら、自前のより軽量かつ目的に特化したアロケータを書いてみたり、汎用的なインターフェースを持ちながらも高速なアロケータに取り替えてみる(参考)等してみるといいかも。

本当は「プログラムを最適化する10の方法」とかいって10個並べると格好いいが、まあ思いつかないのでこんなところで。ちなみに話題のもととなった某氏のコードが純粋計算系のプログラムだったので今回は扱っていないが、I/Oやシステムコールを多用するプログラム(サーバアプリケーションとか)になるとまた違った視点からの最適化も必要であるとは思う。

近況報告

昨年末にCCGrid出しましたと書いておいてその後音沙汰がないのもアレなので。

1月中旬に結果が返ってきて、CCGrid'08には無事通りました。現在Camera-ready原稿の準備中。投稿時にこれでよいと思っていたフォーマットと別のフォーマットを使わないといけないらしいことが判明し、大幅ページ数超過の予感。どうしたものか・・

1月はずっと修論のターン。今週発表会＆審査会も終了して、なんとか修士の修了＋博士への進学を認めてもらえたようです。審査の結果を聞く前から飲んでいたりしたが・・・

周囲はほとんどが修士修了後就職して大学を離れていくということもあり、自分自身の生き方についてもあれこれ考える時間が長くなっているような気がする今日この頃ですが、目の前のやるべきことも疎かにしないように着実にこなしていきたいところです。

2007年を振り返る

毎年恒例の今年のまとめ。

1月〜2月 修論を見据えたテーマ選びに悩む。うだうだと何をするでもない日々を過ごしていたような。昨年から通い始めていた自動車教習所通いに精を出して2月に免許取得。半分現実逃避か。まあ免許は免許で必要だが[1]。
3月 ようやくテーマがそれなりに見えてくる。沖縄に旅行。
4月 M2に進学するも特に感慨もなし。SWoPPに申し込んでとりあえずそれに向けて頑張ることにする。
5月〜6月 SWoPPに向けた実装と論文書きなど。
8月 SWoPP 2007に参加[2]。さすがに1年前よりは内容的にまともな発表ができたと考えているが。
9月 修論中間abstract提出。EuroSys 2008を夢想するもさすがに無謀。
10月 IPDPSに出そうと頑張るもdeadline miss。1ヶ月後のCCGridに向けて仕切り直すことにする。
11月 CCGrid 2008に投稿。論文投稿したのを記念して中部・関西方面に旅行にでかける。中部国際空港・関西国際空港・神戸空港・大阪国際空港を一気にまわり、かつ新幹線N700系にも乗ってくるという超ヲタ旅行。オプショナルツアーは淡路島での野島断層見学。
12月 修論abstract提出。忘年会続きで飲みすぎ。なんかCCGridですべて終わった気がしていたが激しく気のせいで、修論大丈夫なんだろうか・・？というのが最近の心配事。

さて、来年は研究をもっと頑張らないとな、と去年書いたわけだが、まあ自分で振り返ってM1のときよりは頑張ったといってよいのではないかと思う。が、理想値に達しているかと問われればまだまだな気もする。来年は当然これ以上。

1年を終えてみて思うのは、とりあえずシュウカツしてみてもよかったかなぁということ。実際にエントリーしないにしても、説明会とか見学会みたいなのはもっと積極的に顔を出して企業が何をやってるのか、という感触くらいはつかんでもよかったのではないかと今更ながらに思っている(なぜか気が向いてH社にだけは行ってみたが)。

来年はとりあえず、自分の視野を自分で狭めないよう注意しつつ、目の前の研究をがんばるという年になるといいな。実は重要なものが目の前にあるときにはそれほど重要に見えなかったりもするので、なかなか難しい問題ではあると思うのだが。

[1] 実際のところ教習期限ぎりぎりだったため精を出していなかったら危なかった。
[2] (1/7追記) 最初間違えてSWoPP 2008と書いていたので修正。

旅人をつなぐ"マルスシステム"開発ストーリー

久々におもしろい本を読んだので紹介しておく。

旅人をつなぐ"マルスシステム"開発ストーリー

JRの予約発券システムの裏にあるマルス(MARS)システムの開発についてまとめた本。そもそも何でこんな本が読みたくなったかというと、Project Xがこのシステムを扱った回の再放送をたまたまヒストリーチャンネルで見たからだ。

さてこの本、前書きには「コンピュータの知識がほとんどない人を対象に〜」などと書かれているが、「情報処理技術者教育センター」というところが出してるだけあって、結構読み応えのある内容であった。例えばシステムの説明のところにハードウェアのブロックダイアグラムが書かれていたり、予想外の性能のボトルネックが露見したというくだりではバッファメモリ(キャッシュ)がマルチプロセッサに共有されていることによってシングルプロセッサ環境よりも容量ミスが起きやすくなるためである[1]といったことについて解説されていたりする。

プロジェクトXを見て気になっていた「三重発券事故」についてもかかれていて、それによると、三重発券の原因はマルスのバグではなく、
1. 係員Aが客の要求によってある予約をキャンセル
2. 直後別の係員Bが別の端末からその席に予約を入れる
3. 係員Aが念のため正しくキャンセルできたか現在の座席表をチェック
4. 係員Aがキャンセルしたと思っている席には既にBによる予約が入っているが、Aはそれを知らず、キャンセルが正しく実行できなかったと思い込む
5. 係員Aが再度キャンセル操作を実行
6. その後係員Cが空席となっているこの席に予約を入れる
という感じで生じたものらしい。プロジェクトXではさかんに「マルスによる二重発券のトラブル」という語のみが登場してその原因について一切触れられなかったために、これを読むまではrace conditionを正しく考慮できなかったバグじゃないの、程度に考えていた。もちろんこうしたヒューマンエラーを起きにくくすることまで含めて「システム」であると思うので、マルスのせいといっても広い意味では間違いではないと思うが。

これまでシステム開発というととにかく下請け・孫請け・ひ孫請けで自分では何もしない大手ITベンダ、というイメージがあっただけに、こういう夢のあるシステム開発の話は新鮮味があった。このシステム開発は1960年代から70年代にかけての話で、経済の構造もIT業界の構造も何もかもが現在とは違ったころの話であるという点も考える必要があるとは思いながらも、この本を読んで、システム開発というものに対する見方が少し変わったような気がする。

実はもう一冊、みどりの窓口を支える「マルス」の謎—世界最大の座席予約システムの誕生と進化という本も同時に買ったので、こちらも読んでみようと思う。

[1] よく理解できなかったのはこのボトルネックを解消するad-hocな案としてキャッシュのフラッシュ("バッファキャンセル"と呼ばれている)を専用に行うファームウェアを用意した、というくだり。バッファメモリの内容は今日のキャッシュと異なり完全にCPUが制御していたようなので、その制御をoffloadしたということだろうか？

Ubuntu Gutsy (i386)でPAE＋nvidia

DDR2メモリの価格が偉いことになっているのでつい乗せられて記念に4GB買ってしまった・・・というのはよくある話で、もとある2GBとあわせ合計6GBになったメモリをどうするかというお話。

普通の32bitカーネルが扱える物理メモリ空間は4GBまでで、そのうち3GBを超えた物理メモリ領域はI/Oのためにデバイスにマップされていたりして一部のアドレスがつぶれてしまうため、32bitカーネルで起動してもメインメモリは3.2GBしか認識されない(この容量はマシンによって異なるはずである)。

この場合の選択肢は2つあって、64bitカーネルを動かす方法と、32bitカーネルのままPAE(Physical Address Extension)を有効にする方法とがある。前者の場合はさらに64bitディストリビューションを入れる方法と、32bitディストリビューションのカーネルだけ入れ替える方法とがあるが、今回はユーザーランドは32bitのまま維持したかったのでPAE拡張対応のカーネルを入れる方向でいってみることにした。

Ubuntu Gutsyで標準で入るlinux-image-genericはPAE非対応なので、PAEに対応したイメージであるlinux-image-serverを入れて動かす必要がある。

で済めば何も記事を書くまでもないのだが、ここで問題発生。GeForceを使うためにnvidiaのプロプラエタリドライバを使っているのだが、serverイメージには対応するlinux-restricted-modulesがないことが判明。Xがまともに立ち上がらなくなってしまった。

あれこれ試した結果、以下のようにするのがよいようである。
0. sudo aptitude install linux-image-server
1. sudo aptitude install nvidia-kernel-source linux-headers-server
2. sudo aptitude install module-assistant
3. sudo m-a a-i -l 2.6.22-14-server nvidia
4. sudo depmod 2.6.22-14-server

バージョン番号は適宜読み替えて欲しい。

serverイメージはPAE(CONFIG_HIGHMEM64G)がonになる一方タイマ割り込み頻度(HZ)が100になっている、CONFIG_PREEMPTがnoになっているなど本当にサーバー向けの設定になっている。俺のようにまさにデスクトップとして使いたいがメモリを認識させたいだけの場合は本来なら自分でカーネルを作り直すのがいいような気はするが。

今回の設定はあくまでも32bitカーネルが64GBまでの物理メモリを扱えるようになった、というだけなので、各アプリケーションの仮想メモリ空間は32bitのままである。すなわちLinuxでは1GBのメモリ空間がカーネルによって予約されるので、各プロセスは3GBまでの空間しか使えないということになる。1プロセスにより多くのメモリを割り当てたければ64bitカーネルと64bitのユーザーランドが必要である。

ちなみに同じマシンにはWindows XP(32bit版)も入っているのだが、そちらはServerとの差別化のためなのか、boot.iniに/PAEを書き加えても6GB認識してはくれなかった。NXビット(XDビット)はPAEの一部のような仕様なので少なくともSP2以降のカーネル自体は余裕でPAEに対応しているはずなのだが・・・。

謝辞
m-a a-i (module-assistant auto-install) については研究室一のDebianハッカーであるひらの氏が教えてくれた。

Linux: ifconfigコマンドの実装

何度となく実装しているはずだがいつもやりかたが思い出せなくなって時間を無駄にしている気がするので、ここにメモ。

ifconfigコマンドで出てくるようなネットワークインターフェースの情報を直接取得したいときにはどうするか？(Linux限定)

まずはインターフェースのアドレスなどの情報を取得する方法についてはnetdevice(7)にある。基本的にはソケット(種類は何でもいいらしい)を作ってそのソケットに対してioctlすることになる。

次にインターフェースの送受信したバイト数やパケット数等の情報は/proc/net/devから読んでいるようだ。システムが現在認識しているインターフェースの一覧もここから得ることができる。

余談であるが、netdeviceのマニュアルを読むと、デバイスのマルチキャストMACアドレスを設定したり削除したりする方法が示唆されている(SIOCADDMULTI, SIOCDELMULTI )。マルチキャストアドレスの現在の設定については/proc/net/dev_mcastで読むことができる。マルチキャストアドレスを自由に設定するツールは少なくとも標準的にはないような気がするので、知っておくと便利かもしれない。(もしあればコメント欄にツッコミをよろしく)

Nikon D300発表

ウワサどおり23日、ニコンからD3およびD300が発表された。D100およびD200のオーナーとして、特にD300に対する感想を述べておこうかと思う。

D200後継機は「サプライズ」であるという情報は発表前から流れていたが、ここまでのものとは思わなかった、というのが正直なところだ。D300を一言で言えば「DXフォーマットを搭載したフラッグシップ機」と言ったところだろう。実際、D3とD300のスペック的な違いといえばもはや撮像素子のサイズくらいしかない。

D200とD300の比較はDC Watchの記事に詳しいが、特にピックアップすると次のような感じである。
- 画素数が1000万から1200万に
- 最低感度がISO100から200に
- 秒間コマ数が5から6(最大8)に
- ライブビュー機能(二種類のAF可能)
- センサーのゴミ取り機能
- ファインダー視野率100%
- 51点AF/15点クロス
- 3インチ背面液晶
- 5g軽量化(ぉ
- 14bitA/D変換ってのはRAWも14bitで出てくるのかな？

画素数は600万でも十分だと思っているので特にコメントしないとして、ISO感度が200からになったのはうれしい。D100ではやはりISO200からで、D200になって最低感度が100に落ちてシャッター速度の遅さにびっくりする場面も結構あったからだ。ライブビューは星を撮ったりするときに便利そうである。

これまでのD100、D200とも、中級機以上と分類されるランクの製品ではあったが、最上位であるD1シリーズやD2シリーズと比較すると明らかに下位の製品であった。例えばファインダー視野率が100%でないといったスペック上の特徴からそれは見て取れる。しかしながらD300は完全にプロ機という他ないスペックとなっている。驚くべきはこの性能が23万という価格で手に入ることである。昨今のデジタル一眼の相場からはこの価格はやはり高いと思われるかもしれないが、D100が20〜25万円、D200も20万円だったことを考えると実にリーズナブルであると言わざるを得ない。

さて、D300は11月発売であるそうだが、これを買うかどうか？とりあえずは様子見であろう。その理由はいくつもあるが
- D200を買って(2006/03購入)まだ1年半である (D100は2003/03購入なので3年使った)
- そもそもまだD200をほとんど使ってない
- 黎明期の製品故(デジタル部に)致命的な不満の多かったD100と比べてD200には今のところ不満がない
- D200への唯一の不満は重量であるが、5gしか改善されていない (これはこのクラスのカメラとしては仕方のないことではあるが)
- 23万はD300というカメラの値段としては反則的に安いが絶対的に見ると高い
といったところである。

このところのニコンのペースを見ると、おそらく来年夏にD80後継機が出て、再来年夏にD300後継という感じであろうから、あと2年様子を見るというのものまあ現実的ではないか。もしもD300を買うならば、残念ながらD200は売却ということになろう。D200とD300はあまりにも近すぎるため、両方を同時に運用することは難しい。

最後にD3について。「まさか本気でフルサイズをやるとは思わなかった」。C社がやっている以上やらないわけにはいかなかったということだろうか。スペック的には1D-MarkIIIといい勝負であるので、あとは画像に期待である。アテネでは惨敗であったが来年の北京五輪の中継ではまた違った様子を見ることができるだろうか？

残暑お見舞い申し上げます

暑い暑い暑い。これを読んでいるみなさんの多くも暑くてまいっているところでしょうに、追い撃ちをかけるようでごめんなさい。とにかく暑くてblogを書く気も起きない。昔は「あ、このネタを書こう」と思ったらその6割くらいは書いていた気がするのだが、今は1%にも満たないんじゃないだろうか。

それはともかく、夏休みの自由研究ネタとしてマシンHDDの温度について。

画像はうちのマシンの今日一日のHDD温度の変化をグラフ化したものである。

今日は午前中11時前くらいに家を出て、16時過ぎに家族が帰宅するまで家は締め切った状態であった。このマシンは南に面した居間に置いてあり、締め切った状態では部屋は相当な温度になる。その状態でもHDD温度はぎりぎり50度には達していないようだ。Googleによると50度を超えない限り寿命にはあまり影響ないそうなので大丈夫だろうか？

16時を過ぎた時点から急激に温度が下がっているのは、家族が帰宅してエアコンを動かしたからである。エアコンは偉大であるということが見て取れる。

それにしてもここまで暑い日が続くと、つけっぱなしマシンがあること自体が大変な罪悪に思えてくる。とりあえずはエコワットを買って電力使用料を把握するところから始めようかと思っているが・・・。

WX320T(3)

喜び勇んで使い始めたWX320Tであったが、早速初期不良にはまってしまった。以下その写真。


液晶の中央付近に線が何本か入っている。この線はある日一本現れ、時間の経過とともに一本ずつ増えていくという奇妙な振舞を見せていた。残念ながらもう交換してしまったので、5本になったところまでしか確認できていないのだが。写真の段階では4本であった。

そんなことがありつつも、まあWX320Tはよい機体であると思っている。バッテリ持ちであるが、金曜の夜にフル充電→水曜の昼にバッテリ切れで電源断という感じであった。つまりまるまる4日半もったわけである。この間の使用状況は、常に待ち受け状態、1日のうち1時間程度、ディスプレイを開いたり、Webを見たり、1日10通弱のメールを受信したりといった操作を行ったという感じである。通常の使用には問題がないと言えるだろう。

WILLCOMの音声端末の特徴としてUSB-miniBケーブルで充電が可能という点があり、研究室のようなUSBポートもUSBケーブルも腐るほど落ちている環境で暮らしている限りバッテリ切れで困ることはありえない。WX320Tに至ってはUSB充電以外の充電方法を廃止するという思いきりのよさだ。このようなマニアにうれしい仕様がWILLCOMから離れられない理由の1つと言えよう。

WX320T(2)

予告どおり、WX320T(ホワイト)に機種変更を行った。前回記事を書いてからWILLCOMの割賦払いサービスであるW-VALUE SELECTが発表されたのだが、どうせ2年間は使うだろうからこのサービスを使うことにした。機種変更だと19,000円くらいするところを実質14,000円弱で購入できる(パケコミネットを続けた場合)計算になる。そんなわけで今日の支払い額は0円。

さっそく使ってみての感想だが、とにかく動作が軽い。長いメールをスクロールしたときなど、スクロールのキー操作が速すぎて画面の描画が間に合っていない感じである。京ぽんはキー入力の受信部分に問題があり、連続した高速なキー操作を取りこぼすことが多かったのでこの違いは大きい。京ぽんの重さに関しては、購入直後から動作感に関して文句を書いていたのを発見。京ぽんはやはり絶対的に遅かったようである。

ブラウザ(Netfront)でのWeb閲覧も非常にレスポンスがよい。普通にCLUB AIR EDGEにつないだ時にどのモードで通信しているのかわからないのだが、ダイヤルアップ電話番号の末尾が##64であることから2xもしくは4xで通信していることがうかがわれ、1xパケットまでの対応だった京ぽんよりも速いのは間違いなさそうである(W-OAMもつくし)。

機能面では、QRコードリーダと赤外線通信機能に対応したのがうれしい。やはりなるべくなら携帯のキー操作はしないで済ませたいのである。研究室の周囲の人々のDoCoMo携帯およびau携帯との間でデータ交換を試してみたが問題なくアドレス情報の交換が行えた。それに加えて、日時の自動調整機能がついているのが高評価である。これも他社携帯ではすでに自明の機能となって久しいが京ぽんにはなかった。

ハードウェアの使用感もよい。サイズや重量は京ぽんとほぼ同等で、アンテナの突起がなくなった分ポケットに入れたときに一回りスリムに感じる。キーの操作感はA5509Tに準じる感じである。俺は気に入っているがThinkPadのような深いキーストロークが欲しい人には物足りないかもしれない。

以上、ざっと半日使用しての感想を書いてみたが、今のところ京ぽんに劣るところはないというのが感想である。今後はバッテリの持ち、アンテナ感度等の性能について長期的に観察を続けていく必要があると考えられる。