【初心者歓迎】C/C++室 Ver.106【環境依存OK】

[過去ﾛｸﾞ] 【初心者歓迎】C/C++室 Ver.106【環境依存OK】 (1002ﾚｽ)
上下前次 1-新

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索歴削→次ｽﾚ栞削→次ｽﾚ過去ﾛｸﾞﾒﾆｭｰ

595(1): 2021/03/14(日)20:28 ID:EFkbulbJ(1) AAS
QZ案外初心者やなw
でも言ってることは全面的に賛成
ポインタや参照、クラス等の基本を抑えてからでないとスマポや、C++11からの要素(右辺値参照含む)の使い方もわからんと思う

596: 2021/03/14(日)20:35 ID:ERa14GlL(3/3) AAS
>>593
大変勉強になります
今後もよろしく

597: 2021/03/14(日)20:46 ID:uaeFGveg(4/6) AAS
>>595
＞でも言ってることは全面的に賛成
ありがとうございます！

＞QZ案外初心者やなw
もう永遠の初心者のままだと思っていますが、それならそれで「初心者の気持ちが分かる視点からの意見の表明」という形でコントリビュートするのもありかな…、と。

598: ◆QZaw55cn4c 2021/03/14(日)22:01 ID:uaeFGveg(5/6) AAS
>>594
>>592 は歯ごたえがありそうでしょう？私もこの課題を最初に見たときは眩暈がしました…
それから 10 年くらいかな？？それくらいたってから 2chｽﾚ:tech を書き、なんとか卒業できたような気がします
なおこれは、これでも例外方面に配慮が行き届いていない、とさらに書き直した気がしますが、その書き直しは失くしてしまいました……

599: はちみつ餃子 ◆8X2XSCHEME 2021/03/14(日)23:21 ID:aW+jce3e(2/2) AAS
個別の機能を理解してからそれの組み立て方を学習するのがまどろっこしく感じる人もいると思う。
抽象度の高いほう (スマートポインタなど) から解体していく形での
学習のアプローチもそれはそれでありかもしれん。

個人的には個別の機能を先に学んだほうがいいとは思うんだけどね。
実例から学ぶと使い方のパターンとして頭に入ってしまって正確な理屈を
きちんと習得できない気がするから。

そうは言っても途中で学習を諦めてしまうようだと正確さもくそもないから、
人によってわかりやすさは違うし学習にはいろんなアプローチがあるということは
覚えておいてほしい。

600: ◆QZaw55cn4c 2021/03/14(日)23:51 ID:uaeFGveg(6/6) AAS
確かに、私が理解している狭い範囲においても、イテレータが先かポインタが先か、とか
C++11 / std::thread から入門したけど posix-thread なんか知らん！とか
そんな人から補強説が来るのが楽しみです

601: 2021/03/15(月)07:36 ID:PXZ12KYt(1) AAS
>>591
ご回答ありがとうございます。
理解しました。
その辺も調査しながらやります。

602: 2021/03/15(月)13:58 ID:RVKfnS+W(1) AAS
QZが意外と素直で好印象度アップ
逆に高飛車な餃子の高感度ダウン

603: 2021/03/15(月)21:47 ID:pqfQRyG1(1) AAS
Qちゃんは昔からいるけど態度は変わらんね
ときどき自前のコード上げてるあたりは好ましい
プロへのリスペクトは持ってるし謙虚ではある

餃子ちゃんはマジメというか
いちいち規格に沿って発言してくれるんで好ましい
ただコード上げてるのはみたことないんで実力は不明
アマチュアなのにときどき調子乗っちゃってるのも微笑ましい

604: 2021/03/15(月)23:09 ID:kCaDVUc0(1) AAS
はちみつのコードたまーに見るけどすごい変な癖があるよ
意味があるなしに関わらず固執するタイプなんだろうな

