分散コンパイルのためのdistcc

Posted on 2009年11月6日 by inquisitor

とある事情でMySQLを何度もビルドしなければならなくなりました（『MySQLデータベース構築バイブル』を読んだからではありませんが、そういうことにしておいてもらってもいいです）。

利用できる最速のマシン（Core i7 GHz）でMySQL 5.4.3-betaをビルドするのにかかる時間は1分40秒ほどです。1回だけならいいのですが、何回もすることを考えると、少しでも早くビルドできる環境を用意しておきたくなります。

Windowsの場合は知りませんが、GNU/LinuxやMac OS Xでは、C言語とC++の分散コンパイルのためのdistccが簡単に利用できるので試してみました。

手順は以下の通りです。

すべてのマシンで同じコンパイラを利用できるようにする
distccのインストール
環境変数CC、CXXの設定
./configure
環境変数DISTCC_HOSTSの設定
make -jジョブ数

もう少し詳しく説明します。

利用したマシンは以下の通りです（A, D, Eのネットワークは1G、それ以外は100M）。

A: Core i7 940 2.93GHz
B: Core i5 750 2.67GHz
C: Core2 Quad Q6600 2.4GHz
D: Core2 4300 1.8GHz
E: Athlon 64 X2 5400+
F: Pentium D 3GHz

クライアント側で必要なのはdistcc、サーバ側で必要なのはdistcc-serverだけなのですが、マシンをどのように利用するかが確定しているわけではないので、まとめて入れておきます。

yum install distcc*

本稿執筆時点では、パッケージで配布されているdistccのバージョンは2.18でした。Googleによって改良されたバージョン3系列のほうが、パフォーマンスはいいはずなのですが、私の環境ではそれを確認することはできませんでした。

今回利用したGCCのバージョンは4.4.2です。すべてのマシンで、同じフルパスで同じバージョンのgcc, g++を利用できるようにしておきます（binutilsも？）。その上で、クライアントで次のように環境変数を設定します。

export CC="distcc gccのフルパス"
export CXX="distcc g++のフルパス"

さらに、利用するサーバとジョブの数を設定します（クライアントはIPではなくlocalhostと書くべきです）。ジョブ数のデフォルトはIPに対しては4、localhostに対しては2なので、その場合は「/ジョブ数」は省略することができます。「IPアドレス/ジョブ数,lzo」と書くとデータを圧縮するようになりますが、私の環境ではその効果は確認できませんでした。

#distcc Ver. 2の場合
export DISTCC_HOSTS="サーバ1のIP/ジョブ数 サーバ2のIP/ジョブ数 ... localhost/ジョブ数"
#distcc Ver. 3の場合
export DISTCC_POTENTIAL_HOSTS="サーバ1のIP/ジョブ数 サーバ2のIP/ジョブ数 ... localhost/ジョブ数"

すべてのサーバ用マシンで、次のようにしてサーバを起動します（受け入れるジョブの最大値を指定することもできますが、この例のように省略すると、CPU数+2になります）。サブネットは192.168.0.0/24のように指定します（毎回これを行うのが面倒なら、distccdが自動的に起動されように設定しておいてもいいでしょう）。このサーバがポート3632を利用できるようにファイアウォールを設定しておいてください（利用するポートを指定することもできます）。

distccd --daemon --allow サブネット --log-stderr

マシンBをクライアントにして、DISTCC_HOSTSを「AのIP/6 EのIP CのIP localhost」にしたときのビルド時間は1分17秒でした。マシンA単体でのビルド時間1分41秒、マシンD単体でのビルド時間6分54秒と比べると、「速くなってよかったね」という感じです。

投入するジョブの数は微妙な調整が必要です。デフォルトの「CPU数+2」が最適というわけではありません。また、明らかに遅いマシン（ここではマシンF）は入れない方がよさそうです。

Macでも試してみました。Macの開発環境にはdistccがはじめから含まれているので、準備の手間が一つ省けます。

手元のMacBook Pro (Core2 Duo 2.16GHz)単体では、ビルドに7分57秒かかりました（GCCのバージョンは4.2.1）。

MacPortsという常にソースからビルドするシステムがデファクトになっているのでとても困ったことなのですが、私のMacのビルドは遅いです（MacPortsの待ち時間は大嫌いです）。たとえば、CPUはこのMacBook Proより遅いはずのマシンD（上述）のビルド時間は6分54秒でした（ディスクの書き込み速度の差はあまり関係ないでしょう）。

