玩式草子─ソフトウェアとたわむれる日々

第15回 久しぶりの新PC

この記事を読むのに必要な時間:およそ 5 分

新PCのパフォーマンス

新しい環境が使えるようになったので,さっそくパフォーマンスを調べてみることにしました。CPUやメモリ,ビデオカード単体の性能はPC情報サイトなどにも多数上がっているので,今回はPlamo Linuxの開発の際に実際に遭遇する,時間のかかる処理がどれくらいスピードアップするかを調べてみました。

まず,今回テストに用いた各PCのハードウェア的なスペックを整理しておきましょう。

表2 テストした各PCのスペック


製造年CPUMemory
Xeon機2004Xeon 2.8GHz dual HT対応(4CPUに見える)ECC付き DDR2 3Gバイト
Athlon機2006Athlon64 X2 4400+(2.2GHz)(2CPUに見える)ECC無し DDR2 2Gバイト
Corei7機2010Corei7 870(2.93GHz)HT対応(8CPUに見える)ECC無し DDR3 16Gバイト

この3台のPCで,まずは大規模ソフトウェアのコンパイルにかかる時間を調べるために,Plamo-4.73で採用しているlinux-2.6.32.15のフルコンパイルにかかる時間を計測してみました。

計測は,必要なパッチをあてて,実際にPlamo-4.73で使っている状態にしたlinux-2.6.32.15のソースコードを,各PC上でフルコンパイルするのに要する時間をtimeコマンドを用いて測定しました。コンパイルはそれぞれのPC上で2,3回ずつ実行し,結果の平均を求めています。

実際のコンパイル作業の前にはmake cleanを実行して既存のオブジェクトファイル等を削除しておき,処理を可能な限り並列化するために,それぞれのCPU数+1の値をmakeの -j オプションの引数に指定してコンパイルしました(Corei7 なら make -j9)また,実際の利用環境を反映する意味で,デスクトップとして使うCorei7機とAthlon機はKDE環境を実行しながら,ファイルサーバとして使うXeon dual機はVMware-serverを実行しながら,コンパイルしてみました。

カーネルコンパイルにかかった時間の平均値はこのような結果となりました。

表3 linux-2.6.32.15 のコンパイル時間

Xeon機2670秒(44.5分)
Athlon機1864秒(31分)
Corei7機442秒(7.4分)

この結果を見ると,新しいCorei7機は,Xeon機に比べると6倍強,Athlon機に比べると4倍強の速さでコンパイルを完了しているようです。

Corei7機のコンパイル中の様子を top コマンドで眺めると,HTで分身した分を含む8つ全てのCPUが忙しくコンパイルしているようです。

図5 8CPUが並列処理している様子

% top
top - 12:31:30 up 13:57,  5 users,  load average: 6.94, 2.39, 1.07
Tasks: 259 total,   9 running, 250 sleeping,   0 stopped,   0 zombie
Cpu0  : 90.7%us,  6.3%sy,  0.0%ni,  3.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  : 90.3%us,  5.0%sy,  0.0%ni,  4.0%id,  0.7%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  : 88.4%us,  9.0%sy,  0.0%ni,  2.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  : 90.7%us,  7.3%sy,  0.0%ni,  2.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu4  : 91.0%us,  6.3%sy,  0.0%ni,  2.0%id,  0.7%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu5  : 90.1%us,  6.3%sy,  0.0%ni,  3.6%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu6  : 89.3%us,  7.7%sy,  0.0%ni,  3.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu7  : 94.7%us,  3.3%sy,  0.0%ni,  2.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  16626776k total,  8376620k used,  8250156k free,   413796k buffers
Swap: 48837596k total,        0k used, 48837596k free,  6883180k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
26708 kojima    20   0 40904  34m 4580 R   27  0.2   0:00.80 cc1
26721 kojima    20   0 25960  20m 4860 R   19  0.1   0:00.58 cc1
26772 kojima    20   0 24632  18m 4736 R   10  0.1   0:00.31 cc1
26791 kojima    20   0 23564  16m 2612 R    9  0.1   0:00.26 cc1
 5051 root      20   0  363m 183m 106m S    6  1.1  10:49.16 X
26796 kojima    20   0 19056  11m 2452 R    5  0.1   0:00.16 cc1
11683 kojima    20   0  346m 148m  29m S    5  0.9  11:06.57 firefox-bin
26808 kojima    20   0 14400 7100 2416 R    2  0.0   0:00.06 cc1
 5295 kojima    20   0  126m  29m  17m S    2  0.2   0:55.56 konsole

