アカウント名:
パスワード:
このグラフを見た限りでは,すくなくとも性能が劇的に改善したように見えません.
そうですね、グラフには改善前のものが記載されていませんから改善したのか悪化したのかすら判りません。
次に,グラフの左側,並列度が実CPU数よりも低い場合は Linuxのほうが1割以上速いという結果が出ています.
むしろ、実CPU数よりも多い並列度になるとLinuxのスケジューラはうまく処理を捌けない点に注目すべきだと思います。うまく処理を割り当てていれば、スレッド個別のスループットは落ちたとしても合計のスループットはそれほど低下しないはずです。
FreeBSDにおいて並列4~7度の部分が遅くなっているのは、AMDのCPUを使用していることからリモートメモリへのアクセスが発生していることによるボトルネックに思えます(4で若干低下しているのはOSのオーバヘッドだと考えられます。)。先も書きましたがFreeBSDのスケジューラ/メモリアロケータはNUMAを意識していないように思えます。
SMPng の成果を計測するのに、厳密にはSMPといえないAMDのCPUを使用したのは何故なんでしょうか。
厳密にはSMPではないとはどの部分を指しているのでしょうか。単にSMPngが対象としている問題領域の範囲内ではSMPとみなせるだけの条件を満たしていたのかもしれません。
それはともかく、実際にはAMDがマシンを提供してくれたから [freebsd.org]でしょう。
NUMAとSMPは対立する概念とは思えません。
NUMAだからSMPではないとかそういった表現はできなくて、マルチプロセサシステムにおけるメモリの接続方法としてUMAとNUMAといった区分があり、SMPの対義語はASMPだと思うのです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ? -- Debian初級
本当に劇的に改善したの? (スコア:3, 興味深い)
タレコミにリンクが貼ってあるグラフ [freebsd.org]ですが,
このグラフを見た限りでは,すくなくとも性能が劇的に改善したように見えません.場合によっては,Linuxの方が性能が良いようにさえ見えます.
まず,縦軸のピークは linux です.
(意地悪な言い方をすれば) アプリケーション側でチューニングを行えば Linux のほうが性能がでることになります
次に,グラフの左側,並列度が実CPU数よりも低い場合は Linuxのほうが1割以上速いという結果が出ています.
タレコミ中では”僅かに上回る”と言っていますが,CPUのマルチコア化が進んでいる状況を考えると,並列度が低い場合に1割以上性能が劣る事実は,FreeBSDがLinuxに劣る欠点として認識すべきです.
グラフの右側も含めて,グラフ全体を見ても,
- 高負荷時のスループット BSD が有利
- 低負荷時のスループット Linux が有利
という以前から言われている関係が再度示されただけで,結局 SMPng を持ってしても問題は改善できなかったように思えます.一体 SMPng は何を劇的に改善したのでしょうか?
Re:本当に劇的に改善したの? (スコア:4, 興味深い)
そうですね、グラフには改善前のものが記載されていませんから改善したのか悪化したのかすら判りません。
むしろ、実CPU数よりも多い並列度になるとLinuxのスケジューラはうまく処理を捌けない点に注目すべきだと思います。うまく処理を割り当てていれば、スレッド個別のスループットは落ちたとしても合計のスループットはそれほど低下しないはずです。
FreeBSDにおいて並列4~7度の部分が遅くなっているのは、AMDのCPUを使用していることからリモートメモリへのアクセスが発生していることによるボトルネックに思えます(4で若干低下しているのはOSのオーバヘッドだと考えられます。)。先も書きましたがFreeBSDのスケジューラ/メモリアロケータはNUMAを意識していないように思えます。
Re:本当に劇的に改善したの? (スコア:0)
ちょっと不思議です。
Re:本当に劇的に改善したの? (スコア:1)
厳密にはSMPではないとはどの部分を指しているのでしょうか。単にSMPngが対象としている問題領域の範囲内ではSMPとみなせるだけの条件を満たしていたのかもしれません。
それはともかく、実際にはAMDがマシンを提供してくれたから [freebsd.org]でしょう。
Re:本当に劇的に改善したの? (スコア:0)
Re:本当に劇的に改善したの? (スコア:0)
NUMA.≠SMP? (スコア:1)
NUMAとSMPは対立する概念とは思えません。
NUMAだからSMPではないとかそういった表現はできなくて、マルチプロセサシステムにおけるメモリの接続方法としてUMAとNUMAといった区分があり、SMPの対義語はASMPだと思うのです。
Re:本当に劇的に改善したの? (スコア:3, 参考になる)
MySQLのベンチにおいて、これまでは全てLinuxを下回る結果でした。
(ソース失念)
改良したULEスケジューラ、libthrスレッドライブラリ、
CURRENTにパッチをあてたもの、という非標準な環境ではあるにしろ
このような結果がでたことは素直に喜ばしいです。
# 6.2-RELEASE の結果も載せるべきだと思う。
Re:本当に劇的に改善したの? (スコア:1, 興味深い)
8CPU上のLinuxでスレッドを増やして落ち込んでいる所よりも下だったんですか?
このグラフを見るとLinuxのこのバージョン(だけと信じたい)のスケジューラには痛いバグがあるというのが無難な結論と思います。
Re:本当に劇的に改善したの? (スコア:1, 参考になる)
2.6.18, 2.6.19, 2.6.20で観測されているよ。
信じたい→無難な結論、って恥ずかしくね?
Re:本当に劇的に改善したの? (スコア:3, 興味深い)
DBサーバに適応すると考えた場合、
このグラフを見る限り普通はFreeBSD改の方がいいという結論になりませんかね?
FreeBSD改のように低負荷の場合に多少性能が悪くても個々のレスポンスが落ちるだけですけど、
Linuxのように高負荷になった場合に途端に性能ががくんと落ちられてしまうと
何かの拍子にネガティブなスパイラルに突入して待ち行列がすごい勢いで伸びていって
「サーバ落ちた」状態になるのが怖そうなんですが。
確かに全範囲でLinuxを上回ればベストでしょうけど、
サーバ関係なら同時リクエストがコア数を上回るなんてザラでしょうから、
そこを優先して改善するというのはアリじゃないでしょうかね。
どうせならスレッド数を対数にしちゃえば良かったのに(笑)と思うAC
(そういえば、昨日のまいにちいっしょ [dokodemoissyo.com]は「グラフで比較すると」ネタだったな~)
Re:本当に劇的に改善したの? (スコア:1)
同感です。
パクリでもいいのでLinuxにもこの研究(実装)成果を取り込みたい物ですね。
(あ、私がBSD使いになればいいのか。)
Re:本当に劇的に改善したの? (スコア:1, すばらしい洞察)
CPU のマルチコア化が進むと、今後は並列処理を積極的におこなうアプリケーションが増えるであろうことが
予想されるので、並列度が低い場合にしか性能を発揮できない事実はうんぬんかんぬん、
ともいえますね。
Re:グラフ (スコア:0)
至極最もなこといってると思う。
ここまでとんちんかんな読み取り方できるのだろうか?
すぐに書き込まないで二三日検討してから書き込んでも遅くないのに。。。
Re:グラフ (スコア:0)