« Andy Oram, Greg Wilson編 Brian Kerninghan, Jon Bentry, まつもとゆきひろ他著「ビューティフルコード」オライリージャパン 久野禎子,久野靖訳 2 | トップページ | Andy Oram, Greg Wilson編 Brian Kerninghan, Jon Bentry, まつもとゆきひろ他著「ビューティフルコード」オライリージャパン 久野禎子,久野靖訳 4 »

2014年11月24日 (月)

Andy Oram, Greg Wilson編 Brian Kerninghan, Jon Bentry, まつもとゆきひろ他著「ビューティフルコード」オライリージャパン 久野禎子,久野靖訳 3

 Andy Oram, Greg Wilson編 Brian Kerninghan, Jon Bentry, まつもとゆきひろ他著「ビューティフルコード」オライリージャパン 久野子,久野靖訳 1 から続く。

9章 下向き演算子順位解析(ダグラス・クロックフォード)

 JavaScript による、プログラム言語の構文解析の話。特にややこしいのが、演算子に鬱陶しい優先順位がある事。つまり、乗算の * や 除算の / は加算の + や減算の - より強い、とか。また - は引き算を示すと共に、負の値も示したり。私は左辺値と右辺値の扱いで苦労したなあ。だからパーサは面白い。

 「だからS式使え」「逆ポーランド記法こそ至高」とか言い出すと嫌われるので要注意←お前だけだ

10章 高速ビットカウントを求めて(ヘンリー・S・ウォーレン,Jr)

 コンピュータの1ワードの中に、1が立っているビットの数を数える、という問題。例えば32ビットだと、1ビットづつ調べてシフトする、を32回ループすればいいよね、とか思うけど、これをどう高速化するか、というお話。全処理を終えるまでに実行する、命令の数を計算して処理時間を予測するあたりが、いかにもで楽しい。

 昔のCPUにはシフト&テストなんて命令があったような気も…。

 たかがビットカウントで、ここまで多くの方法がある事に驚き。予め256要素の表を作っておく手は、私でもスグに思いついた。でも分割統治法は、最初に読んだ時はよく分からなかったなあ。ビット列を櫛の歯で想像したら、なんとなく分かったような気が…。いや説明はできないけど←をい

11章 安全な通信:自由のための技術(アシシ・グルハッチ)

 PGPを使った安全なMUAを作ろう、というお話。今は例えば Thunderbird だと、プラグインを使えばPGPに対応できるけど当時は「アプリケーションをプラグインで拡張する」って発想が、あましなかった。ってんで、一から作る羽目に。元はMacOS9+FikeMaker+Frontierとか、懐かしい。

 使っているのは perl。こうやって見ると、やっぱり perl は毛深いなあ。いや便利だよね、バッククォート。移植性はないけどw 処理タイミングによるバグを潰すために数ミリ秒寝るとか、あるがち。

 こういうセキュリティが重要な仕事だと、一時ファイルもセキュリティ・ホールになりがちとか、ちょっと勉強になったり。しかしプログラマには人気あるんだな、ヴァーナー・ヴィンジ。

12章 BioPerlにおける美しいコードの成長(リンカーン・シュタイン)

 遺伝子解析を支援する perl モジュール BioPerl 内の Bio::Graphics のお話。遺伝子解析で問題となるのは、その情報量の膨大さ。基本はAGCTなんで2ビットで表現できるんだけど、それが31億対もあるんで、全体で「3ギガバイトほど」。それに解釈(アノーテーション)を加えると「現時点で何テラバイト」にもなる。

 ここで扱うのは、それをグラフにして視覚化する Bio::Graphics モジュール。デスクトップでも、CGIとしても使えるシロモノで、利用者は Webブラウザ経由で使えば perl のインストールとかも考えなくていい。今となっては当たり前だけど、プラットフォームの縛りから開放するには、なかなか賢い解決法。

 基本的にお絵かきソフトなわけで、やっぱり出ましたオブジェクト指向。ここでは perl ならではの柔軟性を徹底的に利用し、「ファクトリオブジェクトの列を作る」とか「コールバックを設定する」とか、無茶しまくり。ある意味、こういう「その場しのぎ」な解決法が取れるのが、perl の良さではあるんだけど、基本設計が酷いと悲惨な事にw

 出来上がってからわかる設計ミスというのも、往々にしてよくある話で。私も昔作ったプログラムを思い出して、つい直したくなったり。今思えば辞書クラスを作っておくべきだったなあ←意味不明