このMacBook Proをクライアントに、Core2 Duo 2GHzのMacBookとMacMiniをサーバにして（DISTCC_HOSTSは「MacBookのIP MacMiniのIP」）ビルド(make -j8)した結果は5分53秒でした（localhostをDISTCC_HOSTSに追加したら遅くなりました）。

確かに速くはなりましたが、「MacPortsがすごく速くなるかも」という期待は裏切られた感じです。

もちろん、GNU/Linuxマシン上にクロスコンパイル環境を構築してサーバにすればよいというのはわかっているのですが、Appleが開発環境を微妙にいじっているせいで、クロスコンパイル環境の構築はちょっとやっかいだったりするのです（そのためのプロジェクトがあるくらいに）。

『ジェネレーティブプログラミング』や『C++ Template Metaprogramming』で紹介されているテンプレート/メタプログラミングのコードを使えば、分散コンパイルのインフラ上で並列計算ができたりするわけですが、そういうネタはまた別の機会に。

追記：Cプリプロセッサメタプログラミングで、文字列系泥沼関数型プログラミングというのもすごいですね。

電卓に求められるコト

Posted on 2009年10月19日 by inquisitor

使っているのは整数の加算と乗算だけで、オーバーフローしているわけでもないのに正しく計算できない例を先日紹介しました（フェルマーの最終定理の「反例」（電卓編））。

文明が発達しすぎた果てに電卓を作れなくなってしまうというのはSFでよくありそうな話ですが、時代の先を行っているというAppleの主張は確かに正しいのかもしれません。（参考：ロストテクノロジー(Wikipedia)）

小数が出てくればいろいろ問題があるのは知っていても、電卓を使った整数の計算を疑う人は少ないのではないでしょうか。しかし実際には、WindowsやMac OS Xの標準的な電卓は、つい最近まで整数の計算を正しく行えませんでした。

1992年に発売されたWindows 3.1の電卓には、下のような普通の電卓と関数電卓の2種類のモードがありました（下はWindows 3.1の電卓をWindows 7上で実行した様子です）。

この、普通の電卓と関数電卓という構成は、2007年に発売されたWindows Vistaまで、基本的には変わりません（下はWindows Vistaの電卓。Windows 3.1のものと違って、Windows 7上では実行できないというのは皮肉なことです）。

Windows 7では、電卓のUIが変更され機能も大幅に拡張されるため、ちょっと話題になっていました。

Windows 95以来、スタートメニューのアクセサリには、電卓が含まれていた。その機能はVistaまでほとんど変わることなく続いてきた。（Windows 7ソフトウェアレビュー－大きく進化した電卓編）

これは大間違いです。まあ、見た目がほとんど変わっていないので、そう思われるのもしかたがないのですが。私が試した限りでは、Windowsの電卓は、1995年に発売されたWindows 95と1999年に発売されたWindows 98SEの間では、その機能が大きく変わっています。計算の精度を高めることによって、フェルマーの最終定理の「反例」（電卓編）のような問題が起こらなくなったのです（参考：When you change the insides, nobody notices）。

一方Macはと言えば、1996年に発売されたMac OS 7.5.5の電卓は、下のような感じでした。1992年のWindows 3.1にかなり後れを取っている感じです。

Mac OS Xの電卓は、下のような基本・科学計算・プログラマの3つのモードを備えており、Windows Vistaのそれより優れているように見えます。

しかし、先に述べたようなMicrosoftが遅くとも1999年には修正できていた問題が、Macで修正されたのは2007年のMac OS X 10.5でのことでした（PowerPC版Mac OS X 10.4では、基本モードと科学計算モードで結果が異なり、しかも、両方とも間違っていました）。

同じくApple社のiPhoneの電卓はもっと大変で、Ver 2.0のバグはかなり大きく取り上げられましたし（参考：iPhone 2.0 の「計算機」アプリにバグが発見される）、本稿で扱っているような、大きな整数の計算を正しくできないという問題は、バージョンが3.1になった現在でも残っています。端末を回転させるとモードが切り替わるのもかっこよくていいのですが、その前にやるべきことがたくさんありそうです。

