ac12+ck5の混合パッチ、ck5のみ、gentoo-dev-r7、ac12のみ
まず、結果だけ先に言うと数値だけで言えば、総合的な結果でgentoo-kernelとacのみ(たぶんvanillaも)に軍配があがると思われます。ckは数値上でおもわしくない結果を残してはいますが、実際デスクトップ用途として使用した場合の体感的な性能の違い(如実にわかる)は優秀であったと思います。xmms等で曲を流している時に時折起る、音切れ等といった事が起らなくなりました。私の場合、旧世代のUSB audioという事もあって切れる頻度は高く、WindowsでもLinuxでも音切れしていたので半ば諦めていましたが、意外なところ直ってよかったです。acでも音声が切れる事はありませんでした。
用途を考慮した上で私の場合はacがベストという事になりました。
あと、ckでのVMware(上のWindows)の性能はおもわしくなく。gentoo-devより遥かに悪い(使えば遅いとすぐわかるくらい)と言えます。遅いポイントはまずファイルの入出力と、メモリアクセスかなと思います、また描画性能も加えて低下しているように感じます。これはスケジューラやVMにチューニングがかかっていて、それとの相性問題と言えると思います。それ以外では全くもって好調。数値を気にせず単純に快適な環境が欲しいというのであれば、ckはオススメです。acにおけるvmwareの動作は良好でした。ckの時のような引掛り(ガクつく)は無く、正常に動作しています。
とりあえず、acかckあたりを使っておけば今のところOKかなと思います。
さて、まずはベンチ結果がない事には始まりませんので、別ファイルとしてアップします。
ベンチ結果
EUCのテキストですので御注意。
まずは環境についてですが、一般的な古すぎず新しすぎないx86ノートPC上で状況の違いはkernel(に適用したパッチ)だけです。値の大小に着目するのではなく、kernel毎の数値の差に着目していただきたいので詳しいハードの説明は無しにします。どのような違いが出るかさえわかれば問題ないはずです。
でわ、順を追ってパッチ適用による性能の変化を見てみましょう。
まずは、Processor。結果をまとめたファイルの上部にパッチのバージョンに関する補足があるので参照ください。ac+ckでは他のものに比べてopen closの値が大きくなっています。他の項目はおよそ似たり寄ったりですが、平均的に見てacが優秀であるように思われます。
次に、Basic integer operations。ほとんど違いはないと言っていいですが、mulにのみ違いが現われています。こちらではac+ckが最も優秀となっています。acかckどちらか適用の場合には200減り、両方適用した場合は合計で300減るという事のようです。
次に、Basic float operations。ac+ckとacのみの場合の値が全く同じ、さらにckのみとgentoo-devの値が全く同じのようです。acで何らかの変更が加わっているのでしょう。この項目だけではac+ckとacが優秀という事になります。
Basic double operationsについては、更に差が出にくいようで、最も優秀なのはac+ckで他は皆同じとなりました。
次に問題Context switchingですが、結果はバラバラです。ac、ckではどちらもスケジューラやvm周りのチューニングが入っているので性能差が出るのは当然です。結果はファイルを参照していただくとして、それぞれに個性や得意分野が見られます。とても面白い結果となりました。一見遅いck+acですが他のものに比べてムラが小さく平均的と言えると思われますし、2p/0Kで好成績を出したgentoo-devはスイッチングが厳しくなるにつれてパフォーマンスが落ち16p/64Kではビリです。ckが得意とするのは中間的な部分以下で8p/16Kでは最も好成績です。acにおいても似たような傾向にありますが、こちらはckの得意分野ではほんの少し(誤差？)劣るものの、逆に苦手な部分ではほんの少し(誤差？)勝っています。そのacとckを統合した結果が可もなく不可もなくといった状況を産んでいるのだと思われます。
*Local* Communication latenciesでも上記と同じ傾向が見られます、コンテキストスイッチに関しては前述したので省略して、pipeに着目しましょう。いずれもgentoo-devよりは好成績となっていますが、最優秀はck patchとなってます。acではgentoo-devに比べ高速されていますが、ckに比べコストの高い処理をしているようで、複合した場合ではckの足を引っ張る形になっています。
File & VM system latenciesを見てみましょう。こちらでは文句無しにac patchが最優秀です。個々の処理のオーバーヘッドが肝なのか、同じacを適用してあるck+acの性能が思わしくないのはck+acで処理が重んでいるせいでしょう。
*Local* Communication bandwidthsはこれまでと違って大きければ良いので注意してください。この場合も得意不得意があるようですが、総合的にみてgentoo-devが優秀であるよう思われます。ただメモリの読み書きに関してはac+ckが僅差で勝利という形になっていますが、誤差の可能性もあります(このベンチプログラムを見る限りある程度の信頼性はあるとは思いますが)。
Memory latenciesに関してはac+ckが優秀でした総合的に見てこちらではacがビリかと思われます。
ついでに、ckパッチを当てた状態のkernelにacを当てるべく色々と辻褄合わせをしていたわけですが、その時に気付いた事を挙げておくと、ckとacでは含まれるパッチのコーディングスタイルが若干違います。ckとacには同じ処理をする異なる方法で実装されたコードを含むパッチが入っていて、ckに含まれるコードにはgotoを用いた定型処理があります(ある条件の時は特定の値をreturnするというもの)。これは以前のLinuxにはよく見られたコードなわけですが、acでは各条件毎にreturnしてます。最近はacの方の書き方が主流かと思われます。ck側のgotoの使い方としては理想的で素晴しいgotoの使いぶりなわけですが、gotoの処理内容は関数の最後の方いかないとわからないという見通しの悪さを含んでいますので、正しかろうともgotoは使わないのが吉です。メインストリームに乗りたいのであればckよりacの方が他のパッチとの相性は良いと思われます。
割といい加減にこさえたac+ckパッチが思いの他健闘したのが嬉しかった。以上、感想を添えたところでおしまいです、
【関連する記事】
