巻頭言 －Asia BSD Conferenceに参加しよう

FreeBSD 7.0-RELEASE発表直後の開催となる、BSDに関連した国際会議、Asia BSD Conference 2008の開催がいよいよ今週後半（3月27～30日）に迫ってきたので注意喚起のため紹介しておきたい。Asia BSD Conference は2004年に台湾で、次いで2007年に東京大学で開催され、東京理科大で開催される今回で3度目を数える。一般論文と招待論文からなる本会議ならびに、先立って開催されるチュートリアルから構成される。

プログラム をざっと拝見したところ、今回のテーマであるSMPに関連してRandall Stewart氏による「P8B: Reducing Lock Contention in a Multi-Core System⁠」⁠、来週紹介する予定のファイルシステムに関しては「GEOMクラス」の活発な開発者であるPawel Jakub Dawidek氏による発表、「⁠P5B: GEOM-in Infrastructure We Trust」や、BSD創成期から今日まで継続した息の長い活動で知られるMarshall Kirk McKusick氏の「P9B: A Brief History of the BSD Fast Filesystem」などが筆者の興味をそそられる。

参加費についても学生登録料の異常な割安感は特別として、一般も食事付きでこの価格は破格のサービスといえる（もちろん技術評論社を始めとしたスポンサーの貢献大であると推察する⁠）⁠。筆者自身はヨーロッパ出張中のため参加できないのが残念だが、昨年と同様、今回も盛会となることを願っている。

止むことなきプロセッサの性能向上

最初電卓向けとして開発された「4004」から37年もの間、マイクロプロセッサは右肩上がりの進歩を続けてきた。マイクロプロセッサの性能の中でも処理速度は最も重要である。速度が向上することで複雑な情報処理にかかる時間が現実的な範囲にまで短かくなることで、結果としてより新しく高度な計算手法、新しいソフトウェアを生み出す原動力となるのである。実際、より高い機能を求めてソフトウェアの規模は膨れあがる一方なので、プロセッサの処理速度向上への要求は今後も絶えることが無いであろう。

筆者は簡単にマシンの性能を測定する指標として、カーネルのコンパイルにかかる時間を数年前から定点観測している。表1は4.6.2-RELEASEから7.0-RELEASEまでのバージョンのカーネルコンパイルにかかる時間をまとめたものである。4.6.2から4.8で所要時間が漸増したと思うと、Pentium MやCore Duoのような新しいアーキテクチャによって激減するなど、まるで最近の株価の動きを見ているかのようである。

プロセッサの性能向上は、半導体製造技術の進歩によって、より微細なトランジスタや配線ができるようになったことが一番の原因である。プロセッサで用いられている「MOSトランジスタ」のON/OFFを切り替えるために、入力端子につながっているゲートキャパシタ（コンデンサ）中に電荷を充電ないし放電しているわけだが、ゲートキャパシタの充放電はさらに1つ前の段のトランジスタをONすることで行っている（ドミノ倒しを想像するとよい⁠）⁠。より微細な（専門用語では、ゲート長の短かい）トランジスタを作製することで、電流駆動能力が向上すると同時に駆動するべきゲート電荷量が減少するので、結果として充放電速度が向上するという仕組みである。

充放電速度が速くなれば、プロセッサのクロックを高めることができるので、筆者が小学生のころは数MHzがせいぜいだったクロック周波数は文字通り加速的に向上し、Pentiumの登場で100MHzの壁を突破、さらにPentiumIIIに至ってGHzの壁を突破するなど、トランジスタの微細と呼応してクロック速度が向上してきた。

ところがこの右肩上りの速度向上も2004年末にインテルが「4GHz Pentiumプロセッサの開発を断念」すると発表したところでひとつの転換期を迎える。チップあたりの発熱量が技術の限界に近付いてきたことが理由であった。

というのも、トランジスタは状態を切り替えるたびに電荷を電源から取り、グランドに捨てているので、電荷を捨てるエネルギーは最終的には熱に変わる。1回1回の充放電で生まれる熱量は小さくても、クロックの掛け算によりまとまった量の発熱となり、これがたった1、2cm四方のチップから出てくるのだから無理もない話である。

代わりに取った戦略のひとつが、消費電力を絞ったプロセッサを1チップ中に複数導入し、マルチプロセッサの協働によって全体のスループットを向上させる戦略である。 その後Pentium D、Core Duo、Core Duo2といったマルチコアのプロセッサが2005年ころから登場しはじめ、現在ではマルチコアでないプロセッサを探すのが難しいほど、マルチコアの全盛期を迎えている。

SMPngと性能のベンチマーク