ディストリビューションの開発といった作業をしていると,コンパイルオプションをあれこれ調整しながら何度もパッケージを作り直すような作業がよくあるので,コンパイル速度が4倍強になるというのは魅力的です。ターンアラウンドタイムが短くなればそれだけ試せる項目を増やせますし,思考が途切れる時間が短くなれば,開発効率も上がりそうです(もちろん希望的観測ですが :-)。

もうひとつ,時間のかかる作業の例としてsqaushfsの作成を取りあげてみましょう。

本連載でも紹介したように,squashfsとLZMA圧縮を組み合わせれば,5Gバイト強のファイルシステムを1.6Gバイト程度に圧縮することができます。しかしながら,それだけの圧縮率を得るためには大量のCPU資源を必要とし,既存の開発環境ではそう頻繁にsqaushfsを作り直すことができませんでした。

カーネルコンパイル同様,mksqaushfsでP-Plamoのsquashfsイメージを作るのにかかる時間を,timeコマンドでそれぞれ3回ずつ計測し,その平均を取ってみたところ,以下のような結果となりました。ここでも新しいCorei7機はAthlon機と比べて4倍強,Xeon機に比べて6倍強の結果となっているようです。

表4 P-Plamoのsquashfsを作成するのに要した時間

Xeon機2242秒(37.4分)
Athlon機1583秒(25.9分)
Corei7機387秒(6.5分)

興味深いことに,squashfsの生成という作業でもCorei7機はAthlon機に比べて4倍強,Xeon機に比べて6倍強の改善という,先に示したlinuxカーネルのソースコードのコンパイル時とほぼ同等の結果となりました。

この結果は恐らく,CPUが増えたことによる並列化の効果から説明できるでしょう。

Linuxカーネルのソースコードは並列コンパイルが効くように調整されており,SMP等でCPUが増えると,ほぼそれに応じてコンパイル速度が改善することがよく知られています。一方,mksquashfsもCPUの数に応じて圧縮処理を自動的に並列化してくれるので,CPUの数が増えればそれだけ処理速度は改善します。

図6 8CPUでmksquashfs実行中

$ time mksquashfs squashfs-root squashfs.img
Parallel mksquashfs: Using 8 processors
Creating 4.0 filesystem on squashfs.img, block size 131072.
[=/                                                                         ]   5053/237425   2%

そのように考えると,HTで8コアに見えるCorei7と2コアのAthlon64 X2の性能比が4:1というのは,ほぼコアの個数比になっているので,1コアあたりの性能で言うとAthlon64 X2はずいぶん善戦しているとも言えそうです。

むしろコアあたりの性能向上が限界に近づいてきたので,マルチコアの方向に振るようになったのがここ数年のCPUデザインの流れと言うべきでしょうか。

一方,Xeon機と比べるとコアの個数比は8:4=2:1だから,コアあたりの性能比は3倍くらいと見積れそうです。このXeon CPUは,現在流通しているXeonとは異なるPentium4世代のXeonで,クロック数こそ2.8GHzと高いものの,クロック数あたりの命令実行数では最近のCPUに比べてかなり見劣りすることがこの結果につながっているようです。もっとも,この差はここ6年ほどの間のIntelの開発努力を評価すべきだと思います。

以上,簡単なテストでしたが,新しいPCは以前の開発用PCに比べて,並列化が効く作業ならば4倍強のパフォーマンスを示すことが分かりました。これぐらい高速化できれば,時間がかかって辟易していたlinuxカーネルやfirefox/thunderbird, GNOMEやKDEのビルドといった作業にも気軽に取り組むことができそうです。

また,新しいCPUはVTやx86-64機能にも対応しているので,旧環境では手を付けられなかった仮想化や64ビット化にも取り組めるはずです。これからの夜長の季節に,このPCでどんな新しい機能をPlamo Linuxに組み込んでやろうかと,あれこれ妄想している今日このごろです。

著者プロフィール

こじまみつひろ

Plamo Linuxとりまとめ役。もともとは人類学的にハッカー文化を研究しようとしていたものの,いつの間にかミイラ取りがミイラになってOSSの世界にどっぷりと漬かってしまいました。最近は田舎に隠棲して半農半自営な生活をしながらソフトウェアと戯れています。

URLhttp://www.linet.gr.jp/~kojima/Plamo/index.html