13章 遺伝子ソータの設計(ジム・ケント)

 「DNA中の××に関係ある領域にある遺伝子で既に知られているものの全部を、候補遺伝子として集める」機能を持つCGI。プログラム言語はc。

 改めて考えると、「××病に関係ある遺伝子」を特定するって、問題としちゃかなり難しい気がする。「病気持ちの人と、そうでない人のDNA配列を比べりゃいい」とか思ったけど、一人当たりのデータが膨大な上に、DNA配列は人により違う。多人数のデータで統計的に特定していくとしても、やっぱりデータ量は膨大になる。

 ってのは置いて。この章のミソは、c言語でポリモフィズムを実現する部分。と言っても実に素直な方法で、struct の中に関数ポインタを持ち、クラスに応じて適切な関数を設定する、という方法。昔覗いた X Window System も似たような事をやってたなあ。キャストだらけだったがw

 膨大な量のデータを扱うだけに、やはり問題は実行速度。ここではディスクのIOがネックになるとして、予めメモリに読み込む方法を使っている。

 終盤では、オブジェクト指向も問題点も指摘していて、これが実に納得できたり。

オブジェクトのメソッド中に役に立つコードを埋め込んでしまったら、そのコードを使うにはオブジェクトを作らなければなりません。

 うんうん、まったくだ。お前だよお前、VBScript。なんでシェル・オブジェクトだのファイルシステム・オブジェクトなんぞを作らにゃならんのだ。複数インスタンスを使う場合なんて…あ、シェル・オブジェクトはあり得るか。 

14章 エレガントなコードはハードウェアに合わせて進化する:ガウス消去法の場合(ジャック・ドンガーラ、ピョートル・ラスツゼック)

 数値計算ライブラリ LINPACK・LAPACK・ScaLAPACKを例に、行列計算のLU分解処理(ガウス消去法)が、CPUアーキテクチャの変転と共に、どう変わってきたかを辿るお話。プログラム言語は Fortran とc。私はガウス消去法なんか全く知らないけど、なかなか面白かった。

 関わってくるCPUアーキテクチャは、IBM360→ベクトルマシン→RISC→分散メモリの並列システム→マルチコア。ここでは、やっぱり実行速度が問題で。ただし、そのネックとなっているのは、CPUとメモリ間のデータ転送。

 一般に飛び飛びにメモリを処理するより、連続した領域を続けて処理するほうが速いんですね。大抵のOSじゃメモリはページング(→Wikipedia)してるんで、同じページのデータを連続して処理すりゃ、ページ切り替えの手間が減って速くなる。これは今も同じで、例えばCPUキャッシュはページ単位で管理してたり。

 ってんで、最初に出てきたのが、二次元配列の場合に、どっちの添字を内側で回すか、という問題。これがcとFortranじゃ、配列のメモリ割り当ての方法が逆で、cだと外→内と回すほうが速いけど、Fortranだと内→外と回す方が速かったり。

 と最初はループの回し方だけだったのが、ベクトルマシンが出たりRISCになってCPUキャッシュが重大な要素になったりマルチコア向けにスレッドセーフにしたり…と、ハードウェアの進歩にあわせて色々とチューニングしていくあたりが、なかなか楽しいコラム。