見た目をよくするのは大事なことです。でも、電卓でもっとも大切なことは「正しく計算できること」であるということに疑問の余地はありません。

「正しく計算できること」を完璧に実現するのはもちろん不可能です。どのあたりで妥協するかが重要なわけですが、フリーソフトウェアのGNU bcの、「メモリが許す限りの桁数を確保する」というのは一つの目安になるでしょう。

やってはいけないのは、「整数はいわゆるintで計算し、その範囲を超えたり1未満の数が必要になったらいわゆるdoubleを使う」というような実装です。こういうことをしてしまうと、フェルマーの最終定理の「反例」（Perl, awk, JavaScript, PHP編）も発生してしまいます。

もっとも、電卓をちゃんと作るのは以外と難しいようで、2008年にはGoogleも計算ミスをしていました（参考：グーグルの電卓機能が計算ミス）。そのときには次のような解説がありましたが、その筆者が考える電卓の実装は、先に述べた「やってはいけないこと」そのままのようです。

コンピュータでの正確な計算は、コンピュータが一般的に0または1の数字しかない2進数で計算をしていることに基づいている。一方、人は0から9までの数字を使った10進数計算を行う。正確性に問題が生じるのは、コンピュータが数字を2進数に変換して処理し、結果を10進数に戻して表示するためだ。

このようなことが、電卓において問題になるはずはありません。

プログラミングの入門書などで、「電卓を作ってみよう！」なんていうのをたまに見かけますが、入門者に電卓はあまりいい題材ではありません（RubyやPythonなら問題ありません。他の言語でも、GMPを紹介するなら大賛成です）。

電卓を作るのもなかなか大変です。

メモ

電卓で整数の計算がある程度正確にできるようになった時期

Unix (GNU bc): 1994年（遅くとも）
Windows: 1999年（遅くとも）
Mac: 2007年

Mac OS X 10.4を10.6にするには

Posted on 2009年9月4日 by inquisitor

3300円でいいみたいです（定価なら）。

「10.5から10.6へは3300円」ということだったようですが（参考：Mac OS X Snow Leopardへのアップグレード、本当はいくら？）、10.4から10.6へも3300円でいいそうです（Amazonならもう少し安いかな）。

Apple concedes that the $29 Snow Leopard upgrade will work properly on these Tiger-equipped Macs, so you can save the extra $140. (AllThingsD)

コードリーディングのための書体

Posted on 2009年9月2日 by inquisitor

プログラムを書くときには等幅フォントを使うのがいいと思いますが、読むときにはプロポーショナルフォントもありだと思います。実際、書体に注目しながらプログラミングに関する書籍を読むと、意外と頻繁にプロポーショナルフォントが使われていることがわかります。

(1) Stroustrup 『プログラミング言語C++』

C++のバイブル、Stroustrup 『プログラミング言語C++』では、コード中の識別子はプロポーショナルフォントのイタリックで印刷されています。曰く、

固定ピッチフォントのコードを見慣れたプログラマには、この表記スタイルは最初は“不自然”に見えるかもしれない。しかし、一般に、テキストの提示方法として、プロポーショナルフォントは固定ピッチフォントよりも優れていると考えられている。プロポーショナルフォントを使えば、非論理的な改行の数も減る。私が試してみたところでも、しばらくすると、ほとんどの人々がこのスタイルの方が読みやすいと感じるようになった。(p.33)

これは読みやすいと思いますが、「識別子のみ」というのがやっかいです。何らかのツールが必要でしょう。たとえば、膨大な機能を誇るWordでも、「識別子のみ」の実践は面倒でしょう。安易に、すべてをセリフ・イタリックにしたりすると台無しですし。

(2) Knuth 『文芸的プログラミング』

Knuth 『文芸的プログラミング』では、(2)のように書体が使われています。擬似コードを印刷するときによく用いられている方法ですが、実際のコードで使ってもいいと思います。

Knuthの本はタイポグラフィの勉強にもいいのですが、『文芸的プログラミング』にはこんな話も載っていました。

ある学生は、FindInNewWordsという名前を用いた。これは印刷するとあまりきれいでない。大文字は小文字の直後に並べるようにデザインしていない場合が多い。複合名詞を使用しないですますことはまず無理だから、WEBにはうまい解決法を用意してある。WEBでは、たとえばget_wordのように、短い下線で語をつなぐことができる。(p. 311)