605(2): 2021/03/16(火)13:45 ID:A61zCves(1) AAS
参照を返す関数の質問です。
オブジェクトの複数のパラメータを設定するときに、obj.param1(...).param2(...).param3(...); みたいに呼ぶ
パターンがあるじゃないですか（ちなみにこれって名前はあります?）

これをやりたいときは
Obj& param1(int val) { mParam1 = val; return *this; }
みたいに参照を返すように宣言しないとダメですよね?

Obj param1(int val) { mParam1 = val; return *this; }
だと、obj.param1(...) は動くけどリターン用にオブジェクトの（余計な）コピーが発生する、
obj.param1(...).param1(...) みたいに呼んだ場合はオブジェクトのコピーに2番目の呼び出しが行われ、
結局破棄されてしまうので、objに2番目のparam1()の呼び出しが反映されない。
省5

606: 2021/03/16(火)16:13 ID:xnFU2goU(1) AAS
builderパターンやね

607: はちみつ餃子 ◆8X2XSCHEME 2021/03/16(火)16:40 ID:AqAKN3jJ(1/2) AAS
クラス構成を見ればビルダーパターンにあてはまりそうだけど、
メンバ関数を連鎖していく表記法のことはメソッドチェインと言ったり、
目的から言うと名前付き引数イディオムということもある。
外部ﾘﾝｸ:en.wikibooks.org
(要するに考え方のレイヤによる。)

608: 2021/03/16(火)17:00 ID:7emEuadh(1) AAS
obj + a + b + c
　operator + () は　obj そのものを書き換えず、新たな実体を戻す

obj += a
　operator += () は　obj そのものを書き換えるついでに、自分自身の参照を戻す

これのどっちに合致したほうが都合がいいかで
複製を戻すか、自分自身の参照を戻すかを分けてる感じ

609(1): 2021/03/16(火)20:32 ID:VN15UowM(1) AAS
>>605
> （ちなみにこれって名前はあります?）

大きく言うとFluent interface
外部ﾘﾝｸ:en.wikipedia.org

610(1): ◆QZaw55cn4c 2021/03/16(火)21:25 ID:EIvloTfy(1) AAS
>>609
その wikipedia の C++ サンプルは int main() が二箇所に現れていますが、これってどう読むのですか？

611(4): 2021/03/16(火)22:36 ID:ne+I3KBD(1) AAS
すみません。
仮に、本を買って勉強する場合は独習C++というのがいいのですか？
独習C++はCの知識がなくても大丈夫ですか？？

612: はちみつ餃子 ◆8X2XSCHEME 2021/03/16(火)23:10 ID:AqAKN3jJ(2/2) AAS
>>610
単に使い方のサンプルを便宜的に main で書いてあるだけでふたつあるのは特に意味ない。

613: 2021/03/18(木)18:04 ID:KYeguKkE(1/2) AAS
>>611

614: 2021/03/18(木)18:05 ID:KYeguKkE(2/2) AAS
>>611
江添本一択

615: 2021/03/18(木)18:59 ID:OslqqG1Q(1) AAS
>>611
C関係無しで覚えるのもいいんじゃね？

616: 2021/03/18(木)19:00 ID:OIk6P4WM(1) AAS
>>611
独習C++はCの知識が前提だったはず

617(1): ◆QZaw55cn4c 2021/03/18(木)23:28 ID:QiBLMBVe(1) AAS
>>605
＞これをやりたいときは
＞みたいに参照を返すように宣言しないとダメですよね?
＞obj.param1(...).param1(...) みたいに呼んだ場合はオブジェクトのコピーに2番目の呼び出しが行われ、
＞結局破棄されてしまうので、objに2番目のparam1()の呼び出しが反映されない。

確かに、メソッドチェインを繰り返すたびにコピーコンストラクタが呼び出されるのは、イマイチ、という感覚を私も同様に持ちます
だからメソッドチェインを書くときには私も参照を返すように書きます、結局のところ「参照を返す」というのは「ポインタを返す」ことですから、コンストラクタの走りようがない

