11/12/13 17:01:56.05
>>822
どのサイズが問題なく読み書きできるかは環境(CPUやVM等)しだい
(intはOKだがdoubleはだめといった感じ)
825:デフォルトの名無しさん
11/12/13 17:32:59.62
>>822
32ビットx86なら4バイトアライメントされたアドレスの4バイトをmovでアトミックに書き込める、
これが8バイトだとmov2回になるので（もっと違う値なら）2値のどちらでもない状態が存在する、とかいうのはある
でも付いて行けなくなるから考えないほうがいいぞ
826:デフォルトの名無しさん
11/12/14 04:35:01.63
>>823-825
ありがとうございます。
とりあえず、メモリを読み書きする電気的な信号などがバッティングして
データが飛んだりハードが壊れたりということはないんですね。
827:デフォルトの名無しさん
11/12/14 06:38:46.37
メモリ競合程度でハード自体が壊れるなら欠陥品と言わざるを得ない
828:デフォルトの名無しさん
11/12/14 08:09:32.50
>>826
その環境が組み込みでメモリマップドI/Oの先にいい加減な回路が繋がっていたりしたら、壊れるかも知れんが。
尤も、そんな回路ならマルチスレッドに関係なく壊しそうだけど。
829:デフォルトの名無しさん
11/12/14 15:52:37.83
そんなハードウェア上で何も組める気がしないぜ
830:デフォルトの名無しさん
11/12/14 16:07:15.72
>>829
しかしそれでも組むのが我々の仕事だ
831:デフォルトの名無しさん
12/01/15 18:00:02.48
物理ディスクとのI/Oコストってデカイじゃん
もしかしたらアーカイブのままメモリに読み込んで、
メモリ中でアーカイブ展開しながら処理した方が
早いんじゃないかとも思うんだが、
検証しやすいサンプルとか無い？
高速展開と、部分抽出が出来れば効果が現れやすいと思う。
832:デフォルトの名無しさん
12/01/15 18:23:45.87
>>831
20年くらい前に、そういうコンセプトのフリーウェアがあったっけな。
とりあえず試してみたら良いだろ。
圧縮率を20%と仮定するなら、100KBのreadにかかる時間と、
80KBのreadにかかる時間差を計測する。
後はオンメモリに置いといて、その時間差ないに解凍できるかだ。
ちなみにディスクの待ち時間の大部分はヘッドのシーク。
データサイズが多少小さくなったところで、得られる時間は少ない。
データが連続している場合、20KB減ったところで1msも短くならないぞ。
833:デフォルトの名無しさん
12/01/15 20:58:51.56
何だ無駄か。読み込みスレッドで随時解凍しながら取り込めば、
ワーカーの処理待ちを減らせるかと思ったのに。
834:デフォルトの名無しさん
12/01/15 22:18:40.46
いや、IO自体のオーバーヘッドは今でもバカにならない。
ネットワーク上のファイルIOもレイテンシがでかい。
いまどき数百MBからGBオーバーのファイルも少なくないんだから、本気でバッファを大きくとるか、コンカレントに処理して欲しい。
アーカイバをいくつか使い比べると何割というレベルの速度差がある。
速い奴はちゃんとそういう所にも気を配ってる。
835:デフォルトの名無しさん
12/01/15 23:21:05.40
そういえば昔、NetWareというサーバOSがあったな
クライアントのローカルＨＤＤをアクセスするよりも
LANでつながったNetWareサーバ上のファイルをアクセスする方が高速だった
古きよき時代
836:デフォルトの名無しさん
12/01/16 01:37:22.73
JavaのFutureとpthread_joinとの違いが、
スレッドプール使えるかどうかぐらいしか解からん。
アレは、pthread_joinとスレッドプール以外じゃ何が違うの？
(オブジェクトと例外返すのは置いといて)
837:デフォルトの名無しさん
12/01/16 01:47:25.07
いやFutureは結果返すためのものだからそれ置いといたらダメだろ
838:デフォルトの名無しさん
12/01/16 02:01:11.36
pthread_joinも結果は返せるからね。
pthread_joinを軽くラップするだけで、
例外を返すのもオブジェクトを返すのも簡単にできちゃう。
結果を返す事だけに注目すると差異としてはあまりに小さいと思うけど。
839:デフォルトの名無しさん
12/01/16 11:48:41.44
>>831
読みきってから処理するのではなく
読みながら処理する
840:デフォルトの名無しさん
12/01/16 13:00:46.78
無圧縮データでディスクIOが、どれくらい
コスト掛かるのか調べてみた。
調べ方は2つスレッドを走らせ、
片方はひたすらカウント、
もう片方はファイル読み込みしながら、
読み込んだバイト数分だけカウント。
どちらもカウント変数をクリティカルセクションで囲んだ。
CPUは2コア。
この条件で実行するとファイル読み込み
してるほうが1/8程度遅かった
遅い遅い言うけどそうでも無いのな。
841:デフォルトの名無しさん
12/01/17 17:41:36.51
キャッシュ読んでるだけじゃないのそれ
842:デフォルトの名無しさん
12/01/17 20:46:09.02
まぁ、NTFSの圧縮ファイルシステム使って早くなるなら、
みんな圧縮してるよね。
843:デフォルトの名無しさん
12/01/18 00:09:55.35
それは一旦全部解答してから読み込むからでしょ
844:デフォルトの名無しさん
12/01/18 15:32:20.55
その認識は完全に間違ってる
URLﾘﾝｸ(blogs.msdn.com)
845:デフォルトの名無しさん
12/01/21 07:08:56.51
2chのログは圧縮フォルダに入れた方が圧倒的に速い
846:デフォルトの名無しさん
12/01/22 10:58:15.73
パソコン側のHDDキャッシュがお馬鹿ってことじゃあ
847:デフォルトの名無しさん
12/01/23 09:41:58.18
>>846
正しいだろ。
848:デフォルトの名無しさん
12/02/21 23:37:31.35
ディスク絡みのスレッドの話だけど、HDDのランダムアクセスの遅さに驚愕した。
任意のスレッド数(プール使用)で、複数同時にファイルを読み込み、
MD5ハッシュを取り出してファイル比較するツールを作った。
んで、1ファイル1MB未満のファイル群と、1ファイル40MBを超える
ファイル群に対して実行してみた。4コア環境で実行したら
1MB未満だと3スレッドが最速。40MB以上だと1スレッドが最速ってな結果になった。
40MB以上で、1スレッドだとディスクアクセスが100MB/sを超える。
40MB以上で、4スレッドだとディスクアクセスは30MB/s未満まで低下した。
みんなは、この辺どう回避してんの？
849:デフォルトの名無しさん
12/02/21 23:46:23.99
>>848
非同期ＩＯとか、メモリマップドファイルとか。
複数スレッドから同時アクセスなんかしたら、ディスクシークが増えて、
帰って遅くなるのは当たり前。
850:デフォルトの名無しさん
12/02/21 23:47:16.21
>>848
NCQにまかせて神に祈る
ってのは冗談で
1. 読む順番が決まっているならデータをデフラグでその順番に並べておく
2. その順番に読めるように1スレッドで読みに行く
851:デフォルトの名無しさん
12/02/22 00:02:11.03
>>849
理屈じゃ分かっちゃいたんだけどねぇ。まさかここまで遅いとは・・・。
>>850
並列化は諦めるしかないのかねぇ。
852:デフォルトの名無しさん
12/02/22 00:31:00.86
ファイルを読むスレッド(1つだけ)とMD5の計算他をするスレッドを分けるとか？
CPU時間がどっちかに偏ってたらだめかもしれませんが。
853:852
12/02/22 00:34:57.35
って850さんが既に言ってますね。ファイルを読むスレッド1＋それ以外の計算をするスレッド複数。
そしてディスクアクセスの時間＞＞計算の時間なら、ディスクが物理的に1つしかない以上は並列化は無理かと。
854:デフォルトの名無しさん
12/02/22 00:49:03.05
>>852
それが微妙なんだよね。
MD5の計算って一般的に順序依存があるから、
1つ前に計算した計算結果が無いと、
次の計算が始められないんだよ。
そんなんもんで、ファイル別なら順序依存が無いから
とりあえず、1スレッド1ファイル処理にしてたんだけど。
実は、ディスクアクセスというよりMD5の
順序依存が一番足引っ張ってんのかもね。
あと、MD5の計算時間だけど読み込みの10倍遅いよ。
855:デフォルトの名無しさん
12/02/22 00:57:48.08
>>854
～かもね、とかの妄想に付き合うのは疲れるから、調べてから書けよ
856:デフォルトの名無しさん
12/02/22 01:17:35.11
>>855
調べるつってもなぁ。発想の問題じゃない？
これ以上調べられることあるかい？
857:デフォルトの名無しさん
12/02/22 01:18:33.05
頼むから喧嘩はやめてくれよな
858:デフォルトの名無しさん
12/02/22 01:18:41.54
> 順序依存が一番足引っ張ってんのかもね。
を明らかにすればいいじゃない
859:デフォルトの名無しさん
12/02/22 01:24:03.16
＞あと、MD5の計算時間だけど読み込みの10倍遅いよ。
あれ？それならいけるんじゃない？
仮に11コアのCPUがあったとして、
1コア目→ディスクから10個のファイルを読み出してメモリに吐く
2～11コア目→1コア1ファイル分担当で計算
って形で10コアまでスケールするはずだと思うんだけど。コアはスレッドと読み替えてもok。
860:デフォルトの名無しさん
12/02/22 01:33:14.66
>>859
ロード時間L, MD5計算時間Mとすると(L=10M)
馬鹿正直にやったら10(L+M) = 110M
お前のやり方だと10L+M = 101M
どこがスケールしてるんだ？
ついでに2スレッドでも101Mは出ると思う
861:デフォルトの名無しさん
12/02/22 01:34:10.53
>>860
ごめんどっちが遅いのか勘違いした
吊ってくるわ
862:デフォルトの名無しさん
12/02/22 01:39:04.31
>>854
計算が10倍遅いなら、シングルリーダスレッドでも十分にペイする。
ただ、机上で計算すればあんたの実測値なら3並列と4並列に分かれ目がある。
ファイル一件の読み込みを1、比較するってことなんでサイズは全ファイル
ほぼそろってるとして、4対象の場合のそれぞれの最長パスは
1リーダ+4計算スレッド： 4+10 = 14
全部で1スレッド： 1*4+10*4 = 44
4(リーダ+計算)スレッド：1*(100/30)+10 = 13.33 (100MB/sが4スレで30MB/sになったから)
まあ実測すると他のプロセスとかとの兼ね合いでまた変わるだろうけど、
多分安定度で言えばシングルリーダスレッド＋N計算スレッドじゃないかなあ。
OSのページキャッシュに乗っている事が期待できる状況ならまた別だけど。
863:デフォルトの名無しさん
12/02/22 01:42:35.74
>>858
ディスクアクセスの改善が無理ならMD5の
順序依存を直すしか無いと言えるんだけど。
もう本当に打つ手がないか意見が聞けないとなんとも。
>>859
確かにね。最終的にはそれが一番効率がいいのかなとも
思うんだけど、ただその方法は計算するファイルは1ファイルまるごと
読み込まないといけないんだよね。
そこがちょっともっといい方法が無いかと引っかかるよ。
864:859
12/02/22 01:45:16.15
861が俺のレスみたいに見えるので一応自己弁護しておこうｗ
ロード時間L, MD5計算時間Mとすると10L=M
シングルスレッド→10(L+M)=110L
11コアによるマルチスレッド→10L+M=10.1L
とほぼ11倍の性能ということで理屈上スケールはするはずだ、と。もう寝るおやすみ～
865:デフォルトの名無しさん
12/02/22 01:46:07.56
>>862
机上の計算の計算式がイミフなんだが
866:860
12/02/22 01:47:47.73
>>864
うんごめん
そのとおり
867:859
12/02/22 01:49:07.58
俺のｱﾎー
マルチスレッドは10L+M=20Lだ。効率は50％弱か。今度こそおやすみー
868:862
12/02/22 02:01:42.37
見直すといろいろあれだったので気にしないでｗ
869: ◆0uxK91AxII
12/02/22 15:13:40.47
thread一つ、非同期読込と計算を交互に行う。
870:デフォルトの名無しさん
12/02/22 17:09:49.10
読み込み時間がクリティカルなんだから
読み込みスレッドが他の作業をしたらダメなんじゃないの?
871:デフォルトの名無しさん
12/02/22 19:17:39.81
HDD一個に複数からアクセスすれば、パフォーマンス低下するのが当然じゃあ
872:デフォルトの名無しさん
12/02/22 20:04:50.74
SSDなら実測値が結構改善するんかね
大して普及してないから宛にならんけど
873:デフォルトの名無しさん
12/02/23 00:31:39.79
スレッド制御に頭使いすぎてI/Oウエイトによる遅延完全に無視してない？
874:デフォルトの名無しさん
12/02/23 00:40:50.43
>>872
普及はどこから出てきた
875:デフォルトの名無しさん
12/02/23 01:04:22.28
>>874
SSDから。
876:デフォルトの名無しさん
12/02/23 01:07:07.00
いやだから。
SSDがとんだけ普及してるか、は実測値に影響する項なのか？ってことだろ
877:デフォルトの名無しさん
12/02/23 01:23:30.75
普及してるかどうかは実測値には影響しないよ。
SSD上での実測値改善が見られるとありがたいけど、
世の中SSD搭載してないPCも多いから、
SSDだけで速くなるプログラムはよくないよねって話しだし。
878:デフォルトの名無しさん
12/02/23 01:25:38.17
そっちかよ
自分とこの環境で動かすんじゃないのか
879:デフォルトの名無しさん
12/02/23 01:49:14.20
自作のハッシュ計算ツールだけど、MD5計算速度はキャッシュに乗ってる状態だと
3GHz弱のCore2Duo程度のCPUでも300MB/sは超えてるぞ。
計算のが十倍遅いってどういうことだ？
HDDなんて速くても100MB/s題だと思うが…
880:デフォルトの名無しさん
12/02/23 01:57:30.10
スレッド構成を書いてもらわないとなんとも言えないなぁ
単にシングルスレッドなら100MB/s超えるしね
881:デフォルトの名無しさん
12/02/23 01:59:55.78
>>879
読み込み時間を差し引いた計算時間はどれぐらいだったの？
882:デフォルトの名無しさん
12/02/23 02:05:32.93
>>879
300MB/sってのは、MD5の関数なりクラスなりが1秒間に
計算できた情報量という理解であってる？
883:デフォルトの名無しさん
12/02/23 02:07:57.39
読み込みと計算は別スレッドで同時にやってるから正確には分からんな。
まあいろいろ状況によって時間が変わるけど、計算だけなら最速時で400MB/sくらいだった希ガス。
ああもちろん、読み込みやってもキャッシュに乗ってたら最速だとほぼ同じくらいまで行くよ。
884:デフォルトの名無しさん
12/02/23 02:31:42.72
純粋な計算速度が負けるってのは構成が gcc+linux+Phenom X4 1.8Ghz だからなのかねぇ
885:デフォルトの名無しさん
12/02/25 14:26:44.01
ちょっとスレッドとは違うかもしれないんだけど
メッセージキューを設計しています
シグナルハンドラからキューに積みたいんですが
どうしても排他制御ができません
うまい方法はありますでしょうか
886:885
12/02/25 14:28:07.28
自己解決しました
887:デフォルトの名無しさん
12/02/28 00:27:52.96
C# の.NET4.0なんですけど
List<Double> hoge は適当な値が入っているとして
Parallel.For(0,hoge.Count,(val)=>
{
hoge[val] = 0.0;
});
とした場合、常にhogeの中身が全て0.0になりますか？
この処理はLockしなくても大丈夫のような気がするんですが少し心配です。
888:デフォルトの名無しさん
12/02/28 00:38:36.19
MSの今のList<T>の実装では問題ないはずだけど保証されているわけではない
でもそれデリゲート呼び出しのコストがかさむから普通にループ回したほうが速いだろ
並列でやるんなら、4コアなら領域を4分割して中でループ回したほうがいい
889:デフォルトの名無しさん
12/02/28 00:46:40.99
つまり、>>887を
Parallel.Invoke(()=>
{
for(int i = 0;hoge.Count/4;i++)
{
hoge[i] = 0.0;
}
},
()=>
{
for(int i = hoge.Count/4;(hoge.Count/4)*2;i++)
{
hoge[i] = 0.0;
}
} ・・・(以下略)
とした方が良いということですか？
890:デフォルトの名無しさん
12/02/28 00:47:12.66
訂正
読み取りだけならスレッドセーフだと書いてあるな
891:デフォルトの名無しさん
12/02/29 12:48:47.15
いくつかstatic変数があって、それぞれに書き込み続ける
スレッドを作ったのですが、コンテキストスイッチが発生
しまくってます(2000～3000/秒)
int a, b, c;
DWORD __stdcall A(void*){ a = ... }
DWORD __stdcall B(void*){ b = ... }
DWORD __stdcall C(void*){ c = ... }
それぞれのスレッドを単独で実行させた場合は、それほど
スイッチしないので、キャッシュ競合が原因なんでしょうか。
それぞれの変数が同じキャッシュラインに乗らないようにするには
どうすれば良いですか?
それともキャッシュは関係ないですか?
VC10です。
892:デフォルトの名無しさん
12/02/29 21:27:49.37
なんでキャッシュでコンテキストスイッチが起こるのよ…
893:デフォルトの名無しさん
12/02/29 22:05:31.00
>>891
コンテキストスイッチは関係ない。
>それぞれの変数が同じキャッシュラインに乗らないようにするには
キャッシュは8～32バイトぐらいの単位で管理しているから、
適当に無駄なメモリを確保して、それぞれのメモリアドレスが
隣接しないようにすればよい。
894:デフォルトの名無しさん
12/02/29 22:19:38.86
>それぞれのスレッドを単独で実行させた場合
はああ？
895:デフォルトの名無しさん
12/03/01 00:23:04.48
メモリバリアの間違い？
896:デフォルトの名無しさん
12/03/01 00:47:56.20
なんでメモリバリアが出てくんだよ
897:デフォルトの名無しさん
12/03/01 00:55:22.06
コンテキストスイッチみたいなのはCPUを占有すると起こるものなの
無限ループしてパソコンがハングしたらどうするつもりなんだろうね
898:デフォルトの名無しさん
12/03/01 01:28:54.69
1スレッドで実行→コンテキストスイッチが起こらない
3スレッドで実行→コンテキストスイッチが起こりまくる
これのどこが悪いのか俺にはわからないのだがとりあえずCPUはいくつある？
899:デフォルトの名無しさん
12/03/01 08:36:10.06
>>898
cpuは4コアです。
>>897
各ループにSleepは挟んでます。
>>893
無駄なメモリを置いて、キャッシュ対策しようと思います。
また、コンテキストスイッチ数が多いのは、別の原因を探してみます。
900:デフォルトの名無しさん
12/03/01 08:45:24.09
Sleep入れたらそりゃぁ、コンテキストスイッチもするだろうよ。
901:デフォルトの名無しさん
12/03/01 15:54:56.63
コンテキストスイッチさせるのがSleepの目的のひとつだもんよ。
902:デフォルトの名無しさん
12/03/01 16:16:45.26
static変数に書き込み続けるスレッドとか
Sleep挟んでますとか
キャッシュ競合を避けるとか
何 考 え て る の よ ？
903:デフォルトの名無しさん
12/03/01 16:43:35.12
マルチプロセスほど枯れきっちゃいない技術だから、ということでしょうがあんめぇ
904:デフォルトの名無しさん
12/03/01 17:01:12.69
スレッドとかどう捉えてるんだろうね？
905:デフォルトの名無しさん
12/03/01 19:41:07.35
>Sleep
噴いたわｗ
906:デフォルトの名無しさん
12/03/01 20:09:58.15
Windowsなんて常時、100スレッド以上動いてるのに。
907: ◆0uxK91AxII
12/03/01 20:27:46.46
4CPU環境、速い順に
キャッシュラインを別にした3thread
キャッシュラインが同じっぽい3thread
threadを作らずに1thread
908:デフォルトの名無しさん
12/03/01 20:42:09.96
>>907
>キャッシュラインが同じっぽい3thread
>threadを作らずに1thread
このふたつどっちが早いかは環境やプログラムによるだろ。
後者の方が早くなる事もあるよ。
909: ◆0uxK91AxII
12/03/02 10:33:44.96
環境と粒度に依存。
910:デフォルトの名無しさん
12/03/26 15:59:30.82
メインプロセスと同じ物理コア内のHyperThreading論理コアで実行されている
サブプロセスが、メインプロセスの動作を邪魔しないようにするためのAPI関数は
ありませんか?
例えば、SetProcessAffinityMaskを同じ値にした2つのプロセスは
SetPriorityClassでサブの優先度を下げれば、メインプロセスが
動いているときはサブプロセスはほとんど動作しなくなります。
しかし、SetProcessAffinityMaskを、メインプロセスで1、サブプロセスで2に
した場合、サブプロセスの優先度が低いにもかかわらず、メインプロセスと
CPUリソースを均等に割り振っているようです。
これを防ぐための、SetProcessPriorityに変わるようなAPI関数はありませんか?
911:910
12/03/26 16:18:58.25
superπを2つのフォルダにコピーして1つをメイン、もう1つをサブとする。
メインのPriorityClassをNORMAL、AffinityMaskを1に固定。
サブのPriorityClassとAffinityMaskを変化させたときの、2つのsuperπの
838万桁計算時間を比較。
記号 P サブのPriorityClass, A: サブのAffinityMask: メインの時間/サブの時間
A P NORMAL, A 1: 5:19/5:22
B P BELOW, A 1: 2:57/5:38
C P NORMAL, A 2: 3:31/3:30
D P BELOW, A 2: 3:30/3:30
E P NORMAL, A 4: 2:53/2:47
F P BELOW, A 4: 2:52/2:47
Dのパターンでのタイムを見ると、サブの優先度がメインより低いにもかかわらず
Cのパターンと同じになっています。
この状況でメインのタイムはFと同等で、サブのタイムはBよりは短くなるような、
SetPriorityClassのような関数はありませんか?
912:デフォルトの名無しさん
12/03/26 16:27:27.46
そんなaffinity maskを設定するのが悪い
913: ◆0uxK91AxII
12/03/26 16:47:02.42
下手の考え休むに似たり。
914:910
12/03/26 16:56:47.14
AffinityMaskを設定したのは、確実に再現させるためです。
実際には設定しなくても、多くのプロセスが動いている場合に
優先度の高いプロセスが、優先度の低いプロセスに阻害される
可能性を排除したいのです。
915:デフォルトの名無しさん
12/03/26 20:42:35.46
そんなπとかどーでもいいもん計算せずに実用的なもんつくれよ。
πなんて20桁でもあれば地球の外周を計算できるぞ。
916:デフォルトの名無しさん
12/03/26 22:29:33.41
>>910
>メインプロセスの動作を邪魔しないようにするためのAPI関数はありませんか?
OSは何？
>Dのパターンでのタイムを見ると、サブの優先度がメインより低いにもかかわらず
>Cのパターンと同じになっています。
もしかしてWindows？
Windowsにはプライオリティブーストなど、CPU占有率の高いプロセスのプライ
オリティを強制的に下げる機能や、アクティブウィンドウを持つプロセスの
プライオリティを強制的に上げる機能があるから、設定した通りのプライオリティ
で動作している事は保証されないよ？
917:910
12/03/27 09:12:32.64
>そんなπとか
superπを作っているのではなく、優先度の制御ソフトを作ろうとしています。
具体的には動画エンコードしながらゲームしているのですが、
core 2のときはエンコーダのプロセス優先度をIDLEかBELOW_NORMALにしておけば
ゲームのフレームレートが落ちることはなかったのですが、
core i7にしたら落ちるようになってしまったのです。
918:910
12/03/27 09:28:22.17
>OSは何？
Windows全般ですが、7固有のAPIでもかまいません。
PriorityBoostで優先度が動的に上下するのは知っています。
BのパターンのメインプロセスはE/Fに比べて
若干時間が長くなっており、これがPriorityBoostなどによる
効果だと思いますが、これくらいは問題としていません。
919:デフォルトの名無しさん
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は出来ているのでマスクには問題無いと思うのですが。
宜しくお願いします。