WikiなどではfindInNewWordsのようないわゆるCamelCaseがよく用いられますが、印刷する可能性がある場合には、使わない方がいいかもしれません。（Knuthなりの対処法が『文芸的プログラミング』で紹介されています。）

(3) Stroustrup 『C++の設計と進化』

(1)でのStroustrupの試みが普及することを期待していたので、(1)の後に出た『C++の設計と進化』（日本語版）のコードが等幅フォントになってしまったのはちょっと残念でした（原著は確認していません）。等幅フォントは、プログラムの印刷に最もよく使われているのはフォントですが、必ずしも読みやすいとは言えません。（本の内容はすばらしいです。）

(4) Stroustrup Programming: Principles and Practice Using C++

1000ページを超えるプログラミング入門書（形容矛盾？）であるProgrammingでは、プロポーショナルフォントが復活しました。これが現時点でのStroustrupの結論だと考えていいのでしょう。すべてサンセリフ（というかセリフ無しローマン）に統一するこの方法は、特別なツール無しで実践できていいと思います。（日本語版は等幅です。）

個人的には、ちょっと手間のかかる(2)が、authenticで好きです。

CodeZineの連載「PEARライブラリ活用」が終了

Posted on 2009年2月1日 by inquisitor

PHPのPEARライブラリを紹介した連載が終わりました。

基礎的なことに絞って書くつもりでしたが、Amazon Web Serviceについて書いたものが最もブックマークを集めているのはちょっと皮肉な感じがします。PHPプログラマの平均的な興味と私の興味がずれているのだと素直に解釈しましょう。

~~CodeZineは一つの記事についてURLを作りすぎている気がします。~~CodeZineもはてなも、正規化タグに対応すべきだと思います。

古きMacを温ね新しきUIを知るか

Posted on 2008年6月7日 by inquisitor

Mac OSの進化を追った2冊、『MacOS進化の系譜』と『Mac OS進化の軌跡』。前者はSystem 7まで、後者はその後を扱ったものだが、私がMacを使うようになったのはOS X以降だから、読んでいてもいまいちぴんと来ないものがある。

実際に動かして試せるといいのだが、職場が職場だけに、そういうことには苦労しない（エミュレータもいろいろあるようだが、そのためのROMだって調達できるだろう）。動作するハードウェアを用意できれば、OS自体はAppleが漢字Talk7.5.3を配布しているから、それをダウンロードすればいい（漢字TalkはSystemと呼ばれたOSの日本語版で、最終バージョンは7.5.5。それ以降は「Mac OS」に統一された）。

ちなみに、漢字Talk7.5.3が世に出たのは1996年のことで、この年にはMicrosoft Windows NT 4.0も世に出た（現時点では無償ダウンロードされていない）。よく「MacはWindowsよりいい」と言われるが、それはUIのことであって、Windows NTが実現していたプリエンプティブ・マルチタスクやメモリー保護、マルチユーザ機能をMacがサポートしたのは、1999年のMac OS X Serverから。

こんなかんじ（当時これだけメモリを積んだら、いくらかかっただろう）。

このMacintoshについて

ハードウェアの歴史を追った『Macintosh Museum』によれば、1996年に出ていたのはPerforma 6420のあたり

Performa 6420

さて、実際に『Mac OS進化の軌跡』を見ながら漢字Talkをいじった後で、UIについて考えるための材料にはこんなものがある。

Linuxの作者Linusによれば、GNOMEは「seems to be developed by interface nazis」とのことだが、はたして・・・

おまけ

もっと古いところを温ねたい向きには、『Apple2 1976–1986』やレボリューション・イン・ザ・バレー―開発者が語るMacintosh誕生の舞台裏がお勧め。『レボリューション』には開発者のノートなんかもたくさん載っている。

もっともっとという向きは、『Apple I Replica Creation: Back To The Garage』でハードを作る

追記：UIデザインガイドラインのまとめ

データアクセスストラテジー

Posted on 2008年5月29日 by inquisitor

Joel on Softwareにこんな記述がありました

Microsoftから出てきたデータアクセスストラテジーの歴史につい考えてみるといい。ODBC、RDO、DAO、ADO、OLEDB、そして今度はADO.NETだ—すべて新しい! これらは技術的必然だったのだろうか？　毎年データアクセスを再発明する必要があるデザイングループの無能さの結果なのだろうか? (たぶんそうだ)。(p.134)

