Distccを使って余剰PCで分散コンパイルする&してみた結果
例えばMozcを使いたいなと思った時、Arch LinuxにおいてMozcはAURにあるので導入にはソースコードからのコンパイルから始まるパッケージの作成が必要である*1。このコンパイルという作業だが、周知の通りマシンスペックによっては時間のかかる作業で、コンパイルが始まったが最後終わるまで待つ必要がある。コンパイルを早く終える手っ取り早い方法は高性能のパソコンを使うことだが、おいそれと高性能マシンを買えるんだったらそもそも問題にならない。しかし、高性能マシンを買う余裕はないが、今までに乗り換えてきたパソコン達が目に付くところに転がっている。このホコリを被って放置されているパソコンを使って分散コンパイルすれば、手っ取り早く、お金を掛けずにコンパイルをさっさと終わらせることができるのではなかろうか。
というわけで、Distcc(https://code.google.com/p/distcc/)というソフトウェアを使って、Mozcを分散コンパイルしてパッケージを作成してみた。加えて、makepkgの設定ファイルである/etc/makepkg.confを編集し、Distcc、Ccache、MAKEFLAGSの設定によってコンパイルにかかる時間がどれだけ変わるかを参考までに計測してみた。
あらかじめ言及しておくと、それっぽい感じのタイムが出なかったので、環境に不備がある可能性がある。データは参考までに。
今考えると分散コンパイル試すだけだったらMozcじゃなくてよかった。もっと手軽なやつにしとけばよかった。
ちなみにCcacheというのはgcc向けのワンダフルなツールである*2。
使用マシン
環境
makepkg関連
- PKGBUILD
- mozc-ut(https://aur.archlinux.org/packages/mozc-ut/)のPKGBUILDに以下の変更を施したもの。
結果
ccache、distcc、MAKEFLAGSの内、容を適宜以下の表のように変更して、それぞれの場合においてのコンパイル時間を計測した。時間の計測にはtimeを使用した。
なお、時間の計測は一回限りである。前述の通り、データは参考までに。
| ccache | distcc | MAKEFLAGS | 時間［秒］ |
|---|---|---|---|
| 875.36 | |||
| ○ | 438.30 | ||
| ○ | -j6(=3+3) | 439.66 | |
| -j3 | 950.98 | ||
| ○ | -j3 | 396.67 | |
| ○ | ○ | -j6(=3+3) | 395.84 |
| ※ | ○ | -j6(=3+3) | 451.69 |
ccache、distcc、MAKEFLAGSを効かせた場合が最速なのはいいとして、それがdistccを無効にした場合と1秒差というのはどうなんだろう。それと何も有効化していない場合よりもMAKEFLAGSを設定したほうが遅いというのも納得がいかない。2,7Mbpsという通信速度もボトルネックになっている気がする。
再計測の余地がある。
結論
Distcc便利。
*1:pnsft-purを使えばバイナリが手に入る(https://wiki.archlinux.org/index.php/Mozc)けど出オチなので見なかったことにする。
uimで./configureに--enable-kde4-appletとか--enable-notify=knotify4をつけるとコンパイルに失敗する事案の解決法
結論
automoc4とcmakeをインストールすればいい。
蛇足
cmakeのほうはhttps://code.google.com/p/uim/wiki/InstallUim#Installing_required_packagesをみればわかるのだけれど、automoc4は必要とされるパッケージとして挙げられてないので忘れがち。でもautomoc4はcmakeに必要なパッケージだし、よく考えてみれば気付くはずだからわざわざ書くようなことはしてないのかもしれない*1。
Arch Linux公式のuimでは前述のオプションは無効化されており、これを使うにはabsからPKGBUILDを取得して編集し、パッケージを作らなきゃならない。そういう事情のため、uimのPKGBUILDにおけるdepends欄やmakedepends欄にはautomoc4及びcmakeの記述はない。ストレスなくuimのパッケージを作るには前述の要項をPKGBUILDに加えるパッチをつくるとよい。
*1:私は気付かなかった
QtEmuで設定できる仮想マシンのRAMの上限を拡げる
2013-09-23 追記
本文中で触れているgendeskをbuild()から呼び出す方法ではうまくいかないというのはgendesk 0.5.4におけるバグであったようだ。現在は0.5.5になり、バグも修正された(https://github.com/xyproto/gendesk)。本文での言及箇所には打ち消し線を引いた。
QtEmuというのはQEMUをGUIで扱うためのソフトウェアだ。
QtEmuで仮想マシンをいじくるとき、RAMを1024MBまでしか割り当てられないのがけっこう不満だった。ある機会があってVirtualBoxを使った時、こいつはシステムが許す限りのRAMを割り当てることができて、RAM割り当てたい欲を満足することができた。
QtEmuが仮想マシン管理のためにつくるXML（<仮想マシン名>.qte）のmemory要素をいじくってみても変更は反映されず、どうしたもんかなあと悩んでいたが、先程、ソースコードをいじればいいのだという着想を得た。得るのが遅すぎる。
とりあえずQtEmuのソースを落としてきて、"1024"MBの制限を掛けているということから
$ find . -name '*.cpp' -print | xargs grep 1024
で全文検索を掛けた結果、machinetab.cppがそれらしいという反応を得た。このファイル中の1024を軒並み4096に変更したら、仮想マシンに4096MBまでRAMを割り当てることができるようになった。RAM割り当てたい欲を満たすことができるようになった。
パッチを書いた。手で書き換えるよりはマシだと思う。
自動的にこのパッチをあてて、https://wiki.archlinux.org/index.php/DeveloperWiki:Removal_of_desktop_filesに沿ったgendeskを行うためのPKGBUILD用パッチも書いた。
このgendeskだが、https://wiki.archlinux.org/index.php/DeveloperWiki:Removal_of_desktop_filesとhttps://wiki.archlinux.org/index.php/Desktop_Entriesで扱い方が異なっているのだけれども、どちらがよいのだろう。prepare()から叩くほうがわかりやすいかなと思うのだけれど。あとbuild()から叩いた場合うまく動いてくれず、prepare()からだと動いた。環境依存かもしれず怖い。
KonquerorやAkregatorとかの見た目がたまにショボくなる
KonquerorとかAkregatorはデフォルトで使用すると起動時は以下のような感じになる。
Konqueror
Akregator
ただ、ふと思い立ってKonquerorをきちんと使おうとしていろいろいじくってみると、Konquerorの見た目が以下のようにショボくなることがあった。
Konqueror（ショボい）
Konquerorだけ影響を受けるのならまだわかるのだが、なぜかAkregatorにも影響が及んでしまってこちらもショボくなる。スクショを撮り忘れたが、他にもSystemsettings（KDE システム設定）などもショボくなった。
Akregator（ショボい）
短期記憶力が絶望的に欠如しているのでいつもKonquerorのどこをいじくったか忘れてしまって途方に暮れてしまい、これまではホーム直下の.kde4/share/configをリネームしたり削除したりで対応していた*1*2。
が、奇跡的に今日は短期記憶力がそれなりに使える日であったようで、直前に設定したAdblockのフィルターの設定（Konquerorの設定からWeb Browsing→AdblocK Filters）をデフォルトに戻したら、ショボい見た目がいつもの見た目に戻った。
場当たり的な解決法で気持ち悪い。KonquerorでAdblocKを使っても見た目がショボくならない方法を見つけたい。
crfppを正しくインストールするためのパッチ書いた&"pkgdir"と"startdir/pkg"の違い
昨夜、cabochaで遊ぼうと思ってkonsoleからコマンドを叩いたら以下のようなエラーを吐かれた。
cabocha: error while loading shared libraries: libcrfpp.so.0: cannot open shared object file: No such file or directory
libcrfpp.so.0がないんですって。早速findで検索かけたがたしかに見つからない。crfpp(CRF++)はcabochaの依存関係に含まれるものであるのでインストールされてあるはずなのだが。
浅薄なのはわかっているがここでcabochaの再インストールを試みた。が、今度はcabochaのコンパイルで以下のエラーが出てきた。
chunk_learner.cpp:6:19: fatal error: crfpp.h: No such file or directory
これcrfppがどうにかなっているんじゃないか。ということでcrfppのPKGBUILDを見てみる事にした。すると現在は使用が非推奨になってる変数であるstartdir*1を用いてbuild()とかpackage()を書いていることがわかったので、startdir/pkgをpkgdirに、startdir/srcをsrcdirに変更してmakepkg、インストールした。この結果、cabochaのコンパイルも無事成功してきちんとcabochaが動いてくれた。
AURのcrfppでもいちおうこの旨をコメントしておいたので重複するが、きちんと使えるcrfppのパッケージを作るためのパッチを下のリンクにおいておく。
さて、なんでstartdirを使うとダメでpkgverおよびsrcdirを使うといいのかちょっと観察してみることにした。
まずtreeを用いてstartdirを使った場合とpkgdirおよびsrcdirを使った場合のディレクトリの様子をみた。通常makepkgするとPKGBUILDが存在するディレクトリ内にpkgとsrcの2つのディレクトリができるが、src下についてはstartdir/srcとsrcdirで内容に差異がなかったので省略する。
- startdir/pkgの場合
. ├── CRF++-0.58.tar.gz ├── PKGBUILD ├── crfpp-0.58-1-x86_64.pkg.tar.xz ├── pkg │ ├── crfpp │ └── usr │ ├── bin │ │ ├── crf_learn │ │ └── crf_test │ ├── include │ │ └── crfpp.h │ └── lib │ ├── libcrfpp.a │ ├── libcrfpp.la │ ├── libcrfpp.so -> libcrfpp.so.0.0.0 │ ├── libcrfpp.so.0 -> libcrfpp.so.0.0.0 │ └── libcrfpp.so.0.0.0 └── src
- pkgdirの場合
. ├── CRF++-0.58.tar.gz ├── PKGBUILD ├── crfpp-0.58-1-x86_64.pkg.tar.xz ├── crfpp.patch ├── pkg │ └── crfpp │ └── usr │ └── local │ ├── bin │ │ ├── crf_learn │ │ └── crf_test │ ├── include │ │ └── crfpp.h │ └── lib │ ├── libcrfpp.a │ ├── libcrfpp.la │ ├── libcrfpp.so -> libcrfpp.so.0.0.0 │ ├── libcrfpp.so.0 -> libcrfpp.so.0.0.0 │ └── libcrfpp.so.0.0.0 └── src
PKGBUILDがあるディレクトリをカレントディレクトリとして.(ドット)、インストールするプログラムの名前をfooと表せば、startdirはそのままカレントディレクトリを指し、結果startdir/pkgは./pkgを指す。しかしpkgdirは./pkg/fooを指す。startdirをつかってインストール先を直接指定するよりは、pkgdirを用いて動的にインストール先を指定してもらったほうが便利だよ、という話のようだ。
また、ふたつのtreeの結果をみるとわかるが、startdirを使った方はインストール先が./pkg/usr/binとなっているのに、pkgdirを使うと./pkg/crfpp/usr/local/binとなっている。crfppのMakefileには"prefix = /usr/local"が宣言してあり、pkgdirを使うとこのprefixが使用されるがstartdirではこれが使用されないようだ。結果、インストール先のディレクトリ構成が異なってしまう。ただ、Arch Linuxはすべてのパッケージは/usrを使用すべきとしており*2、その場合"prefix = /usr/local"という宣言は殺してしまうのがいいのかもしれない。./configureで--prefix=/usrしてるだけだった。
Nexus4買った
2013-05-31 追記
大変遺憾なことにNexus4は盗難に遭い、現在私の手元にない。仕方ないので画面の割れたGalaxy Nexusを持ち歩いている。
2013-06-07 追記
無事に戻って来た。
4月上旬のある日の外出中、携帯(Galaxy Nexus)を地面に落下させた。
パーンという不吉な音がしたものの、あちゃー迂闊だったなーやっちまったなーと気楽な気持ちで拾い上げたら想像以上のことをやってしまっていた。
これはいけない
まさか自分が液晶パネルを割るとは思ってもみなかった。
動揺して色々早まった行動を繰り返し、紆余曲折の末Nexus4を個人輸入してしまった。
そして先日、Nexus4が届いた。個人輸入は長期休暇中にすべきという教訓を得た。
はこ
ブツ
いまさらな端末でありスペックも現行の最新機種と比べて特に優れているということはない（らしい）Nexus4ではあるが個人的には十分すぎるほど高性能な機械だ。
「入門 自然言語処理」第12章を読む上で必要なソフトウェアまとめ
今日（正確には昨日）ようやく「入門 自然言語処理」を読み終えた。
かなり面白い本だったが、冒頭に必要であると明記されたソフトウェア群だけでは章が進むにしたがってだんだん内容をカバーしきれなくなっていて、いろいろとソフトウェアの追加をしなきゃならなかったりしてお茶目だと思った。11章まではそれで通った。
が、12章に入ってから、扱う言語が英語から日本語にシフトしたためにNLTKではカバーできなくなり、形態素解析や構文解析に使うためのソフトウェアを続々追加していかなきゃならなくなった。このソフトウェアたちが曲者で、Arch Linuxの公式レポジトリにない、AURにないの連続で、pacmanないしyaourtを叩いて待ってればオワリというわけにはいかなかった。もちろん今は時代が進んでいるので
./configure make make install
とか
python2 setup.py build sudo python2 setup.py install
などとやれば簡単にインストールはできるのだけれど、困ったことに私は潔癖症の気があるようで、パッケージはpacmanで管理できないと嫌だ、という奴なのだ。半ば自分の潔癖症のせいでブチ切れながらPKGBUILDを書いてmakepkgを叩くということをしながら12章を読んでいたら、本文を読んでいる時間よりもPKGBUILDを書いてる時間のほうが長くなってしまったという悲しい結果に終わってしまった。
さて、このようにブチ切れながらこの大変おもしろい本を読むような悲しい人間をこれ以上出さないために、12章を読む上で要求されるソフトウェア群を以下に列記する。12章を読む前にこれらをインストールして動作する状態におけばストレスを感じることなく本文を読むことができるだろう。
なお、下にあるもので「AURになかった」ものについては私がPKGBUILDを書いてAURに公開しておきましたのでよろしければご利用ください。
形態素解析系
最初に使われる形態素解析エンジン。AURにある(mecab)。
Mecabのpython用インターフェース。AURにある(python2-mecab等)。
次に使われる形態素解析エンジン。AURになかった。
構文解析系
- CaboCha(https://code.google.com/p/cabocha/)
日本語係り受け解析器。AURになかった。
- CaboCha-python(同上)
CaboChaのpython用インターフェース。AURになかった。
日本語構文・格解析器。ファイルサイズがすごく大きい。AURになかった。
