アカウント名:
パスワード:
負荷を物理CPU間で適切に割り振る仕組みは当然あるんだろうな、と勝手に想像してましたが、そうでもなかったんでしょうか。
以前の仕事で、複数ソケットに複数コアおよび/または複数スレッドがあり得る場合に、どれとどれが同じソケット、同じコアなのかをなるべく普遍的に区別できないものかと調べたことがありましたが、自分にはわかりませんでした……orz
Linuxならstruct cpuinfo_x86のphys_proc_idを比較することで同じコアかどうか(同じAPICに接続されているか)を判断できます。
struct cpuinfo_x86は、struct cpuinfo_x86 *c = &cpu_data(CPU番号)とやれば取り出せます。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
HyperThreadingはオフ (スコア:1, 興味深い)
Re:HyperThreadingはオフ (スコア:1, 興味深い)
確かにHTはスレッドあたりの性能を悪くしますが、マルチスレッド全体での性能は間違いなく向上します。
サーバの場合、単一のスレッドで動いているとは考えられないため性能は上がると思うのですが。
巨大なファイルのコピーを複数同時に行うと悲惨なことになるように、
HTのおかげで並列度が上がってI/Oがボトルネックになってるとか?
Re:HyperThreadingはオフ (スコア:5, 参考になる)
http://technet.microsoft.com/ja-jp/magazine/cc137784.aspx [microsoft.com]
この場合は、DBMS 自身がスレッディングとキューイングを既に効率化させているため、HT によるスレッディングによって却って DBMS の動作が非効率になるという、ある種不幸な事象が原因でした。
Re:HyperThreadingはオフ (スコア:3, 参考になる)
ません。むしろ並列プログラミング特有のボトルネックが出てしまって、トータルではかえって
性能が低下したというだけに見えます。シングルCPUに(過度に)最適化したアプリをそのまま
マルチCPUに持っていっても性能が出ないのはある意味予想されていたことなのですよ。マルチ
CPUはCPUの内部的な演算は高速化してくれるけど、それ以外は今までと変わりないですから。
Re:HyperThreadingはオフ (スコア:5, 参考になる)
ソフト単体だと、プログラマ自体がマルチスレッドで意識して書かないと100%使い切るような性能はなかなか出ないですね(汗
HTは使ってみるとわかるんですが、論理上(少し性能の劣る)マルチコアに見えるというだけであり、マルチスレッドのソフトは基本的に素直に性能が上がりますね。
(HTとは関係無しに)マルチスレッドで出た問題を挙げると
やたら演算ばかりするスレッドを書くと、スレッドが回りすぎて、他のスレッドと比較して負荷が上がる>Windowsのスケジューリングで負荷が高い物を優先してスケジューリングする(Boost)>結果特定スレッドのみCPU時間を取ってしまい、他のスレッドに時間が回らず、想定よりもパフォーマンスが落ちる(Boost問題)
(余談ですがSEGAのPSOBBでアイドルループの書き方がまずくて、こうなってた事例があります)
自分で書いたソフトには問題が無いが、ASPIレイヤで「同一ソフトから同一IDのデバイスの操作は一つだけ」という条件が入っている為に速度が出ない(環境的な問題)
マルチスレッドをあまり意識せずにパフォーマンスを稼ぎたい場合は
・OpenMPを使う
・シングルスレッドで書いて複数走らせる
が良いかと思います
(特に後者は解析等で分散して解析を行うのに便利だったりしますし、意外に侮れないwww)
Re:HyperThreadingはオフ (スコア:4, 参考になる)
Re:HyperThreadingはオフ (スコア:1)
Re:HyperThreadingはオフ (スコア:1)
以前の仕事で、複数ソケットに複数コアおよび/または複数スレッドがあり得る場合に、どれとどれが同じソケット、同じコアなのかをなるべく普遍的に区別できないものかと調べたことがありましたが、自分にはわかりませんでした……orz
Re: (スコア:0)
Re:HyperThreadingはオフ (スコア:3, 参考になる)
Linuxならstruct cpuinfo_x86のphys_proc_idを比較することで同じコアかどうか(同じAPICに接続されているか)を判断できます。
struct cpuinfo_x86は、struct cpuinfo_x86 *c = &cpu_data(CPU番号)とやれば取り出せます。
Re:HyperThreadingはオフ (スコア:3, 参考になる)
Re:HyperThreadingはオフ (スコア:1)
「劣化」というよりは「そもそもその程度しか性能が出ない」と見た方が良いかと思います。
色々試しましたが、正直1.5倍出れば良い方ですね。
Re:HyperThreadingはオフ (スコア:1)
>「劣化」というよりは「そもそもその程度しか性能が出ない」と見た方が良いかと思います。
いえ、HTの方がむしろ遅くなるパターンもあったので、劣化と書きました。 2CPUのマシンで2スレッド並列処理させると、シングルスレッドで計算させたときのほぼ2倍速になる単純な自作ベンチマークだったんですが、HT対応CPUで2スレッドで並列処理させると1スレッドで計算させたときの0.9倍速(各スレッドの計算速度は約0.45倍)になっちゃったとかそういう。
並列計算を見越した書き方、みたいなのは噂には聞いたことがあったんですが、HT用には更に別に考慮すべき要素があるのか、と、げんなりしました。
Re: (スコア:0)
お互いのキャッシュを削りあってキャッシュミスが頻発する。
みたいなことを聞いた気がする。
Re: (スコア:0)
Re:HyperThreadingはオフ (スコア:5, 参考になる)
ここで問題となるのはHTの複数論理スレッドが, ある物理コアの1次キャッシュを取り合ってしまうこと.
HTでは1物理コアに複数の論理スレッドを割り当てる.
とうぜん1論理スレッドあたりのキャッシュ容量は減る.
各スレッドのキャッシュミスヒット率はキャッシュの容量に線形ではないので,
1論理コアに2スレッド走らすと, 各々のキャッシュミスヒットがHT off時の倍以上に
増加する可能性がある.
その場合HT offであるまとまった時間一方のスレッドを走らせ, その後他方のスレッドを走らす
よりも遅くなる.
Re:HyperThreadingはオフ (スコア:2, 参考になる)
>1論理コアに2スレッド走らすと, 各々のキャッシュミスヒットがHT off時の倍以上に
>増加する可能性がある.
間違いじゃないけど、
「キャッシュ容量が半分になっても、通常はキャッシュミスは倍増しない」
ってことに触れておかないとフェアじゃないよね。
1スレッドのワーキングセットがキャッシュ容量ギリギリで、
2スレッド動かすとお互いに相手のワーキングセットを押し出すような
アプリだと上のようなことも起こるでしょう。
他の方が書いていたように、1コア向けに最適化されたDBMSなんかは
そんな感じですよね。
Re: (スコア:0, フレームのもと)
でググレ
Re: (スコア:0, フレームのもと)
Re: (スコア:0, フレームのもと)
Wiki と Wikipedia は違うと。