これらのマルチコアCPUは、同一構成のプロセッサを複数同じCPUバスに接続するSymmetric Multi Processor (SMP、対称型マルチプロセッサ）アーキテクチャであり、システムの外からは1つのCPUだが実際は複数のコアが分担して計算処理を行っている。この「分担して計算処理」を実際に行わせているのはOperating Systemの役割であり、OSの出来不出来によって得られるパフォーマンスは大きく異なってくる。FreeBSDでもこのSMP機能を古く（3.x時代）から実装してきたが、FreeBSD 7.0-RELEASEで採用されている機能は、SMPng（SMP next generation）プロジェクトの成果である。

SMPng自体はバージョン5.x時代から存在しているので、すでに御存知の読者諸君も多いことと思う。FreeBSD 7.0-RELEASEでの大きな変更点は、GENERICカーネルでこのSMP機能がオンになったということで、わざわざカーネルを再コンパイルしなくても、OSをインストールした直後から使えるようになったという点が進歩である。くどいようだが「デフォルトを安全側に振る」ことで、ユーザの無益なトラブルを未然に防止するというのがFreeBSDの思想であるから、デフォルトがオンになったということは、エンジニアリングチームの相当の自信が見て取れる。

マルチコアCPUをお持ちの読者諸君であれば、現在走っているプロセスを表示する「top」コマンドの出力が変わり、リスト1のように、「⁠CPU番号」を表す列が表示されるようになったことに気付くことと思う。一方、6.3以前のGENERICカーネル、もしくはシングルコアのマシンでは、リスト2のように、CPU番号は表示されない。

last pid: 52569;  load averages:  0.00,  0.00,  0.15    up 0+02:37:02  00:39:49
25 processes:  1 running, 24 sleeping
CPU states:     % user,     % nice,     % system,     % interrupt,     % idle
Mem: 19M Active, 734M Inact, 147M Wired, 25M Cache, 111M Buf, 68M Free
Swap: 1997M Total, 1997M Free

  PID USERNAME    THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
  745 root          1  76    0  1436K   760K select 1   0:00  0.00% moused
  794 root          1   5    0  5160K  2740K ttyin  1   0:00  0.00% csh
  585 root          1  76    0  1404K   884K select 1   0:00  0.00% syslogd
  644 root          1  76    0  1296K   692K select 0   0:00  0.00% usbd
 1155 root          1   5    0  4968K  2548K ttyin  1   0:00  0.00% csh
  514 root          1   4    0   528K   284K select 1   0:00  0.00% devd
52556 root          1   4    0  6300K  2744K sbwait 0   0:00  0.00% sshd
  713 root          1  76    0  3552K  1744K select 0   0:00  0.00% sshd
 2022 root          1   5    0  4968K  2548K ttyin  0   0:00  0.00% csh
 3883 root          1   5    0  4968K  2580K ttyin  0   0:00  0.00% csh

last pid:   820;  load averages:  0.61,  0.26,  0.10    up 0+00:01:26  00:43:16
26 processes:  1 running, 25 sleeping
CPU states:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
Mem: 8612K Active, 4948K Inact, 28M Wired, 14M Buf, 951M Free
Swap: 1997M Total, 1997M Free

  PID USERNAME    THR PRI NICE   SIZE    RES STATE    TIME   WCPU COMMAND
  809 root          1   4    0  6300K  3284K sbwait   0:00  0.00% sshd
  813 work07        1  20    0  4792K  3064K pause    0:00  0.00% tcsh
  794 root          1   5    0  4964K  2836K ttyin    0:00  0.00% csh
  786 root          1   8    0  1764K  1448K wait     0:00  0.00% login
  585 root          1  96    0  1404K  1072K select   0:00  0.00% syslogd
  820 work07        1  96    0  2360K  1568K RUN      0:00  0.00% top
  811 work07        1  96    0  6280K  3328K select   0:00  0.00% sshd
  720 root          1   8    0  1396K  1064K nanslp   0:00  0.00% cron
  787 root          1   5    0  1352K   936K ttyin    0:00  0.00% getty
  793 root          1   5    0  1352K   936K ttyin    0:00  0.00% getty
  791 root          1   5    0  1352K   936K ttyin    0:00  0.00% getty

実装ができれば性能について議論したくなるのが人情であり、議論のため「ベンチマーク」を行い「ランキング」を行ってみたくなるものである。特にFreeBSD 7.0-RELEASE が出るにあたって、SMPでの処理性能の向上が謳われているのでなおさらである。開発者の間では、サービスプロバイダで多用される、Apache + MySQL + PHP/Perl（この頭にLinuxをくっつけるとLAMPとなりFreeBSDが置き換えを狙う重要なターゲットの一つである）環境を想定したベンチマーク談義が盛んに行われている。

一般的に、高負荷でもへこたれないのはFreeBSDという評判をよく聞くが、環境の調整のやり方（チューンアップ含む⁠）⁠、ベンチマークの行ない方、そもそもベンチマークがどのくらい現実に役に立つのかも含めて、なかなか1つの答に収束することは難しいというのが筆者の考えである（下記コラムも参照のこと⁠）⁠。

kernelコンパイルでパフォーマンス試験

筆者はどちらかというと日本語デスクトップ環境とコンパイル環境が揃っていれば満足する、末端の一ユーザなので、筆者の日常生活とはあまり関係がないMySQLのパフォーマンスについては、すでに多くのサイトで議論されていることもあり、本稿では述べないことにする。代わりに、OSを新しくしたときの常套評価手段としている、kernelコンパイルでパフォーマンス試験を行ってみた。とくに、SMPではmake -j (数字) でジョブの数を増やすことである程度まで性能が向上することが知られているので、その効果を重点的に観察することにした。

手法は至って簡単で、GENERICカーネルを tcsh上でtime makeしたときの時間を測定している。

# cd /sys/i386/conf
# config GENERIC
# cd ../compile/GENERIC
# make depend; time make -j (並列ジョブの数)

Core2 Duo E6550 2.33GHz ＋メインメモリ 1Gバイト マシンでコンパイル時間はそれぞれ表2のようになった。7.0-RELEASEと、比較のためSMPカーネルを有効にした6.3-RELEASEでの結果を記載する。

このうち、パフォーマンスとして最も大切な項は左から3列目の「全体としてかかった時間[s]」である。注目するべき点として、6.3-RELEASE、7.0-RELEASE共に、並列度が「3」のときにコンパイル時間が最短となり、その後は徐々に性能が悪化するという事実が見てとれる。単純にデュアルコアだからジョブ2つが最適かというと、そうでもないようだ。

比較を始めると、どうでもQuad Coreのマシンでの結果が知りたくなったので、卒業生の杉浦君に頼んでQuad Core 2.8GHz メインメモリ2Gバイトの環境でコンパイルを行ってもらった。

こちらは、少なくとも8並列までジョブを一度に投入するまでの性能向上が得られるようである。これをもってQuad coreの方が性能向上率が大きいとするのは早計であるが、1つのヒントにはなるだろう。

もう一点、表2を見ると、7.0-RELEASEではCPUの利用率[%]があまり伸びないことに気付かされる。たとえば6.3-RELEASEのSMPカーネルでは、最大150％のCPU効率であるのに対し、7.0-RELEASEでは124％までしか利用できていない。このため筆者は当初、7.0-RELEASEの方が効率が悪くなったのかと思ったのだが、シングルCPU（Pentium M 2GHz）との比較をすることで、全体としての効率は向上していると結論することができた。Pentium Mで6.3-RELEASEと7.0-RELEASEとをコンパイルした結果は表4のとおり。

Pentium MはシングルコアのためSMPの影響を受けないので、6.3-RELEASEに対して7.0-RELEASEのコンパイルに必要な時間は、925.5÷586.3＝1.57倍に長くなっていることがわかる。一方、マルチコアのCore2 Duoマシンでは863.8÷586.3＝1.47 倍にしか延びていない。ピークパフォーマンス（-j 3）で比較しても1.49倍止まりである。 Pentium Mを基準にしたときのCore2Duoで得られた差分は、7.0-RELEASEのSMPカーネルが6.3-RELEASEのカーネルに対して効率が上がっている分だと勘定できる。トータルのコンパイル時間は7.0-RELEASEになって長くなっているので、あまりメリットとして感じられないのは確かだが、確かに効率は改善していると考えてよいだろう。

同時に、今後デフォルトのスケジューラとしての採用が見込まれる新スケジューラ「ULE」でも同様の比較を行なったが、カーネルのコンパイルという目的に対してはどちらも似たり寄ったりの結果であった。4BSDスケジューラがもともと優秀だったと見るか、ULEがBSDと張り合えるくらい優秀になったと見るか、それぞれの見方次第であろう。

本記事で行ったコンパイル試験は、まったく単純な作業だが組み合わせの数が多く、トータルで100回以上コンパイルを行うことになり、思いの他時間を取られてしまった。読者が全員筆者の真似をすると地球環境に良くないと反省し、結果の生データをこの記事の最後に置いておくので興味があれば参照されたい。

• コンパイルテスト結果［完全版⁠］⁠ compiling.zip