00:28:33 # Life likely / unlikely. Linux Kernel のソースを読んでいると、 likely とか unlikely とか書いてありますよね。 それって gcc の__builtin_expectというディレクティブを利用して実装されているわけです。 gccがよきに計らってくれるに違いないと信じてあまりきにせずに使っていますが それがどれくらい効果のあるものなのか、気になってしかたがなくこのままでは年が越せない気がしてきたので簡単に計測してみました。 計測に使ったのは core duo の MacBook です。 i386 で unlikely な場合は、どういう処理になるのかな、と gcc の出力のアセンブリをのぞいてみたら、 je が jne になったり(どっちかがどっちかのケースだとはやいのか?)、あまり実行されないはずの条件分岐の飛び先が遠くになっていた(多分 icache の関係)だけで、ちょっと考え込んでしまいました。 初回実行時だけ初期化するロジックだけを取り出した単純な例を組んでみたのですが、 この簡単な例の場合、正しい分岐予測情報を与えた場合と分岐予測の情報を与えなかった場合で、配分は違いますが、トータルでは大体同じような結果になりました。 間違った分岐予測情報を与えた場合、若干改悪しましたが、30:37 程度で、それほど悪くはなってません。 もっと劇的に違うことを期待したわけですが、そうでもなかったです。 うーむ。
volatile int flag_1=0;
volatile int flag_2=0;
volatile int flag_3=0;
main()
{
int i;
int count = 1000*1000*1000;
for (i=0; i< count; ++i)
{
if(!flag_1)
{
flag_1=1;
/* do some process */
}
}
for (i=0; i< count; ++i)
{
if(__builtin_expect(!flag_2,0))
{
flag_2=1;
/* do some process */
}
}
for (i=0; i< count; ++i)
{
if(__builtin_expect(!flag_3,1))
{
flag_3=1;
/* do some process */
}
}
}
opreport -lg の出力を適当に処理してみたもの:
CPU: Core Solo / Duo, speed 1833 MHz (estimated) Counted CPU_CLK_UNHALTED events (Unhalted clock cycles) with a unit mask of 0x00 (Unhalted core cycles) count 6000 vma samples % linenr info image name app name symbol name 08048350 612432 63.5054 proftest.c:11 a.out a.out main [flag_1] 08048360 87383 14.2682 proftest.c:17 08048365 8 0.0013 proftest.c:17 08048367 6321 1.0321 proftest.c:17 08048373 87951 14.3609 proftest.c:15 08048376 16 0.0026 proftest.c:15 0804837c 7361 1.2019 proftest.c:15 [flag_2] 08048380 15316 2.5008 proftest.c:27 08048385 8 0.0013 proftest.c:27 08048387 11404 1.8621 proftest.c:27 08048389 202678 33.0940 proftest.c:25 0804838c 2 3.3e-04 proftest.c:25 08048392 770 0.1257 proftest.c:25 [flag_3] 08048396 13327 2.1761 proftest.c:37 0804839b 4 6.5e-04 proftest.c:37 0804839d 3094 0.5052 proftest.c:37 080483a9 155573 25.4025 proftest.c:35 080483ac 29 0.0047 proftest.c:35 080483b2 21187 3.4595 proftest.c:35 */
08:44:26 # Life YARV。 カーネル読書会でYARVの話をきいてきました。 ビデオに録画されていないところで酔っ払いながら適当な話をしてきたので、 一応後で裏をとろうかなとおもってメモをしておきます。
なんかもっとあった気がするのですが、後で追加する、かも。
15:47:54 # Life git-dch 。 debian/changelog や ChangeLog ファイル、コミットの度に編集するというルールにしていると、 バージョン管理システムを利用しているとよく衝突します。 分散バージョン管理システムの場合はさらに分散して管理しておりマージまでの間隔が伸びがちのため、 マージの際にコンフリクトが起きる部分の扱いが面倒になります。 この課題についてはバージョン管理システム自体に履歴の管理システムが付随しているのだから、 それから変更履歴を生成させればよい、という発想で解決する場合が多いようです。 その代表例として git であれば git-shortlog コマンド (git-log --pretty=short | git-shortlog) (リリースアナウンスの 文書に添付するための文書を git の変更履歴から抽出するコマン ド)があったり、GNU arch であれば tla changelog コマンドがあっ たりします。 Debian Developer のために Debian の debian/changelog の専用のツールもあります。それが、 git-dch です。 git-dch -S でスナップショット用の ChangeLog を作成し、 git-dch -R でリリース用にChangeLogを修正してくれます。 バージョン番号やスナップショットであることを主張しているバナーなどが追加されてくれるので便利っぽいです。 お試しあれ。
16:45:59 # Life module-assistant でモジュールをビルドする。 module-assistant は Debian でカーネルモジュールのパッケージをビルドするのに便利なパッケージです。 従来の kernel-package を利用したモジュールビルドの方法では /usr/src/modules (もしくは MODULE_LOC )以下にファイルを展開しておいて、それを make-kpkg の modules_image ターゲットでビルドするというものでした。 module-assistant では module-assistant コマンドのメニューから選択したり、 コマンドラインでも m-a a-i モジュール名 でビルドできるようになりました。 ただ、作業のフローとしては、カーネルを入れ替える際に make-kpkg でビルドしてインストールしたあとそのカーネルでリブートし、各モジュールを m-a a-i モジュール名でインストールするという流れになっています(リブートしなくてもモジュールはビルドできますが、 現在実行中のカーネルじゃないとカーネルのバージョンを指定することになり、m-a a-i -l KVER なんてタイプするのが面倒なのでやってません)。そうすると必要になった時点までビルドするのを忘れていたりするわけです。頻繁にカーネルのアップグレードをする側にとってはなんか煩雑です。 新しいカーネルの初回起動時、もしくはカーネルのインストール時にビルドできるようにしたらよいような気がします。 どのタイミングでそれが実現できるのかなぁ、と思うに
どれでもよいのですが、postinst スクリプトでやればよい気がします。 あと課題としては、どれを m-a a-i するべきかという一覧を 管理する必要がありますな。 m-a list すると、パッケージの一覧が出力され、どのソースとバイナリがインストールされているのかの一覧が出ます。m-a list-installed をみようとしたら何も出力されませんでした。うーむ。 linux-uvc kvm kqemu madwifi をインストールしたいわけですが、その意志をどう伝えるのか。
09:28:03 # Life 東京エリアDebian勉強会報告。 12月の第35回東京エリアDebian勉強会を実施しました。 今回の参加者は 山本 浩之さん、石原怜美さん、あけどさん、吉田＠板橋さん、でんさん、前田耕平さん、小林さん、小室文さん、本庄さん、 キタハラさん、 上川の11人でした。
(+ ;;資料コピー12人分 -4334 ;;会場代 -1500 ;;勉強会費 x 10 +5000 ;;交通費 -320 ) -1154 の赤字
13:39:49 # Life ssh-copy-id コマンド。 ssh でログインする際にパスワードを入力するかわりに公開鍵認証に切り替えてますよね？ その際に鍵ってどうやっておいていますか？ authorized_keys を作成してくれるというコマンドが実は openssh には付属しています。 ssh-copy-id ホスト名と指定すればよいのですが、ホスト名にポート番号を指定しないといけない場合についてよくわからないので調べてみました。 ソースコードを読んでみると、「$1」にsshでログインするだけのようで、どうやらそこまで深い処理はしていないようなので、 たとえば localhost のポート 2222 番にログインしたい場合であれば ssh-copy-id '-p 2222 localhost' と指定したらできるということがわかりました。
01:34:53 # Life oprofile の NMUをしておきました。 9-day delayed queue にアップロードをしたので、9日後にDebian Archive にインストールされることになります。 oprofile がデフォルトでまったくつかえない状況になるため、その状況を改善するためのパッチです。
01:36:31 # Life opreport のXML出力機能。 oprofile はプロファイリングのためのツールで、その出力をするためのツールが opreport です。 opreport は通常は人間が読むための出力を出します。その出力はコンピュータ処理をするにはちょっと面倒な形式です。 しかし最近のバージョンでは、-X オプションを指定したらXMLの出力をしてくれるようになっています。 出力形式はシンプルで、XSLTを作成してXML出力をHTMLファイルに変換してみるのも簡単です。
sudo opcontrol --shutdown
sudo opcontrol --reset
sudo opcontrol --setup \
--vmlinux=/lib/modules/$(uname -r)/build/vmlinux \
--separate=library
sudo opcontrol --start
$@
sudo opcontrol --dump
sudo opcontrol --shutdown
opreport -X > XXXX.xml
xsltprocで処理するのには、コマンドラインは下記を使いました。
xsltproc opreport-op.xsl opreport-op.xml > opreport-op.html
09:09:57 # Life yc-el sponsor upload. 矢吹さんからリクエストがきていたので対応。 最初のリクエストがきたのが11月２５日で、その日に修正をお願いしたところ修正されたのが12月4日で、 そのメールにきづいたのが今日。
07:56:07 # Life Debianでのバージョン管理システム。 Debianのソースパッケージの制御フィールドとして Vcs-* フィールドが追加されたので、 どのバージョン管理システムを使っているのかという情報が確認できるようになりました。 VCSの統計をとっている人がいます。 いまのところ subversion が圧倒的で、Git がその後を追いかけている形ですね。
08:45:50 # Life SHNS。Yaari祭りがおきているみたいですね。 slashdot でもとりあげられているようなのでもう引っかかる人はいないとは思いますが、SNSというより、ソーシャルハックネットワークサービス、SHNSですな。
21:32:29 # Life メモリについて知っておくべきこと。 LWNに連載されていたのは知っていたのですが、 まとめてPDFとして公開されていたのをおくればせながら奥地さんのBlog ではじめて知りました。 プログラ ミングの際に考慮が必要なメモリアクセス関連の常識について Ulrich Drepper の論文が出ています。よく整理されているので 一読をおすすめします。
$Id: 200712.html.ja,v 1.26 2008/01/23 15:00:18 dancer Exp $