しかし「参照を返す『必要がある』」と言い切れるかどうか？
「結局破棄される」というのは最後のメンバ関数が返す実体を回収していないからであり、「参照を返すから」破棄されるわけではないと感じました。
実際、この実体を回収すれば、それはそれで 2 番目以降の呼び出しが意味を持つように書けると思います
省4

618(1): 2021/03/19(金)03:28 ID:mbZVOQ2F(1) AAS
だからムーブコンストラクタとムーブ代入演算子があるんだろうが・・

619: 2021/03/19(金)03:37 ID:0CmLwf9e(1) AAS
>>617-618
てかそもそもコンストラクタ走っていいのかよこの場合に

620(1): 2021/04/09(金)12:21 ID:dUyySPje(1) AAS
クラスFooのメンバ関数fの型ってどう書くの？
戻り値void、引数intです。

621(1): 2021/04/09(金)12:52 ID:N6zWukcq(1) AAS
>>620
f の型は void (int) だけど f へのポインタの型は void (Foo::*)(int)

622(1): 2021/04/09(金)18:45 ID:WYvZUx+H(1) AAS
>>621
それはメンバ関数へのポインタでしょ
聞いてるのは関数の型でもなく、メンバ関数の型です

623: 2021/04/09(金)20:18 ID:DC3guaga(1) AAS
言われてみれば関数の型ってなんだ？

624: はちみつ餃子 ◆8X2XSCHEME 2021/04/09(金)21:13 ID:foJJo5gI(1) AAS
C だと関数指示子 (Function Designator) で説明されたりするんだが、
C++ の仕様を Designator で検索しても出てこないな。
シグネチャもまたちょっと違う概念だし、
このあたりのきちんとした解説がまとまったものがあればぜひ読みたい。

625: 2021/04/09(金)21:39 ID:MYEEijki(1) AAS
「メンバ関数の型」が必要になるケースって何じゃろ？

626: 2021/04/10(土)01:44 ID:4ITkpFPM(1) AAS
>>622
だから「f の型は void (int)」って書いたのに、なんでそれが答えじゃないと思うの？

typedef void ftype(int);
struct Foo { ftype f; };
void Foo::f(int) {}
int main() { Foo x; x.f(0); }

627: 2021/04/10(土)08:44 ID:gtw6CEDD(1) AAS
関数ポインタを考える以前は関数の型と言えばイコール評価した値の型だったな。

628: 2021/04/13(火)16:10 ID:uVvL/txB(1) AAS
今は関数の型とかもうどうでもよくて
一周回り帰えりキャプチャとかダイナミックスコープとかの有用性や整合性が中心よね

629: 2021/04/15(木)15:55 ID:6RtJrvVe(1) AAS
pod的な意味でなく論理的整合性的な型付けの恩恵受けたいなら、別に包む必要無くても常に即席structで返しててやんでい

630(1): 2021/04/24(土)08:11 ID:LUJ0Utr0(1/4) AAS
C++/CLIで、スタティックライブラリからマネージドクラスを公開するのは無理なんでしょうか？
ヘッダファイルに全部実装書けば出来る、ってところまでは調べたんですが、ソースコードをプロジェクト外に置いてるのと変わらないので…。
ダイナミックライブラリでできるならそれでも構わないです。

631(1): 2021/04/24(土)08:19 ID:nPKzA798(1) AAS
>>630
.NETでstatic libraryなんて作れたっけ？
最終的に.exeと.dllができるのが邪魔だからstatic libraryにしたいというだけなら、
いったんDLLとして作ってILmergeするのが一般的だと思う

632: 2021/04/24(土)08:36 ID:LUJ0Utr0(2/4) AAS
>>631
Lib自体は作れるし、アンマネージクラスなら公開もできるんですが、マネージクラスだと参照側でメンバーが参照できず、LNK2020が発生してしまうんですよね。
ビルドオプションでなんとかできるものなのかな、と。

