Feb 26, 2006
続Athlon 64x2ベンチマーク(SMPでの4BSD/ULE比較) [computer]
さらに修正(24:00頃)- load ave ->CPU使用率 CPU使用率 = (user+system)/realtime (%)なのでいらなかったかも
- これはあくまでkernelの複数プロセスによる並列処理での評価 マルチスレッドのアプリケーションの場合はまた別の結果が出るかもしれない。 ただ1プロセスの場合のsystem時間と複数プロセスの場合のsystem時間から考えるとこのあたりの効率を改善しても全体のスループットの改善効果は限定的であることが予想できる。
- 何考えてたのかわからんtypo修正。
- ぼそ。レポートというのは結構めんどい。
- 生データを一応公開しておくか。 生データだけなので使いにくいとは思うが。 compile_bench.tar.gz
なんらかの形で実証はしたいけど
前回のテストのうちSMPカーネルかつNO_MODULE=YESの場合のテストのみ
再度プロセス数の条件を増やして4BSDとULEスケジューラの比較を行った。
対象OS:FreeBSD 6.1-PRERELEASE (2/14頃のもの)
テストは3回行い平均値を示した。
smp-4bsd:SMPオン,4BSDスケジューラ
smp-ule: SMPオン,ULEスケジューラ
以下に測定結果を示す。
# smp-4bsd プロセス数 user(s) system(s) realtime(s) CPU使用率 1 169.034 9.724 172.87 103.3% 2 170.063 10.199 94.87 189.9% 3 171.281 11.165 95.50 191.0% 4 172.169 11.688 96.03 191.3% 6 172.653 11.435 96.30 191.0% 8 172.482 12.046 96.20 191.6% 10 172.743 12.494 96.07 192.7% 16 172.930 12.696 96.10 193.0% #smp-ule プロセス数 user(s) system(s) realtime(s) CPU使用率 1 169.265 8.833 176.27 101.0% 2 169.916 10.471 94.87 190.0% 3 170.499 11.274 95.27 190.6% 4 170.900 11.705 95.33 191.4% 6 171.322 12.064 95.53 191.8% 8 171.735 11.792 96.00 191.1% 10 171.648 12.181 95.50 192.4% 16 171.802 12.207 95.77 192.0%
前回のテストからはあまり大きな違いはない。 別個のテストを行ってほぼ同じ結果が出たため結果にはある程度再現性があることがわかる。今回のテストに関する限り、
- 1プロセスの場合は2%程度4BSDの方が性能が良い
- 複数のプロセスを同時に動かした場合平均的にはわずかに(1%未満)ULEの方が性能が良い
- user時間、system時間いずれも4BSDの方が大きい値が出る傾向がある。この点からも極わずかではあるが今回の条件下(Athlon64x2 SMP)ではULEの方が効率がよいことがうかがえる。
グラフも書いてみたがあまり面白い結果は見られなかったので割愛する。 結論を言えば1%未満の性能のためにULEを使うのはチャレンジャーだと思う。 特に重要性が高くはない所でバグ出しに協力するつもりなら悪くはないが。
Feb 24, 2006
ネコミミ(?) [その他]
22日の深夜に女子回転(アルペン・スラローム)を見ていた
(記憶で書いているから間違っているかもしれない)A:アナウンサー
K:解説の川端絵美さん
A: これは... K: 彼女のトレードマークですね A: しかし、いいんですか...空気抵抗とか K: 多少はあるでしょうけど...
TV見てマジ吹いた(画像なしなのが残念)。
Athlon 64x2ベンチマーク(SMPのテスト) [computer]
一部加筆修正。カテゴリが間違っていたので入れ直し。
対象OS FreeBSD 6.1-PRERELEASE (2/14頃のもの)
GENERICカーネルのコンパイル
スケジューラは4BSDのものとULEのもの両方をテスト
- 事前の検討など
- 測定結果
最初は普通にFreeBSDのカーネルコンパイルで make -j4 等で 並列度を上げてコンパイルして比較を試みた。xload等で表示される負荷を見ていて気がついたが、コンパイルの前半ではmakeであたえた最大並列度一杯まで負荷が上がるが次第にダラ下がりになることがわかった。通常の処理例としてはそれでも評価にはなるとは思うが、SMPのテストとしてはあまりよろしくない。
xloadの表示からモジュールのコンパイルでは並列度が上がらないことが考えられた。このためNO_MODULES=YESを指定して負荷の動きを見てみた。この結果テスト全体に渡り並列度があまり落ちなくなり、CPUの使用率も190%程度となった。SMPのテストとしてはこちらの方が適しているだろう。
もう一つ。テストはスクリプトを用いて連続的に自動的に行うようにしたが、kernelのコンパイルを繰り返しで、最初の2回程度はページフォルトが起きることに気がついた(csh内蔵のtimeを使っているとデフォルトの設定では表示される)。
このためまず2回 kernelのコンパイルを行い、その後各条件で3回づつコンパイルを行い平均値を求めることにした。
up-4bsd: SMPオフ,4BSDスケジューラ
up-ule: SMPオフ,ULEスケジューラ
smp-4bsd:SMPオン,4BSDスケジューラ
smp-ule: SMPオン,ULEスケジューラ
以下に測定結果を示す。
(1)GENERIC kernelのコンパイル # up-4bsd proc user system real time CPU 1 534.666 33.328 9:32.26 99.2% 2 537.250 35.328 9:36.60 99.3% 4 544.882 34.684 9:43.04 99.2% 8 544.762 35.225 9:44.56 99.2% # up-ule proc user system real time CPU 1 536.687 32.908 9:34.41 99.1% 2 541.345 34.734 9:41.25 99.1% 4 545.630 35.352 9:45.68 99.1% 8 545.529 35.795 9:46.64 99.1% # smp-4bsd proc user system real time CPU 1 533.321 33.706 9:10.86 102.9% 2 535.664 36.666 6:25.19 148.5% 4 539.983 38.300 6:09.26 156.6% 8 541.189 39.319 6:15.77 154.4% #smp-ule proc user system real time CPU 1 533.717 32.031 9:22.87 100.5% 2 536.659 35.313 6:28.49 147.0% 4 537.696 38.382 6:15.93 153.2% 8 538.695 38.847 6:19.12 152.3% (2)GENERIC kernelのコンパイルでNO_MODULE=YESを使いmoduleは作らない # up-4bsd proc user system real time CPU 1 169.805 9.821 3:01.19 99.1% 2 170.525 10.401 3:02.25 99.2% 4 173.328 10.436 3:05.11 99.2% 8 173.660 10.640 3:05.59 99.3% # up-ule proc user system real time CPU 1 169.766 9.731 3:00.97 99.1% 2 172.537 10.072 3:03.81 99.3% 4 172.765 10.605 3:04.73 99.2% 8 173.745 10.566 3:05.49 99.3% # smp-4bsd proc user system real time CPU 1 169.081 9.399 2:52.57 103.4% 2 170.419 9.947 1:35.29 189.2% 4 172.228 10.650 1:36.43 189.6% 8 172.712 11.928 1:36.45 191.2% #smp-ule proc user system real time load 1 169.372 8.938 2:56.25 101.1% 2 170.086 10.707 1:35.23 189.8% 4 171.078 11.557 1:35.13 191.9% 8 172.004 11.669 1:35.51 192.9%
この結果からは以下の事がわかる
- 並列度を変えてもuser timeはあまり変わらない
- ULEと4BSDの性能の差はあまりない
8プロセス動かした場合で単一プロセスに比較して1.5%〜2%程度の変動。この数値が大きくなっている場合、メモリやバスの競合でCPUの性能が見掛け上落ちている事を示す。 スループットの点から見ればSMPはうまく動いていると言える。
HyperThreadingの場合は仮想CPUそれぞれに均等にjobを与えると数10%程度"CPU"の性能が落ちるように見える。これはそれぞれの仮想CPUは実際には単一のCPUのパイプラインにできる空きを有効活用するためのものであるからである
深く検討するなら少々データ不足気味だがおおざっぱに言えばこのテストでは性能面であまり大きな差は出ていない。1%程度の差は計測誤差の可能性もある。
(一応)続く
Feb 20, 2006
Necronomicon's [本,雑誌など]
- ドナルド・タイスン「ネクロノミコン アルハザードの放浪」(学研 2500円)ISBN4-05-402948-5
「クトゥルフ」にとっては説明不要の『偽書』ネクロノミコン。 著者がドナルド・タイスン。翻訳者がラヴクラフトの作品の多くの翻訳で知られる大瀧啓裕。これは完璧。
ネクロノミコン=アル・アジフはクトゥルフ物の作品で言及される架空の書。 今までもいくつか「ネクロノミコン」を作る試みは行われてきたけどこれは体裁もネクロノミコンの設定を忠実になぞっている。
設定に忠実(にしようとしている)なので当然読み易くは無いのが欠点といえば欠点。 マニアの間ではありがちな「設定で遊ぶ」ことを突き詰めたものなんですが。
これをベースにした「ネクロノミコン解説」が欲しいところですな。
Athlon64x2とA8S-X の続報 [computer]
- A8S-Xの続報
- AMD Athlon64x2 3800+(2GHz) (37420円)
巷では色々言われているA8S-Xだが私のところでは大きな問題は出ていない。 (気がついていない?)掲示板等の情報を見ても不具合を訴える人もいるが「問題は起きていない」と言う人もいるようで、条件次第で「外れる」場合があることが伺える。 BIOS 0801で安定するようになったと言う人もいるようだが、それでも不具合の起きる人は起きるようで。
と思ったらGSA-4040でCDRに書き込みすると読めないCDRができてしまうようになっていた。これはドライブがへたっておかしくなったのかA8S-Xの方の問題なのかわからない(どっちも色々言われているし...)。何度か試行錯誤したところどうやらCool'n'Quietを効かせていると問題になるらしい事が判明。
さて、試しにFreeBSD-6.0Rを入れてみた。問題なく動作する。SATAのディスクからの起動も問題ない。
というわけで(?)せっかくだからAthlon64x2を試してみることにした。
...まあ起動程度だったらWindowsおよびその他のOSは動くようですね。
パフォーマンスのテストでもやってみるか... というわけでSMPのテストをやってみた。内容そのものは簡単なのだけどテスト完了まで1週間(ははは..)。というところで力尽きたので「続く」(ぉい)。
Feb 06, 2006
スキー [その他]
長めのスキー旅行に行ってきた。今年はかなり奮発してカナダ(Whistler Blackcomb) まで1週間ほど。WhistlerとBlackcombは隣の山でふもとからはゴンドラが2つのスキー場に向けて設置されている。リフト券は共通なので下まで降りれば行き来はできる。
行きの飛行機が2時間程遅れた関係かバンクーバーには30分程しかいなかったのでほとんどスキー場近くのステイ。
日本には無いスケールの大きさ...等々はあまり語る言葉が無いのでその他気がついたことなど。
- 日本人の観光客は多い。スキー場でもよく日本語は耳にする。
- スキー場のレストラン(CA $15ぐらいで食事できる)では何故か80年代の曲がよくかかっていた
- TOTO「ロザーナ」
- ピーター・ゲイブリエル「big time」
- レストランで出てくる量は日本人標準の50%〜100%増し
- トリノの次の冬季オリンピック会場なのでその関係の施設、シンボルマークも見かけた。女子滑降/スーパーGコース(予定)は滑ることができる。
- 明け方にスキー場まで出ると積雪状態によっては表層雪崩等の危険のある場所に発破をかけている音が聞ける
- 「本当にこれコース?」(日本標準)と思えるようなコースも少なからず。上級(◆)の上に超上級(◆◆)コースがあって、全部が全部では無いが...