LINQもありますね

どんどん変わっていくのは困りますが（進歩というものでしょうか）、あまり変わらないものがたくさんあるというのもまた困ります。私の作業環境のPHPには、抽象度の低いデータベースアクセス方法がこれだけあります（JDBCだけだと言えるJavaとは偉い違いです）

PEAR DB
PEAR MDB
PEAR MDB2
MySQL
MySQLi
PHP Data Objects (PDO)

「どれを使ったらいいの？」と悩む向きのために、ちょっと調べました。汎用性やパフォーマンスから言って、新しいPHPを使える人はPDOを使うのがいいと思いますが、ある程度古い環境でも動くように、PEAR MDB2で解説しています（MySQLiとPDOでも同じことができることを示すために、サンプルファイルを付けました）

PEAR MDB2でPHPからデータベースを操作する(CodeZine)

ソフトウェア開発の名著8冊

Posted on 2008年4月3日 by inquisitor

『ソフトウェア開発の名著を読む (技評SE新書 003) (新書)』ソフトウェア開発の名著を読む
柴田芳樹
技術評論社 (2006/7/26)

「開発」というだけあって、カバーする範囲は『改訂新版コンピュータの名著・古典100冊』より狭いが、そのぶん、じっくり紹介されている（かぶっているものも多い）。読むためのモチベーションを高めるには、『100冊』よりこっちがいいでしょう（モチベーションが必要なのは、最後の2冊だけかもしれないが）。

もとが雑誌の連載だから、編集の問題なんだろうけど、この小さい本で同じ部分（『プログラミング作法』のp.50）を2回も引用するのはどうなんだろう。

大事なポイントは、良いスタイルは習慣の問題だということだ。自分でコードを書き起こす際にスタイルに配慮し、時間をとってスタイルを見直し改善していけば、良い習慣が身につくようになる。（p. 146, 179）

キーボード配列QWERTYの謎

Posted on 2008年3月17日 by inquisitor

キーボード配列QWERTYの謎安岡孝一, 安岡素子
NTT出版 (2008/03)

日記でたびたびQERTY配列に関する俗説を批判されていたから、調べられていることを知っていた人は多いと思う。その集大成を、かなり期待して待っていた私

QERTY配列に関するメジャーな俗説は次の2つ

人間がキーを打つ速さにタイプライタのメカが対応できなかったため、キー配列をわかりにくくして速く打てないようにした
TYPEWRITER社のセールスマンが、一番上の列だけを使って社名を素早く入力できるようになっている

私自身、第一の俗説を信じていて、それを披露していたこともあった（ごめんなさい）。披露して、第二の説で反論されたことも

本書は、これらがガセネタだということを、歴史を丁寧に追うことで証明した力作。前著「文字符号の歴史」は価格が「うっ」という感じだったが、今回はリーズナブル

俗説を日本で広めた人もちゃんと調査されている。広まる原因には有名人がいるわけで、

一九八七年一月、東京大学の坂村健が「アンチQWERTY説」を、（中略）という文章で流布した直後に、一橋大学の今井賢一や東京大学の石田晴久が「アンチQWERTY説」を引用し、あっという間に日本中が「アンチQWERTY説」で埋まっていった。(p.174)

なんか、各方面で敵を作りそうな・・・。ちなみに、俗説の日本での初出はおそらく1924年とのこと。日記でもいろんな例を紹介（攻撃）されている

前著の時も感じたことだが、安岡夫妻の書籍を紹介するのはちょっと難しい。というのも、

学者がその論文や著書に、歴史に関する記述を含めるのなら、当然そこには歴史学者としての姿勢が求められるはずだ。歴史の事実を追求しようという姿勢だ。しかし、現実はそうではなく、孫引きや曾孫引きがエンエンと繰り返されてきた。(p.188)

と主張する安岡夫妻の著作を引用することが、まさにその批判の対象になるだけでなく、失礼なのではないかと思われるからだ。とはいえ、

これまで肥大化し続けてきた「アンチQWERTY説」に対して、私たち夫婦の投げるこの石は、あまりに小さい。願わくば本書の読者も、今後は「アンチQWERTY説」に向かって石を投げてくださることを、切に望む次第である。(p.189)