633(1): 2021/04/24(土)09:53 ID:K4uxnQki(1/2) AAS
LNK2020ってそれnativeのC++からリンクしようとしてる？

634: 2021/04/24(土)14:56 ID:LUJ0Utr0(3/4) AAS
>>633
libなのでクライアントはC++です

635(1): 2021/04/24(土)15:16 ID:K4uxnQki(2/2) AAS
そりゃ無理。その仲立ちをするためにC++/CLIがあるのに。
一応nativeのC++からでも自分でCLRを立ち上げたりしてマネージドクラスにアクセスする方法は
あるらしいが、リンクしてそのまま呼ぶという形にはならない。

636(12): 2021/04/24(土)15:41 ID:at4cvaWV(1/2) AAS
自作のプログラム、起動時の読み込み処理の前に以下を入れると
for(int i = 0; i < 100; ++i){
OutputDebugString("dummy!!!!\n");
}
起動時に行っている外部データの読み込みが凄く速くて
これを無くすと凄く遅くなるんですが怖い…
3分くらい違いが出るので明らかにおかしい
どっかでメモリでもぶっ壊れてますかね？
どういう理由が考えられるでしょうか？

637(1): 636 2021/04/24(土)15:43 ID:at4cvaWV(2/2) AAS
さっきのダミーを入れなくても
普通にコードを追加したりしてても遅くなったり速くなったりする
別に読み込み処理の部分とは関係ないところでも。
なんでだろう？

638(1): 2021/04/24(土)15:54 ID:hc4SaSPr(1) AAS
>>637
それは、本当に native の C++？
もしかして、C#のC++/CLI とか？

639(1): 2021/04/24(土)16:03 ID:lkpB631F(1) AAS
コンパイラはほんと何してるのか分からんから、問題の部分だけ切り出したのを.sへ吐かせて読みなさい
10行程度のcコードなら、edxとか変な名前のは取り敢えず変数だなって思って追えば、アセンブリ知らずとも大体分かるよ

640(1): 2021/04/24(土)20:39 ID:LUJ0Utr0(4/4) AAS
>>635
いや、
C++ライブラリ内にマネージクラスを作って
マネージのC++プロジェクトから
呼び出したいだけ
DLLだったら、C#のDLLからマネージクラスを呼び出すのと
理屈上同じだからできそうな気がするのだけれど

以前実装した時はInterfaceだけ公開して
呼び出されるとそのインスタンスを返す、みたいなことをしたんだけれど

641(1): 2021/04/24(土)21:31 ID:+v1plSJo(1) AAS
>>640
.NETはstatic libraryをサポートしていない
出来上がった.libにはそのマネージドクラスのメタデータとか入ってないんじゃない？

642(1): 2021/04/25(日)00:05 ID:Oojm0ZzH(1) AAS
>>641
結局そういうことだよね
なんか普通にlibのクラスを呼び出せますみたいなのをサンプル付きで出してた記事があってさ…。

まあstaticメソッドしかないクラスばかりだから、アンマネージクラスで公開するか、namespaceでまとめます。
ありがとうございました。

643(2): 636 2021/04/25(日)00:07 ID:sRfn5IZk(1/11) AAS
>>638
C++とWin32APIのプログラムです
>>639
これは自分へのレスですか？

特に遅くなる以外は止まったりする事もないので
困ることはないですがなんか気持ち悪い…

644: 2021/04/25(日)03:40 ID:vJWG11Gh(1/7) AAS
>>643
外部データの読み込みは、fopen, _open, CreateFile、CFile のどの系統を使
ってる？

645(2): 2021/04/25(日)03:43 ID:vJWG11Gh(2/7) AAS
>>643
関係ないかもしれないが、HDDが寿命で故障寸前の時にHDDの読み込みが
時々極端に遅くなったりする現象を経験したことがある。
その場合は、そのプログラム以外でも同様の現象が起きるが。

