12/03/27 09:36:39.40
>>917
動画エンコードプロセスに対して、Battle Encoder Shirase みたいな制御をするとか？
920:デフォルトの名無しさん
12/03/27 10:12:01.02
>優先度の高いプロセスが、優先度の低いプロセスに阻害される
HTに係るCPUの内部状態を、そのCPU上で動いているプロセスから、
ソフト的に制御する方法なんて無いよ。
ICEでも使って外部からコントロールするなら兎も角。
・・・っていうか、そのアプローチは不可能に近いって何となくわからない？
>Cのパターンと同じになっています。
ソフト(ＯＳ)から見たら、HTなんて関係ないし、二つのCPUは等価なのだから、
ソフトにスケジューリングを任せてたら、
二つのスレッドの実行時間がほぼ同じになるのは当然。
>>917
>core i7にしたら落ちるようになってしまったのです。
それホントにCPU依存の話か？
Core2とi7はソケット形状が違うので、CPU以外にも色々と構成が違うはずだが。
VIAとかの互換CPUならともかく、インテル純正CPUでその手の話って聞かないからさ。
もしかしてCore i7のCPU内蔵GPUを殺すと意図したとおりに動いたりとかしないか？
だとしたらGPUとCPUでメモリバス食いあってるか、GPUのハードウェアエンコーダが
有効になってて、GPU食いあってるだけだと思うぞ。
921:910
12/03/27 10:53:19.74
>919 このソフトを試してみたいと思います。
これでうまくいくようなら、メインプロセスと同じ物理コアの別論理コアで
動くスレッドに対して同じような処理をするプログラムを作ってみようと思います。
>920 ハード的に制御してくれるAPIがないか知りたかったのです。
エンコーダはマルチスレッドですが、GPUは使っていません。
ゲームとエンコーダをE/Fのパターンのように違う物理コアのAffinityMaskにしてしまえば
ゲームのフレームレートが落ちないことは確認しました。
922:営利利用に関するLR審議中＠詳細は自治スレへ
12/03/29 23:58:28.02
>>911
その計算時間どういう操作してどう計ったの？
838万ケタを同時に計算開始しただけ？
論理CPUの割り当てが別なら優先度なんて関係ないに決まってるんだが、意味分かってるか？
ゲームメインを物理コアにだけマスク指定したら問題なさそうな気がするが、それじゃうまくいかないか？
923:910
12/04/02 12:23:22.30
計算時間はsuperπが計測しています。
同時に計算開始しました。
2つの開始ボタンを押す間の数百ミリ秒は、今回は無視です。
>論理CPUの割り当てが～
だから、それを優先付けるAPIはないかという質問です。
HyperThreadingを使用するとパフォーマンスが落ちると問題視され
Pentium4からずいぶん時間がたったので、そろそろ出ていないかと思いました。
ないので代替案を提示してくださってるのだと思いますが。
>ゲームメインを物理～
それだと、論理コアが1つ遊んでしまいます。
924:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/02 17:53:01.73
遊べば他方を圧迫しない、働けば圧迫する
HTのために２つあるのは状態に関するレジスタ類だけだもの
925:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/02 20:40:06.53
自分で設定する気が無いんならOSに任せろ
926:915
12/04/02 20:57:35.84
>>923
SetProcessAffinityMask
URLﾘﾝｸ(msdn.microsoft.com)
ムダだろうがこれ使ってみれば？
927:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/02 21:05:59.53
既出か。メンゴメンゴ。
928:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/02 21:25:52.93
>>ゲームメインを物理～
>それだと、論理コアが1つ遊んでしまいます。
何を言ってるのか分からなくなってきた。
論理コアをあそばせるのがもったいないほどCPUを使い切るマルチスレッド化が出来てるのか？
もうちょっと詳しくどういう動作をさせてるのか、どういうスレッド構成になってるのか書いてくれ。
まさかCPUパワーが余ってるのに論理コアが遊んでるのは許せないとかとち狂ったこと言ってないよな、念のために聞くが。
929:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/02 21:29:09.18
>>928
どんな理由でもかまわないだろ・・・
930:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/02 21:44:51.68
結局のところ>>924でどうにもならないんじゃないの？
931:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/02 23:47:25.54
元の質問に誰も答えないのは、万が一あったりするとアレだからだろうねぇ。
でも、さすがに無いと思うよ、そんなAPIは。
別な方法で妥協するしかないんじゃないかな。
932:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/03 07:42:04.28
あるか否かは、CPUのニーモニックコードのリストを見ればわかるよ。
そこに命令が用意されていないなら、CPUの内部状態をコントロールしようがない。
非公開命令が用意されている可能性は残るけどな。
933:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/03 11:36:54.07
結局一緒じゃねーか。
あとそういうニーモニックがあるかどうかじゃ確実には分からんよ。
無いと思うけどね仕組み上から考えても。
934:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/03 14:07:48.98
なんでハードウェアの話になってしまったのかよくわかんないけど、
OS のスケジューリングの話じゃないの？
こんなのとか。
URLﾘﾝｸ(kerneltrap.org)
Windows も HT を意識したスケジューリングをしてくれればいいのにね。
935:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/03 15:03:29.48
そりゃOSレベルじゃ制御してない部分の話だもん。
どころかハードレベルでも制御不能だろってのが優勢。
936:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/04 07:28:13.10
>>934
してるよ
URLﾘﾝｸ(www.dosv.jp)
APIでプログラマに公開されてるかは知らんが
937:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/04 10:42:53.69
物理マルチコアにHTなんていらないんじゃないかな
938:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/04 10:44:43.96
HTをONにすると2000ではひっかかりまくるが、XPではスムーズ。
どうみても対応している。
939:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/04 11:02:06.05
ただlinuxみたいに同一物理コアの別論理コアに割り当てられたスレッドの優先順位を考慮して
タイムスライスの比率を変えるようなことはしてないね。
940:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/04 11:08:09.89
別コアなのにタイムスライスって、スレッドを一時停止してるっことなんだが、
Linuxではそんなことしてるのか。逆にコスト高くつくんじゃないのか。
941:910
12/04/04 11:42:02.39
HyperThreadingは空いている演算器を有効に使うためのものなのに
メインで使っている演算器も奪ってしまうのはおかしいと考えており
別のOSでは実際にそれを回避するようにもなっているということで
とりあえず安心しました。
942:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/04 13:07:41.32
なんというか・・・
同時に動かすから、空いてるのを有効に使えるのよ
そして同時に動かせば他方を圧迫する
圧迫を回避する＝片方を止める＝空いてるのを使えてない なのよ
943:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/04 14:29:03.38
>>941
なってねーよ馬鹿かお前は。
944:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/04 14:30:35.88
あいつは人の話を聞かないからなあ。
何でも都合よく解釈しやがる。
945:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/05 13:36:26.86
そんな理論武装で大丈夫か?
946:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/06 15:00:20.07
pthread_rwlockの使い方をおしえて
947:営利利用に関するLR審議中＠詳細は自治スレへ
12/04/06 16:30:03.14
>>946
その前に聞くが、pthread_mutex_lockの使い方くらいは知っているのか?
pthread_rwlockはそれより厄介だぞ。
URLﾘﾝｸ(www.tsoftware.jp)の図4が理解できないならやめとけ。
つーか、本当にrwlockが必要なのか?
948:デフォルトの名無しさん
12/05/11 15:36:21.96
2CoreのCPUなら問題ないのに、
HTをONにするとフリーズしたり不安定になるプログラムって何が原因なんだろう？
949:デフォルトの名無しさん
12/05/11 15:41:22.67
複数のスレッドを使うプログラムだろうから、スレッド間の同期がいい加減なのだろう。
950:デフォルトの名無しさん
12/05/12 01:16:48.20
同時に動くとまずいコードがあるんだろう
951:デフォルトの名無しさん
12/05/12 12:53:15.98
2Coreなら大丈夫というのがおかしい。
952:デフォルトの名無しさん
12/05/12 13:07:54.49
別におかしくないよ。
953:デフォルトの名無しさん
12/05/12 13:38:09.65
いやおかしい。
おかしくないなら、2CoreでOKで、HTだとダメなパターンプリーズ。
954:デフォルトの名無しさん
12/05/12 13:45:24.65
ドライバレベルなら昔あったな。
省電力でCPUクロックダウン／休止させる時にHTなので全部止まっちゃいました(テヘっ)ってのが。
955:デフォルトの名無しさん
12/05/12 13:47:28.79
試してみて動いた=OKだと思ってるなら根本的に勘違いしてる
956:デフォルトの名無しさん
12/05/12 13:51:32.68
>>953
そんなこと考えてる暇あったら、HT時に起こってる問題を正確に掴むべき。
ちょっとしたタイミングの違いで動いたり、動かなかったりなんてのはいくらでもある。
957:デフォルトの名無しさん
12/05/12 13:53:22.20
おまえの勘違い半端ねぇ
958:デフォルトの名無しさん
12/05/12 13:54:19.83
たまたまの話ならどうでもいい。
頭の悪い突っ込みは必要ないから。
959:デフォルトの名無しさん
12/05/12 13:55:56.52
突っ込みはしたものの、
HTだけダメなパターンはなに一つも思いつきませんでした。
ごめんなさい。
960:デフォルトの名無しさん
12/05/12 14:01:26.21
お前に思いつくかどうかなんてどうでも良いんだよ。
961:デフォルトの名無しさん
12/05/12 14:03:59.23
>ちょっとしたタイミングの違いで動いたり、動かなかったりなんてのはいくらでもある。
この原因は二つ。
・同期処理をしていない。
・同期処理が必要な部分を洗い出せていない。
HTがダメで2CoreがOKな理由になってないなぁ。
考える暇がないのか考える頭がないのか。
962:デフォルトの名無しさん
12/05/12 14:06:39.92
相談スレで相談したら自分でやれって言う奴を相手にするな。
ただ煽りたいだけの馬鹿なんだから。
963:デフォルトの名無しさん
12/05/12 14:06:45.64
現に原因不明の不具合を目の前にして、そんな事考えるだけ無駄だと分からないやつは開発向いてない。
964:デフォルトの名無しさん
12/05/12 15:03:57.50
問題の起きるメカニズムを解明するのは興味深いが、
解明したところで自己満足以外に得られるものがないからな
結局きっちり同期するしかないんだし
965:デフォルトの名無しさん
12/05/12 15:05:54.53
二つの処理が30ナノ秒以内に終わらないとタイムアウト
するウンコな処理があって2CPUだと偶然動いたとか。
ＫＵＳＯなコードに論理性を求めるほうが時間の無駄。
単にHT環境で再現するという明らかな不具合を直せばよろしい。
966:デフォルトの名無しさん
12/05/12 18:26:42.65
Pen4の頃のHTを使っていた時は明らかに普通のデュアルCPUと
タイミングが違ってバグの出方も全然違ったよ
>>965の言っているように運よく再現できる環境があるなら
そこで治せばいいんじゃない
967:デフォルトの名無しさん
12/05/12 20:16:48.32
>>953
1スレッドがループ内でレジスタを使い切るパターンだろ
フリーズまではいかんが、挙動が悪くなる
968:デフォルトの名無しさん
12/05/12 20:37:58.42
自分で2CoreではセーフなのにHTをオンにしたら動かない！って言ってるのに、
「そんなパターンは無い！」とか分裂症ですか？って感じ。
そんなパターンがあるからその現象が発生してるのは明らかなのに。
現実逃避もいい加減にしろよ。
969:デフォルトの名無しさん
12/05/12 21:02:29.35
スペック厨で、自分の最強ハードに問題が有るって事が気に入らないんだろう
目の前で起きてる問題をどう解決するかが問題なんだがオタクは空気がよめないね
970:デフォルトの名無しさん
12/05/12 21:07:20.42
HTをオフにしたら動きました。
971:デフォルトの名無しさん
12/05/12 21:19:10.76
>>953
void threadA(){
while(1);
}
void threadB(){
while(1);
}
972:デフォルトの名無しさん
12/05/13 02:00:44.76
それのどこがHTがダメなんだ？
973:デフォルトの名無しさん
12/05/14 09:08:39.75
>>971
シングルコアならOSがタイムシェアリングして均等に実行してくれる。
マルチコアならOSがそれぞれのコアに割り当てて均等に実行してくれる。
HTだとOSはそれぞれの仮想コアに割り当てて均等に実行しているつもりでも、
片方のスレッドが動いている間、もう片方のスレッドは満足に実行されない。
上のようなBusyLoop場合とくに顕著で、何もしない処理がCPUを占有する事になる。
これを防ぐために何もしないから他の仮想コアに処理を渡してよい事を示す
命令が追加されている。
974:デフォルトの名無しさん
12/05/14 16:30:14.82
htでもだいたい均等に割り振られるが。
975:デフォルトの名無しさん
12/05/14 17:15:11.15
HT非対応なんだろ
976:デフォルトの名無しさん
12/05/18 21:50:52.80
すいません。教えてください。
signalマスクをかけたスレッドの関数内で、popenをコールしてるんですが、ctrl+Cするとポインタ(NULLでないpopenの戻り値)からのfgetsが成功する時としない時があるんですが留意する事って何かありますか？
ちゃんとpthread_joinは出来ているのでマスクには問題無いと思うのですが。
宜しくお願いします。