[過去ﾛｸﾞ] 【初心者歓迎】C/C++室 Ver.106【環境依存OK】 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
673(1): 2021/04/25(日)20:18 ID:j6IXZwA/(2/2) AAS
650使えば遅くならないならいったん解決？
674(2): 2021/04/26(月)01:18 ID:0cli3R6k(1/4) AAS
>>671
大きな画像(2048*2048)とかを結構読み込んでて。
読み込み処理自体は他の部分もあるのでそのくらいになってしまってる感じ。
>>672-673
一応は650にすれば何の異常もなくとても速く動作はするんだけど
出来れば原因が知りたいと思ってて。難しいならもうあきらめるけど。
675: 2021/04/26(月)01:51 ID:u7NjNSbC(1/3) AAS
>>674
ファイルから読み込んでるらしいけど、fseek をループの中で多数回使うと
使わない場合と比べて劇的に遅くなるけど、seek 系の関数は使ってない？
676: 2021/04/26(月)02:03 ID:+l9LtKe6(1) AAS
ファイル読み込みの部分でHDDキャッシュがかかってるかどうかだったり
よくある話
677(3): 636 2021/04/26(月)02:36 ID:0cli3R6k(2/4) AAS
色々と試行錯誤してたら
>>651のコードのこの部分を
for(int x = 0; x < ImageWidth; ++x){
このように書き換えたら普通に速くなったｗ
for(int x = 0; x < ImageWidth / 1.0f; ++x){
なんか最適化が効いたり効かなかったりみたいな差に感じてしまう。
そういう原因なのかな？
678(1): 2021/04/26(月)02:37 ID:u7NjNSbC(2/3) AAS
>>674
2048 * 2048 ドットの画像だとベタデータにしたとき16MBになってしまうので、
それを沢山読み込むとメモリー不足になり仮想記憶が働いてしまっている可能性も
有るかも知れない。どれくらいの枚数読んでいるか知らないのでなんとも
言えないけど。
679(1): 2021/04/26(月)02:39 ID:u7NjNSbC(3/3) AAS
>>677
使ってるのはVisualStudioのようだけど、速度を測定する時には、ちゃんと
Release版にして最適化は有効にしてる？
DebugPrintを使っているなら最適化はOFFになってるのでは？
680: 2021/04/26(月)02:43 ID:0cli3R6k(3/4) AAS
>>678
でも>>677の修正で速度が劇的に変化するのはなんでなんだろう？
>>679
Releaseで調べてるよ。OutputDebugStringはReleaseモードでも使えるので。
681: 2021/04/26(月)02:46 ID:0cli3R6k(4/4) AAS
>>677の修正をしたあと、>>636のダミーコードを
追加したらなんと今度は遅くなったｗｗなんでだ？ｗ
>>636のダミーコードだけ追加したら速くなって
ダミーコードを削除すると遅くなる
その遅くなった状態で>>677の修正をすると速くなる
その速くなった状態で>>636のダミーコードを入れると
今度は遅くなるｗｗ
682(1): 2021/04/27(火)02:43 ID:qV+SOSDm(1) AAS
状況から察するに、おそらく君が見ている部分じゃない
どこかに根本的な問題がある、という気がする
なんとなくだけど、バッファオーバラン系のような気がする
683: 2021/04/27(火)05:25 ID:Vf/GSwOl(1) AAS
>>682
どこかに問題がありそうですよね。
バッファオーバラン系は問題あっても動いてしまう事があるから怖いですね。
地道に調べて行くことにします。
684(1): 2021/04/27(火)11:47 ID:V9b4VlmB(1) AAS
それより、12秒間も大量のメモリーを使う状態でCPUがフルパワー状態になっている
とすれば、フル・キャッシュ汚染してる可能性がある。
フル・キャッシュ汚染すると、その後しばらくの間、キャッシュを取り戻すために
速度が不安定になるから、説明可能。
685(1): 2021/04/27(火)12:52 ID:cPrICHbO(1) AAS
Meltdowm や Spector 対策のパッチの影響とか？
特定のパターンのメモリアクセスに対して例えばなんかのトラップが働いてキャッシュをクリアし、ダミーコード入れるとそのパターンが崩れてそういう処理が入らないとか。
686(1): 2021/04/28(水)02:54 ID:XgRH6ChF(1/2) AAS
>>684-685
みなさんありがとうございます。
色々な問題が考えられそうですね。参考になります。
もう少しコード弄りながら挙動を調べて行きたいと思います。
687(2): 2021/04/28(水)04:32 ID:v8E9sca8(1) AAS
>>686
なお、y方向に関して、メモリーを上下逆さまに読んでいっているところがあるが、
本当はそういうのはDDR-Memoryやキャッシュと余り相性が良くない。
しょうがないけれども。
それでも、x方向には「順方向」に読んでいるからまだなんとかなっている。
完全にメモリーを逆方向に読んだりすると、低速化の原因になる。
この場合には難しいが、なるべくならメモリーは順方向にアクセスした方が
速くなる。DDR-MemoryはBurst転送が基本なので。
キャッシュに乗っていれば、逆方向でもなんとかなるが、キャッシュから
外れると、DDR-MemoryのBurst転送とは逆方向にアクセスするのは
省1
688: 2021/04/28(水)10:42 ID:XgRH6ChF(2/2) AAS
>>687
そういう問題もあるんですね。とても詳しくて勉強になります。
ありがとうございます！
689(2): 2021/04/28(水)11:32 ID:oswWyFbg(1) AAS
>>687
読み書き方向が逆になるなら、読む方を順方向にすると良さそうだと思うけどどう思う？
690: 2021/04/28(水)13:14 ID:WdoV9Bq9(1/2) AAS
>>689
コンパイラのくせに生意気だぞ
691: 2021/04/28(水)13:16 ID:jQpDsyge(1) AAS
>>689
実は昨日の夜から、俺もそう思ってた。
今は、
読む方が逆方向で、書く方が順方向になってしまっているが
読む方を順方向に、書く方を逆方向にした方が DDR-SDRAM や キャッシュの
仕組みから行って速くなる可能性が高い。
692: 2021/04/28(水)14:04 ID:4fcF+gv5(1) AAS
Windows の bitmap で ファイル中の配置や CreateDIBSection() で戻ってくるメモリの配置だな
デフォで bottom - up の方向 カメラのフレームとかは top - down な方向
ん？メモリ操作なコードだけど実はメモリマップドファイルだったりして
上下前次1-新書関写板覧索設栞歴
あと 310 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.029s