646(1): 2021/04/25(日)03:49 ID:vJWG11Gh(3/7) AAS
>>645
もし、他のアプリやファイルマネージャーも遅くなることがあるなら、
CrystalDiskInfoなどで診断してみて欲しい。
そのアプリだけ遅くなるが、アプリの動作は正常、というなら、
メモリーやスレッドやOSリソースの使いすぎなども考えられなくは無いが。
何か極端に変わったことしてたりしない？

647(1): 2021/04/25(日)09:07 ID:x26Nnfhp(1) AAS
OutPutDegugなんちゃらの関数がファイル出力してるなら、単純にそのドライブのアクセス準備が整ってないとか。

以前、SSDに同じファイル名で一時ファイルの作成と削除を繰り返したら、SSDの仕組み上めっちゃ遅くなったことがある。

648: 2021/04/25(日)09:59 ID:j6IXZwA/(1/2) AAS
>>642
どこの記事？
ちょっと気になった

649: 636 2021/04/25(日)10:38 ID:sRfn5IZk(2/11) AAS
>>645-647
遅くなる原因の個所が分かった！
画像を読み込む時にメモリを操作して
16bitで読み込む部分があるんだけど
これを32bitで読み込むようにすると
どんなコードでもまったく遅くならない。
メモリの操作の部分がおかしかったみたい。
自分で書いたコードじゃないのでよくわからない。
32bitのやつと16bitのやつを載せるのでおかしい所あったら教えて。

650(6): 636 2021/04/25(日)10:39 ID:sRfn5IZk(3/11) AAS
これは遅くならないコード
int X = 0;
for(int y = ImageHeight - 1; y >= 0; --y){
X = 0;
for(int x = 0; x < ImageWidth; ++x){
pPx[X] = ((DWORD*)pSrcBuf)[x + (y * ImageWidth)];
++X;
}
pPx += Pitch;
}