とあるから、石を投げてみよう。援護射撃になればいいのだが

ウェブの世界でも、Googleに「QWERTY」と訊けば、いわゆる「アンチQWERTY説」が上位に出てくる。みんなの意見は案外正しくない

QWERTY配列は、19世紀後半に英文のタイプライターが開発された当初のキー配列がそのまま継承されたものであり、この配列が採用された理由については、タイプライターのバーが互いに絡みにくいように設計されたものであるという推察が有力となっている。そうであるならば、キーは故意に打ちにくく設計されていると表現することもできるため、両手全指を用いてタッチタイピングを行うことの多い現在でもQWERTY配列が最良であるか否かについて、様々な意見が飛びかっている。（IT用語辞典バイナリ, ZENetの用語解説）

タイプライターのバーが絡みにくいように設計されており、故意に打ちにくくしてあると揶揄される傾向があるが、実際には左右交互の打鍵になるように配慮して配置されている。（HitachiSystemsのパソコン用語辞典, e-Words）

IT用語辞典では、いろんな同じ文章を使い回している例がよくあって、以前から気持ち悪いと思っていた。ここで挙げた例を見ると、気持ち悪いでは済まされないことになってしまうことがわかる。もし、内容が間違っていても、いろんなサイトで使い回されていると、その間違いがなかなか消えないのだ

何故 Qwerty 配列になったのかというと、英文を平でタイプしたとき、連続して出てくる文字の統計をとって、アーム（印字を行うために紙にたたきつける棒）が交差しないように決められたものなのです。タイプライターは機械的な動作をする物なので、この Qwerty配列はもっぱら構造的な制限から決められたものだったのです。（雪下智且「キーボードの歴史」）

タイプライターのキー配列は，英字キーの最上段を左から読むと「QWERTY」となることから，QWERTY配列と呼ばれた。タイピング・スピードが高速になると印字ヘッドが交差してしまうという機械部分の問題から，あまりタイピング速度が上がらないQWERTY配列に収束していったと言われている。1880年代後半のことだ。つまりQWERTY配列は人間が機械に合わせるという妥協の結果生まれたものだ。（八幡勇一の「キーボード論」(ITpro)）

若い人の中には、もはや英文タイプライターを見たことない人もいるかもしれませんが、キーを打つと、キーで蹴っ飛ばされたアームがハンマーのように動き、インクリボンと紙を打ち、文字が印字される仕組みです。このとき、近くにある二つのキーをほぼ同時に打つと、アーム同士が押し合ってからまり、調子良く打っていたのに中断され、からまりを解くのに苦労することがありました。そこでアームの衝突を防ぐために、連続して現れることの多い文字がなるべく遠くに配置したのが現在のQWERTY 配列だという説がありますが、真偽は不明です。（キーボード配列の歴史）

「みんなの意見」は案外正しいというし、ウェブは「みんなの意見」だけを目立たせるシステムになりつつあるのだけれど、本書を読むと、そう単純でもないよなあ、と自戒せずにはいられない

欲を言えば、もっと最近の事情まで扱って欲しかった。和田先生の論文「けん盤配列にも大いなる関心を」で扱っているあたりまで。「A」の左がControlなのかCaps Lockなのかが、私にとっては大問題なのさ

追記：安岡さんにコメントで教えていただきました。以下の文献で少し現在に近づきそうです。

codepadの遊び方

Posted on 2008年3月5日 by inquisitor

コードを貼り付けてボタンを押すと実行結果を表示してくれるcodepad。（動く様子が秋元@サイボウズラボ・プログラマー・ブログで紹介されている。）

C言語のHello Worldはこんな感じ。（改行が一つ多いのでは？）

私が最初に試したのはHello Worldではなくこれ（まだ何も知らなかった数年前の私）。ほかに、

結論：最初に何を試すかを見ると面白いかも。

秋元さんはSegmentation faultを起こしたり、ppencodeを試したりしてます。
小飼さんはPerlでいろいろ試してます。ローカルファイルを覗いたり・・・

私、ここ10年くらいあまり変わってないのかしら。

参考：自分のコードを出力するプログラム

自分って何でしょう。

inquisitor

{informa,computa,evolu}tion

Category Archives: 開発環境