15章 美しいデザインの長期にわたる恩恵(アダム・コラワ)

 再びLAPACKの話。プロフラムはFortran。大文字ばかりのソースコードが、年寄りにはちょっと懐かしい。プログラミング・スタイイルも、ちょっと懐かしい流儀で。

 まず最初に「おお!」と思うのが、サブルーチンに渡した(配列の)引数に中身が、戻って来た時には変わっていること。

 今は値呼び出しが基本で、処理系によっては構造体までスタックに積んじゃうけど、やっぱ私は参照呼出しの方が好きだなあ。だって、紛らわしいじゃん。「文字列や構造体は値が変わるけど、整数は変わらない」とか。参照呼出しなら、「基本的になんでも変わる可能性がある」で分かりやすい。

 もう一つは、例外処理。今は「try~catch~throw で例外投げればいいじゃん」な風潮だけど、それやるとイベントのチェインが次々と遡っていって、最終的にはコアダンプになる。で、このサンプルは、ステータス・コードを返すという懐かしい仕様。「とにかく俺のプログラムの中じゃ止まらない」という、ある意味、自己防衛本能の極みな仕様。

 いやだって、止まったルーチンを作った奴が呼び出されるでしょ、普通。それを使った奴じゃなくて。だから異常を示すステータス・コードを返して、意地でも自分のルーチン内じゃ止めない。例え使い方が間違ってても。ステータス・コードを見ない方が悪い←をい

 など懐かしい流儀もあるけど、新しい流儀もある。「CERN ライブラリの多くのルーチンが簡単なテストとサンプルプログラムを提供していることです」。そう、テスト環境も重要な資源で、それに気づいてからは、自分用のテスト環境パッケージをコッソリ作ったっけ。コッソリってトコが姑息w

16章 Linuxカーネルのドライバモデル:一緒に働くことの恩恵(グレッグ・クローハートマン)

 Linux のデバイス・ドライバを作る話。プログラム言語はc。

 やっぱり仕様ってのは実装してみないとわからないモンで。それぞれのデバイス・ドライバは独立しているように見えて、実は互いの情報を必要としてる、そいう最初の例が身に染みる。

 ここでは、USBディスクの電源を、どうやって切るかという話。USBディスクは本体のUSBコントローラに繋がってて、USBコントローラはPCIコントローラカードに繋がってる、この時、電源を切る順番が PCIコントローラ→USBディスクだと、怖い事になる。USBディスク→PCIコントローラの順じゃないと拙い。

 つまり、カーネルまたはデバイスドライバが、互いの繋がり方を認識してないとマズいわけ。

 などから始まって、Linux のデバイスドライバの礼儀正しい作り方の話が色々と。メモリリークが起こる原因が、これまた切実で。いや良くやっちゃうんだよね、ドキュメントをシッカリ読むのが面倒で、「とりあえずデフォルトでいんじゃね?」みたいな。特にメモリリークのバグは、簡単なテストだと見付からないから、気づかぬままリリースしちゃったり。

 一般にデバイス・ドライバなんて小さいモンで、組み込みだとメモリが少ないから重大かも知れないけど、今のパソコンなら大きさはあまし問題にならない。なら大型コンピュータならもっと関係ないだろう

 …と思ってたら、IBMのS390で問題が起きた、というから笑っちゃう。ナニが問題かと言うと、「このコンピュータは最大で1024個までの仮想パーティションで同時にLinuxを起動でき」って所。仮想マシンが1000個、同時に走るわけ。だもんで、デバイス・ドライバが占める資源も千倍になって、問題も一気に千倍になってしまったw

おわりに

 次の記事に続く。

【関連記事】

|

« Andy Oram, Greg Wilson編 Brian Kerninghan, Jon Bentry, まつもとゆきひろ他著「ビューティフルコード」オライリージャパン 久野禎子,久野靖訳 2 | トップページ | Andy Oram, Greg Wilson編 Brian Kerninghan, Jon Bentry, まつもとゆきひろ他著「ビューティフルコード」オライリージャパン 久野禎子,久野靖訳 4 »

パソコン・インターネット」カテゴリの記事

書評:科学/技術」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/201750/60702167

この記事へのトラックバック一覧です: Andy Oram, Greg Wilson編 Brian Kerninghan, Jon Bentry, まつもとゆきひろ他著「ビューティフルコード」オライリージャパン 久野禎子,久野靖訳 3:

« Andy Oram, Greg Wilson編 Brian Kerninghan, Jon Bentry, まつもとゆきひろ他著「ビューティフルコード」オライリージャパン 久野禎子,久野靖訳 2 | トップページ | Andy Oram, Greg Wilson編 Brian Kerninghan, Jon Bentry, まつもとゆきひろ他著「ビューティフルコード」オライリージャパン 久野禎子,久野靖訳 4 »