651(5): 636 2021/04/25(日)10:42 ID:sRfn5IZk(4/11) AAS
これが遅くなる場合があるコード
WORD px, tmp;
BYTE b;
int X = 0;
for(int y = ImageHeight - 1; y >= 0; --y){
X = 0;
for(int x = 0; x < ImageWidth; ++x){
px = 0x00000000;
pPx[X] = px;

b = (BYTE)((((DWORD*)pSrcBuf)[x + (y * ImageWidth)] & 0xff000000) >> 24); //A
省16

652(1): 636 2021/04/25(日)10:46 ID:sRfn5IZk(5/11) AAS
pPxは、32bitの時はDWORD*で、16bitの時はWORD*になってた。
全て載せると長くなるので変更すると速度が変わる部分だけ載せたよ。
16bitの方でも>>636のダミーを入れれば遅くならないんだよね。
やっぱメモリが壊れてるのかな？

653(2): 2021/04/25(日)11:02 ID:vJWG11Gh(4/7) AAS
>>651
pSrcBuf, pPx, Pitch の型、及び、それらを初期化しているコードが重要。
そこに問題があるとバッファオーバーランしている可能性が捨てきれない。

654(1): 2021/04/25(日)11:04 ID:vJWG11Gh(5/7) AAS
>>653
「初期化しているコード」を載せる際、ImageWidth, ImageHeightとの
値の関係が分かるようにしてほしい。
要は、ちゃんとバッファの範囲内に読み書きが収まっているかどうかが知りたい。

655(1): 2021/04/25(日)11:19 ID:vJWG11Gh(6/7) AAS
>>652
例えば、pPxの指しているメモリーブロックのバイトサイズが、
Pitch * ImageHeight * (pPx の 1 要素当りのバイト数)
以上に、pSrcBufの指しているメモリーブロックのバイトサイズが、
ImageWidth * ImageHeight * 4
以上になっていることが重要。

656(1): 2021/04/25(日)11:46 ID:vJWG11Gh(7/7) AAS
そういえば、pSrcBufを((DWORD *)pSrcBuf)のようにキャストしてから使っている
ことも気になる。
pSrcBuf = new DWORD [ImageWidth * ImageHeight]
ではなく、
pSrcBuf = new BYTE [ImageWidth * ImageHeight * 4]
などとしているのだろうか。

657: 636 2021/04/25(日)12:16 ID:sRfn5IZk(6/11) AAS
>>653-656
void *pSrcBuf;
LONG Pitch;
pPxは、16bitの時がWORD*で32bitの時がDWORD*
という感じになってた。

初期化の部分がかなり複雑で結構辿って調べる必要があるんだよね…
でも思うのは初期化は、16bitと32bit大体同じで違うのはpPxの型くらいで
それで>>650の32bitのコードだと全然遅くならないから
>>651の16bitのコードの部分自体が何か変だったのかなと思ったんだけど
ここ自体は大丈夫なのかな？

658(1): 2021/04/25(日)13:26 ID:QOuShU0Z(1/2) AAS
そもそも遅くなるって何分が何分になるん？
100分が103分ならそんなもんじゃね？
としか思えないし

659(1): 2021/04/25(日)13:48 ID:sRfn5IZk(7/11) AAS
>>658
それが30秒が2分とか3分とかになっちゃって。

660(1): 2021/04/25(日)14:01 ID:9Nm1id/y(1/4) AAS
>>659
それだとせいぜい6倍くらいだね。
>>650 と >>651 だと 6倍くらいの差が出るのは当然だよ。

661(3): 2021/04/25(日)14:37 ID:sRfn5IZk(8/11) AAS
>>660
いやそうじゃなくて、>>636のダミーコードを入れると
何故か速い速度になって、それを取り除くと遅くなってしまう感じ。
普通にコード書いてても関係ない部分を追加したりすると遅くなったり
速くなったりするからおかしいなと思ってて。

662(1): 2021/04/25(日)14:41 ID:9Nm1id/y(2/4) AAS
>>661
なるほど。では、
>初期化の部分がかなり複雑で結構辿って調べる必要があるんだよね…
であったとしても、原因を特定するには、少なくともまずそこを丹念に
調べる必要がある。

663(1): 2021/04/25(日)14:41 ID:QOuShU0Z(2/2) AAS
>>661
とりあえず遅いコードと速いコードを晒してよ
バッファーオーバーランで制御変数壊してるとかあるかも知れんし

664(1): 2021/04/25(日)14:45 ID:9Nm1id/y(3/4) AAS
>>661
そういえば、速い時でも30秒もかかっていることはとても気になる。
>>650 のコードだとどれくらいの時間になるの？
経験と勘で言えば、そのような平易なコードで30秒も掛かって、
時と場合により3分もかかるという現象が起きる場合、キャッシュ
が乱れている可能性がある。
もしかして、どこかで極端にメモリーをランダムアクセスしてない？
巨大なメモリーの中を、極端に不連続な場所をあっちこっちアクセスすると
キャッシュが聞きにくくなって、急激に遅くなることがある。

665(2): 2021/04/25(日)14:57 ID:sRfn5IZk(9/11) AAS
>>662
確かにそこは念入りに調べる必要がありますね。
>>663
それが本当に>>636をまったく関係ない部分に入れるだけで
速くなったりしてて。普通にコード書いてまったく関係ないところ追加したりすると
速くなったり遅くなったりするんだよね。一旦速くなったら弄らない限り遅くなる事はなくて
逆に一旦遅くなったら弄らない限り速くなったりする事はない感じ。
>>664
読み込んでメモリ操作する部分自体はかなり多い数をやってるので
20〜30秒くらいかかる時もある感じ。
省2

666(1): 2021/04/25(日)15:04 ID:9Nm1id/y(4/4) AAS
>>665
>読み込んでメモリ操作する部分自体はかなり多い数をやってるので
>20〜30秒くらいかかる時もある感じ。
話を総合すると、
>>650 のコードが、「20〜30秒くらいかかる」が、
>>651 のコードが、速い時には「30秒」
ということになるが、コードを見る限り、651のコードは650の
コードの10倍以上かかっても不思議ではないコードになっているので、
この速度差はむしろ、少な過ぎる。
むしろ、>>651のコードは「3分」かかっている方が、
省1

667(1): 2021/04/25(日)15:13 ID:CFgRAQQ/(1) AAS
読込とか細かいメモリー確保とかコードに無いこと言われてもエスパーじゃないのでどうしょうもないな
悪いけど情報出せないなら他でやってくれ

668(1): 2021/04/25(日)15:19 ID:sRfn5IZk(10/11) AAS
>>666
今チェックしたら650の方が少し速かったですｗ
650が12秒くらいで、651が22秒くらいでした
これが速い場合で、651が遅い場合は2分くらいでした。
650は遅くなることがないです。

>>667
ほんとうにそうですね。
とりあえず晒した所が大丈夫なら
他の部分は自分で調べてみようと思います。

669(1): 2021/04/25(日)15:45 ID:S2tV53BX(1/2) AAS
>>668
>今チェックしたら650の方が少し速かったですｗ
>650が12秒くらいで、651が22秒くらいでした
>これが速い場合で、651が遅い場合は2分くらいでした。
>650は遅くなることがないです。

これだけでも重要なことが分かる。以後は、処理時間に関する(数学的な)定量的な話になる。
まず、650と651の速度差が1.8倍程度しかないことからすると、
pSrcBuf と pPx の読み書きに相当時間が掛かっていることを示唆している。
650と651のソースを比較した時、計算部分の処理がとても増加しているが、
読み書きはキャッシュまで考慮すると、650と651で差が出ない。
省14

670(1): 2021/04/25(日)16:25 ID:sRfn5IZk(11/11) AAS
>>669
細かい分析ありがとう。
だとしたら>>636のダミーを入れると速くなるのも
そのキャッシュの原因に何か関係してるのかな？
でも今まで>>665でも書いたように一旦遅くなったら
遅くなったままで、速くなったら速くなったままなんだよね… コード弄らない限り。
もしかすると何か条件が重なればコードを弄らなくても遅くなったり
速くなったりすることもあるのかもしれないけど。今のところは確認出来てない感じ。

671(1): 2021/04/25(日)16:32 ID:S2tV53BX(2/2) AAS
>>670
それより、650のコードで12秒も掛かっていることにかなり違和感を覚える。
ImageWidth が、ImageHeight が 2000 位までなら、4*10^6 ピクセルくらいで、
32BIT RGBカラーだとしても16MB位。
いまのCPUだと、>>650のコードくらいで12秒も掛かるはずは無い。
大雑多な予測だと、3.0GHzのCPUで、10(ms)くらいまでのはず。
ImageWidth や ImageHeight の値はいくらくらいになってる？

672(1): 2021/04/25(日)17:04 ID:/0G3TNx0(1) AAS
650は最適化で X も x も同じ値で遷移していくし内側のループは
memcpy 相当のブロック転送におきかわりそうだけど

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 な方向

ん？メモリ操作なコードだけど実はメモリマップドファイルだったりして

693: 2021/04/28(水)15:30 ID:WdoV9Bq9(2/2) AAS
走査線と描画が重なったらチラツキが激しくなるから下から描いていくんだよ

694(2): 2021/06/14(月)15:32 ID:TE2ntQhj(1) AAS
for(int a=0; ...; ...){...} とかはループ内だけのスコープで int a が使えるのに

int a;
while(a){...}
とか
int a;
do{...}while(a);
とかは
while(int a=...){...} ←これだけはOK?
とか
do{...}while(int a=...);
省3

上下前次 1-新書関写板覧索設栞歴

あと 308 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.058s