Win32API質問箱 Build123

1 名前：デフォルトの名無しさん mailto:sageteoff [2016/10/08(土) 12:33:02.29 ID:0jaJMPXG.net] Win32APIについての質問はこちらへどうぞ。 ■注意 ・質問する前にMSDNライブラリやPlatformSDK、Google等で検索しましょう。 ・日本語版MSDN Online Libraryは不完全です。 　英語版( msdn.microsoft.com/en-us/library/ )の利用推奨。 ・APIフックなど高度な事をしたい場合はできるだけAdvenced Windowsを読みましょう。 ・言語特有の問題やIDE、MFCやVCLなどの質問はそれぞれの言語や開発環境スレで ■過去スレ Win32API質問箱 Build122 echo.2ch.net/test/read.cgi/tech/1451988219/ 152 名前：デフォルトの名無しさん mailto:sage [2016/11/13(日) 23:32:34.76 ID:+F2H1InO.net] 非表示はWM_UNINITMENUPOPUP MF_DISABLEDとMF_GRAYEDが違ったのはWindows3.1とかの時代で今は同じ 153 名前：150 mailto:sage [2016/11/13(日) 23:57:21.61 ID:Wy5L1qQW.net] >>152 ありがとうございました！ 助かりました！ 154 名前：デフォルトの名無しさん [2016/11/14(月) 17:38:20.71 ID:lPYI51le.net] リストビューを一番下までスクロールさせるプログラムは？ 155 名前：片山博文MZ ◆T6xkBnTXz7B0 mailto:sage [2016/11/14(月) 17:39:51.88 ID:L1+AAJlg.net] >>154 WM_VSCROLL 156 名前：デフォルトの名無しさん mailto:sage [2016/11/14(月) 17:51:37.15 ID:LtnXkA90.net] メッセージおくれ 157 名前：デフォルトの名無しさん mailto:sage [2016/11/14(月) 18:02:49.89 ID:NhpFtVry.net] ListView_EnsureVisible()マクロないしは ListView_Scroll()マクロ 158 名前：154 mailto:sage [2016/11/14(月) 19:38:32.87 ID:lPYI51le.net] >>156-157 サンクス！ 159 名前：デフォルトの名無しさん [2016/11/18(金) 03:17:57.05 ID:OSOzrvg7.net] > MF_DISABLEDとMF_GRAYEDが違ったのはWindows3.1とかの時代で今は同じ xpはどちら？ 160 名前：デフォルトの名無しさん mailto:sage [2016/11/18(金) 03:36:41.14 ID:AM2vlSzW.net] えっ？ 161 名前：デフォルトの名無しさん mailto:sage [2016/11/18(金) 03:58:35.98 ID:2yb3wpBY.net] >>156 つ メッセージ 162 名前：デフォルトの名無しさん mailto:sage [2016/11/18(金) 07:05:51.48 ID:8X6DMoza.net] Win3.1(Win16) ならスレ違いだろｗ 163 名前：デフォルトの名無しさん mailto:sage [2016/11/18(金) 11:11:21.47 ID:GZ4BhfWs.net] Win32sかもしれない 164 名前：デフォルトの名無しさん [2016/11/18(金) 15:45:40.16 ID:sN4pSlll.net] WS_EX_TOOLWINDOWに関して質問です。 タイトルバーに� 165 名前：ﾖしてです。 普通のタイトルバーより小さいタイトルバーを持つ旨説明がありますが、 小さくなりません。 通常のスタイルも色々試しましたが、通常のタイトルバーと変わりません。 変える方法を教えてください。 [] [ここ壊れてます] 166 名前：デフォルトの名無しさん mailto:sage [2016/11/18(金) 16:01:28.45 ID:AM2vlSzW.net] win8辺りからタイトルバーが小さくならなくなったべ。 理由は知らんけど、エアログラス廃止→モダンUIの流れの一環で何か変わったのかもね。 167 名前：デフォルトの名無しさん [2016/11/19(土) 12:52:23.68 ID:LZczXE+c.net] > MF_DISABLEDとMF_GRAYEDが違ったのはWindows3.1とかの時代で今は同じ 7で非エアロ + 視覚効果を無効にした場合はどちらになりますか 168 名前：164 mailto:sage [2016/11/19(土) 22:31:46.85 ID:m8v4iLe9.net] >>165 なるほど、そういうことだったんですか。 ありがとうございます。 169 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 10:34:28.02 ID:rUGeTkRI.net] Windows3.1 って 標準で１画面に16色しか使えなかった時代の名残だから忘れていい 170 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 10:50:09.74 ID:pCJ1qvOZ.net] 3.1のときには256や6万色普通にあったろ 171 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 12:16:32.29 ID:KiQiujJB.net] 16bit と間違ったんじゃね 172 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 12:20:21.09 ID:IiH4Q+hE.net] PC-9801の話だと思った。 173 名前：デフォルトの名無しさん mailto:sage [2016/11/20(日) 16:35:07.06 ID:HG1JDYXN.net] PCG 174 名前：デフォルトの名無しさん mailto:sage [2016/11/21(月) 11:15:47.37 ID:RFCc0VFb.net] ビデオカード次第だったよな 175 名前：デフォルトの名無しさん mailto:sage [2016/11/21(月) 12:21:40.28 ID:gVIfBZaZ.net] PSG 176 名前：デフォルトの名無しさん [2016/11/22(火) 15:36:11.99 ID:qW+6ZAFd.net] sscanf(buffer, "%4s", &data)の4の部分に変数を使いたい場合ってどうしたらいいんでしょう？ 177 名前：デフォルトの名無しさん mailto:sage [2016/11/22(火) 15:42:16.93 ID:eab8TQx6.net] "%4s"をsprintfで作る 178 名前：片山博文MZ ◆T6xkBnTXz7B0 mailto:sage [2016/11/22(火) 15:44:33.07 ID:iRpYF31I.net] "%*s" 179 名前：デフォルトの名無しさん mailto:sage [2016/11/22(火) 15:45:01.21 ID:RWgWe0KR.net] >>175 int space = 4; sscanf(buffer, "%*s", space, "t") 180 名前：デフォルトの名無しさん mailto:sage [2016/11/22(火) 15:47:04.45 ID:RWgWe0KR.net] >>175 "t"は編集ミスだから気にしないで *の所にspaceの値が指定される 181 名前：デフォルトの名無しさん mailto:sage [2016/11/22(火) 18:37:11.83 ID:mC9XTyoU.net] ウンコしてくる 182 名前：デフォルトの名無しさん mailto:sage [2016/11/27(日) 05:47:03.44 ID:9mn0D+RY.net] windows8.1 環境下、imm にて ImmSetCompositionString で漢字変換したい文字列を設定し、 ImmNotifyIME で CPS_CONVERT、NI_OPENCANDIDATE を投げて 変換候補リストを表示したいのですが、MS-IME 系では問題なく使えていますが、 GoogleIME では変換候補リストが表示されません。 変換したい文字列が入力された状態にはなっていますが、変換候補リストが表示されない だけでなく、キーボードで変換キーを押しても変換自体ができません。 （GoogleIME ではキー入力でただちに予測変換一覧が表示される仕組みだからか？） これを実現するには、imm ではなく tsf に移行するしかないのでしょうか？ imm を使わず keybd_event でキー入力をエミュレートすればある程度実現できたのですが、 （文字入力→変換キー→変換候補一覧表示） 変換候補一覧を表示するための変換キーを押す回数が、MS-IME と GoogleIME では異なる のが困ります。 ImmGetDescription で動作を切り分けることも考えましたが、そもそも ImmGetDescription が 廃止されてしまってこの手が使えません。 183 名前：デフォルトの名無しさん mailto:sage [2016/11/27(日) 16:59:16.60 ID:CC34oqbC.net] Watashi no Namae wa Nakano desu 184 名前：デフォルトの名無しさん mailto:sage [2016/11/27(日) 19:36:59.90 ID:iFUA1Ofz.net] Watashi ni Namae wa Nakattano desu 185 名前：デフォルトの名無しさん [2016/11/28(月) 15:21:52.39 ID:msYXnjQ5.net] 情報通信業の残業やばす https://www.youtube.com/watch?v=TnZEDQchkJk 186 名前：デフォルトの名無しさん [2016/11/29(火) 12:19:49.33 ID:ITJWJL4i.net] 分かる方、教えて下さい。 プログラムの処理時間を計っているのですが、 GetThreadTimes()で取得した時間をもとに計算した処理時間（ＣＰＵ時間）が timeGetTime()で取得した時間をもとに計算した処理時間（実時間）より長くなりました。 スレッドが複数のコアを同時に使うことはないので こういうことは起こらないはずだと思うのですが、 どういう場合に起こるのでしょうか。 なお、1/16秒くらいの精度しかないことは、認識しています。 その上でループを何度も回して十分な時間動作させた上で、 前者が後者の２倍くらいになってしまうのです。 187 名前：デフォルトの名無しさん mailto:sage [2016/11/29(火) 12:57:55.07 ID:NaRikWXT.net] GetThreadTimesで計算したのは処理時間でなくスレッド生成オーバーヘッドとかも含んでるからとか？ 188 名前：185 [2016/11/29(火) 13:40:47.29 ID:ITJWJL4i.net] >>186 そうでもないです。 スレッド生成終了は含まない部分を計っています。 チェックポイントで各関数で時刻を取り、差を計算して、 チェックポイント間にかかった時間を出しています。 >>185 1/16は1/64の誤りです。 189 名前：デフォルトの名無しさん mailto:sage [2016/11/29(火) 13:46:46.72 ID:W5POPsuB.net] >>185 思いつくのはこのあたり ・単位は合っているか。GetThreadTimes()は１００ナノ秒単位、timeGetTime()は1ミリ秒単位 ・GetThreadTimes()の計算方法は、作成時刻から終了時刻までの差なのか、カーネル・ユーザモードの実行時間の合計なのか ・timeGetTime()はいつどのタイミング、またどの場所で呼び出しているのか ・timeGetTime()が計測スレッド内部で実行されているなら GetThreadTimes()の“作成時刻”からtimeGetTime()が実行されるまでの時間が含まれていない ・timeGetTime()が計測スレッド内部で実行されているなら 終了時のtimeGetTime()の呼び出しからGetThreadTimes()の“終了時刻”までの時間が含まれていない ・カーネル・ユーザモードの合計なら他のスレッドの“実行時間”が含まれていない 190 名前：デフォルトの名無しさん mailto:sage [2016/11/29(火) 14:01:14.55 ID:W5POPsuB.net] >>187 GetThreadTimes()がtimeGetTime()の２倍なんでしょ？ ただ２倍と言っても１ミリ秒が２ミリ秒になったってのと１分が２分になったというのではかなり違う 平均して何ミリ秒が何ミリ秒になったの？ timeGetTime()　チェックポイントA スレッド作成　　ポイントα timeGetTime()　チェックポイントB いろいろ実行 timeGetTime()　チェックポイントC スレッド終了　　ポイントβ timeGetTime()　チェックポイントD GetThreadTimes()はαやβの時刻であって、timeGetTime()でA〜Dのいずれかで計測しても誤差は生じる。 「スレッドが複数のコアを〜」からすると計測スレッドでチェックポイントを設けているように見受けられるので B、C間とするとαからBまでの差が含まれていないと思うけど。 ポイントαの時刻って言うのも「スレッドの作成を開始した時刻」なのか「スレッドの作成が完了した時刻」なのかでも誤差は生じる。 191 名前：185 [2016/11/29(火) 14:28:28.52 ID:ITJWJL4i.net] >>188 ・timeGetTime()とGetThreadTimes()の単位の違いは認識しています。 ・GetThreadTimes()による時間の計り方ですが、 　CreationTimeとExitTimeは一切使用せず、 　KernelTimeとUserTimeだけを使用して、チェックポイント間の差を取り、 　ユーザーモード時間とカーネルモード時間を個別に出しています。 ・スレッドの開始及び終了は、チェックポイント間に入っていません。 　>>189のイメージでいう所のBとCの間のいろいろ実行の部分だけを計っている感じです。 >>189 ・今動かしてみたら、 　500回ほど回して平均を取った上での数字として、 　B-C間の測定結果が、 　timeGetTime()の場合で9msec 　カーネルモード時間が429usec 　ユーザモード時間が14037usec 　になりました。 　2倍までいってませんが、2倍くらいになることもあります。 ・スレッド生成及び終了の処理部分は計っていません。 192 名前：デフォルトの名無しさん mailto:sage [2016/11/29(火) 15:45:24.23 ID:1SK7brxW.net] GetThreadTimesが必ずしも正確な時間を返さない可能性もある スレッドの切り替えは可能な限り超早業で行う必要があるので 細かな正確な時間など、二の次かもしれない もっと長い時間のかかる処理(10秒とか)を走らせてみて 実時間とスレッド時間を比較してみては？ もしそれで上手くいくのなら、スレッド時間の精度の問題という 可能性が濃厚になる 193 名前：185 [2016/11/29(火) 16:21:45.88 ID:ITJWJL4i.net] >>191 volatile変数をひたすらインクリメントするコードを書いて、 試してみました。 　timeGetTime()で計った時間：10560msec 　カーネルモード時間：280801usec 　ユーザモード時間：10296066usec 4個のコアを食いつぶさせるために5個同時に動かすと、 　timeGetTime()で計った時間：12sec〜18sec 　カーネルモード時間：343msec〜608msec 　ユーザモード時間：11902msec〜12729msec 1プロセスから2スレッド起動するのもやってみましたが、 　timeGetTime()で計った時間：11869msec 　スレッド１ 　　カーネルモード時間：312msec 　　ユーザモード時間：11403msec 　スレッド２ 　　カーネルモード時間：390msec 　　ユーザモード時間：11528msec 　プロセス 　　カーネルモード時間：1092msec 　　ユーザモード時間：22776msec ほぼ期待通り（本来あるべき）の結果となりました。 194 名前：デフォルトの名無しさん mailto:sage [2016/11/29(火) 16:46:40.42 ID:1SK7brxW.net] もう一つの可能性として timeGetTimeの方の精度があまりよくない可能性もある >Windows NT：timeGetTime 関数の既定の精度は、マシンによっては 5 ミリ秒以上になる場合があります。 とMSDNにも書いてあるしな 君が最初に測ろうとしていた処理の時間は >timeGetTime()の場合で9msec であるから、timeGetTime の「デフォルト」の精度の 195 名前：「5ミリ秒以上になる」は無視できない誤差だね [] [ここ壊れてます] 196 名前：185 [2016/11/29(火) 17:48:25.90 ID:ITJWJL4i.net] >>193 十msec規模の誤差がありうることや、 9msecに対して5msecが無視できないことは理解します。 ただ、>>190に書いた9msecは 500回動かして平均を取っ（て整数にまるめ）た数字です。 誤差が毎回毎回プラスあるいはマイナスに偏って出るとは考えにくいので、 スレッドのＣＰＵ時間が実時間の1.5〜2倍になることについては、 誤差以外の原因があるのではないかとかんぐっています。 197 名前：デフォルトの名無しさん mailto:sage [2016/11/29(火) 18:02:52.57 ID:kNMZE4WL.net] >>194 > 誤差が毎回毎回プラスあるいはマイナスに偏って出るとは考えにくいので 誤差が均等にバラつくなんていう保証はないだろ 198 名前：デフォルトの名無しさん mailto:sage [2016/11/29(火) 18:14:13.77 ID:NaRikWXT.net] 時間取得のオーバーヘッドじゃないか？ >>195 誤差の定義てか確率論の考え方を真っ向から否定してるなｗｗ 199 名前：デフォルトの名無しさん mailto:sage [2016/11/29(火) 18:40:14.32 ID:3TFqVZYr.net] いや、、、誤差の平均取るなら複数の環境でやらんと 同じ環境ならプラスばっかりとかマイナスばっかりとかあるべ 200 名前：デフォルトの名無しさん mailto:sage [2016/11/29(火) 19:46:40.98 ID:w2ftYsPy.net] 環境というか仕組み上プラスしかないとかマイナスしかないということもある 201 名前：デフォルトの名無しさん mailto:sage [2016/11/29(火) 19:46:41.38 ID:Ofu9bBqm.net] どちらか言えばDDK（WDK）の領域じゃね 202 名前：185 [2016/11/29(火) 20:53:31.95 ID:ITJWJL4i.net] 新たな発見がありました。 スレッドのＣＰＵ時間が実時間よりだいぶ長くなるコードの時間測定ですが、 該当コードを2回実行するコードと3回実行するコードも計ってみました。 （いずれも500回平均です。） 1回 timeGetTime()による時間：7msec カーネルモード時間：1060usec ユーザモード時間：13540usec 2回 timeGetTime()による時間：14msec カーネルモード時間：2246usec ユーザモード時間：13291usec 3回 timeGetTime()による時間：21msec カーネルモード時間：2527usec ユーザモード時間：19468usec このデータから、 timeGetTime()はかなり正確であり、 GetThreadTimes()が真値より随分大きな値を返していることが強く疑われます。 クロックの誤差は、通常は、クロック更新粒度に起因する誤差であり、 それは一様な分布であるため、平均処理で抑えられます。 しかし、明らかにプラス方向の誤差が生じており、 クロック精度とは別の何らかの原因があるはずなのですが、 現在、原因の特定に至っていません。 203 名前：デフォルトの名無しさん mailto:sage [2016/11/30(水) 00:10:42.24 ID:V/PBKRN8.net] >>200 「クロック更新粒度」がいわゆるtickのことなら常に一方向に偏るはず。 timeGetTimeはtick単位の値を返すから、より正確な値を返すGetThreadTimesより 短い時間を返す、ということじゃないの？ 204 名前：デフォルトの名無しさん mailto:sage [2016/11/30(水) 00:21:37.30 ID:tnQQtKaj.net] いや 開始タイムが実際の時間より小さければ、測定タイムは増えるし 終了タイムが実際の時間より小さければ、測定タイムは減るので ・・・ 何が言いたいのか自分でもよくわからなくなったが 同じ方向へ偏っても、end - begin で計算するから 符号は反対だから打ち消しあうといいますか 複数回測定して平均をとれば均一になるという彼の意見も一理あるかと ただ、なぜ、timeBeginPeriod しないのかは謎だけど、いや、しているのかもしれんが 205 名前：デフォルトの名無しさん mailto:sage [2016/11/30(水) 00:52:07.64 ID:ZP8Eu14+.net] 単純に時間取ってくる関数とスレッドのアクセス権取ってきたりしなきゃ関数とで比べたら後者の方が時間かかるよ 1度の実行でmsec変わるなら別に原因あるだろうが 206 名前：デフォルトの名無しさん [2016/11/30(水) 02:17:24.90 ID:WhaKofQb.net] 馬鹿発見 207 名前：デフォルトの名無しさん [2016/11/30(水) 03:54:14.51 ID:tfyAgmME.net] おいおい 話逸れすぎていて草 208 名前：185 [2016/11/30(水) 16:27:00.78 ID:NmhabroG.net] >>200の2回実行するケースについて 1回目と2回目に分けて測定しました。 すなわち、 　timeGetTime(); GetThreadTimes(); 　時間測定対象コード　Ａ 　timeGetTime(); GetThreadTimes(); 　時間測定対象コード　Ｂ 　timeGetTime(); GetThreadTimes(); とし、500回の平均で計測しました。 ＡとＢは全く同じコードです。 下記結果となりました。 Ａ timeGetTime()による時間：8msec カーネルモード時間：343usec ユーザモード時間：14664usec Ｂ timeGetTime()による時間：7msec カーネルモード時間：93usec ユーザモード時間：904usec スレッドＣＰＵ時間において、 ＡがＢより圧倒的に長くなりました。 なぜこのようなことが起こるのか分かりません。 どのような可能性があるでしょうか。 なお、>>200で触れましたが、 timeGetTime()は比較的正確です。 209 名前：デフォルトの名無しさん mailto:sage [2016/11/30(水) 18:01:03.98 ID:3E8a/W4X.net] まあ当然の結果だな 210 名前：185 [2016/11/30(水) 18:01:22.28 ID:NmhabroG.net] ああ、もう時間がない。 今日までにＣＰＵ時間測定結果を報告しないといけないので。 GetThreadTimes()は信用できないという前提のもと、 timeGetTime()の結果も参考に、 推測されるおおよそのＣＰＵ時間ってことで報告するしかなさそうです。 皆さんありがとうございました。 211 名前：185 [2016/11/30(水) 18:02:13.44 ID:NmhabroG.net] >>207 おっと！ なぜ当然の結果なのですか。 教えて下さい。 212 名前：デフォルトの名無しさん mailto:sage [2016/11/30(水) 18:03:45.74 ID:3E8a/W4X.net] ゲームスレで聞いてみ 213 名前：185 [2016/11/30(水) 18:15:54.33 ID:NmhabroG.net] >>210 そうですか。教えてくれないなら結構です。 214 名前：185 [2016/11/30(水) 19:24:20.97 ID:NmhabroG.net] >>200に示したように、1回だけ実行すると、 実時間7msec、スレッドＣＰＵ時間14msecという不整合が起きます。 ところが10回実行して計ると、 実時間78msec、スレッドＣＰＵ時間80msecとなります。 これでも不整合はあるものの、 実時間≒スレッドＣＰＵ時間であることから、 1回の場合でも実時間≒スレッドＣＰＵ時間であることが想定される。 また実時間の方がより信頼できることが分かっている。 したがって、1回実行時のスレッドＣＰＵ時間は7.8msec程度であろう。 このようなスレッドＣＰＵ時間の見積もり方で妥当でしょうか。 215 名前：デフォルトの名無しさん [2016/11/30(水) 20:49:07.15 ID:5wEUj1of.net] >>212 GetThreadTimesの精度は15.6msなので、ある程度時間のかかる処理でないと 意味が無い。7msの処理をはかると0か15になるかのどちらか。 数百回の平均をとるのではなく1回だけ測定してみると意味ないのがわかる。 216 名前：デフォルトの名無しさん [2016/11/30(水) 20:49:57.04 ID:o1dhiyLy.net] . . ■■人間性に批判殺到　あの悪質パクツイ垢　@copy__writing の管理人は東京都三鷹市の莉里子■■ i.imgur.com/5qAgsHG.png i.imgur.com/kldi84l.png i.imgur.com/8vCymiC.jpg ■今までのプライベート垢 @riricoco0 @bibliophilia333 @muzimuzi333 @nekomatagensou @hanasoraumimori @mirainosekai3 @zibanyan666 @parlorchild @liliririko @EriotN @mike_peko @riricoco0 @ririko_neko @nyanpas ※1 @telegraphyneko ・ ・ @riricatputi (新アカ)　　imgur.com/a/X1vQA 100垢以上作ってるキチガイ出会い厨　（粘着やめろ詐欺師！はやく捕まれホラ吹きネットストーカー犯罪者！！） 217 名前：185 [2016/11/30(水) 22:05:18.43 ID:b9TNuS14.net] >>212の方法でスレッドＣＰＵ時間を見積もって報告し、帰宅しました。 ID変わります。 >>213 クロック更新粒度に基づく精度のことは認識しています（>>185、>>187）。 500回の平均を取ることでその問題を回避し、 その上で>>200、>>206の結果になります。 >>206のデータは、 1回目で実時間を大きく上回るＣＰＵ時間が記録されており、 2回目で殆どＣＰＵ時間が経過していないことを表しています。 GetThreadTimes()で取得したクロックは、どうしてこのようになってしまうのか。 それが分からないんです。 どういう場合にこうなり得るのか、御存 218 名前：知の方は教えて下さい。 [] [ここ壊れてます] 219 名前：デフォルトの名無しさん [2016/11/30(水) 23:20:53.03 ID:EvMIugyq.net] 1回目はいろいろオーバーヘッドあるよね 220 名前：185 [2016/11/30(水) 23:52:18.25 ID:b9TNuS14.net] >>216 ですと、実時間を超えるＣＰＵ時間になり得ると？ プロセスＣＰＵ時間ではなくスレッドＣＰＵ時間で。 同じ処理なのに2回目が1回目の6％のＣＰＵ時間で妥当だと？ メモリアクセスのキャッシュヒット率に違いがあるとか そういうことであれば分かります。 でも、ＣＰＵ時間ですよ。 ＣＰＵ時間で圧倒的に2回目が有利でしょうか？ だとしても、 実時間の2倍近いスレッドＣＰＵ時間って何なのでしょうか？ 不思議だらけで、困惑しております。 221 名前：デフォルトの名無しさん mailto:sage [2016/11/30(水) 23:54:22.80 ID:R/TXkRDp.net] >>217 先ずその測定方法では誤差が偏り問題を回避できなかったという事実を認めろ 500回繰り替えして全体の時間を500で割るなら誤差を縮小出来るが 一回分の時間を積み上げたところで誤差も同じように積み上がったということだろ 一回分の時間を積算して精度の問題を解消するには測定開始時刻が tick周期に対して完全に自由でなければならないのでは？ どんな測定方法をしたのか分からないけどプログラムの起動やスレッド生成や スケジューリングのスイッチなどがtickと相関関係にあれば破綻する方法だったんだろ 222 名前：デフォルトの名無しさん [2016/11/30(水) 23:55:15.34 ID:nOqMl3Nb.net] >>215 GetThreadTimesが切り捨てなのか切り上げなのか、平均をとればうまい具合になるのか あなたの環境で要確認。 206-Aは精度的にあり得るが、Bは異様に少なすぎるので、測定ミスを疑われるレベルですね。 コードを見ないとなんとも言えないですが、対象部分を適当な計算をするループに 変えても起こるんでしょうか？ 223 名前：デフォルトの名無しさん mailto:sage [2016/12/01(木) 00:37:40.42 ID:cvCPUZP4.net] みんな憶測で偉そうに話すしかできないんだから、再現コード上げたらいいだけやん 224 名前：デフォルトの名無しさん [2016/12/01(木) 00:49:48.35 ID:O5qZU2qd.net] GetThreadTimes,つまりスレッドを作っているんだろ 1回目と2回目以降で違って当然じゃねぇ？ 225 名前：デフォルトの名無しさん [2016/12/01(木) 00:54:41.76 ID:O5qZU2qd.net] クロックカウンタ使えよ 226 名前：デフォルトの名無しさん mailto:sage [2016/12/01(木) 02:56:36.59 ID:wMlr02vN.net] CPUがいくら速くても切り替えは60Hzくらい 227 名前：デフォルトの名無しさん [2016/12/01(木) 04:56:48.70 ID:O5qZU2qd.net] スタック生成だけ考えても1回目と2回目以降で違ってくると思う 228 名前：185 [2016/12/01(木) 11:21:31.25 ID:SFr2s2fw.net] >>218 第一段落はやり方が悪いというご批判だと思いますが、 ティックが粗いことによる誤差は平均で軽減しました。 その上で誤差が起こっています。 ティックが粗いこと以外の理由で誤差が起こっています。 その理由を知りたく、知恵を拝借したいのです。 間違っていないと思います。 第二段落第一文は、おっしゃる通りです。 第二段落第二文は、思いつきのご発言でしょうか、 それとも知識や経験に基づく助言でしょうか。 後者であれば、もうちょっと詳しくお願いします。 >>206のようなコードで起こりうるでしょうか。 229 名前：185 [2016/12/01(木) 11:39:04.09 ID:SFr2s2fw.net] >>220 職業プログラマなので実際のコードを公開することはできませんが、大よそ以下のようなものです。 ========ここから======== tRealA=0; tRealB=0; tUserA=0; tUserB=0; for (int i=0; i<500; ++i){ いろいろ tReal1=timeGetTime(); GetThreadTimes(...,&tUser1); func(...); //A tReal2=timeGetTime(); GetThreadTimes(...,&tUser2); func(...); //B tReal3=timeGetTime(); GetThreadTimes(...,&tUser3); いろいろ tRealA += tReal2-tReal1; tRealB += tReal3-tReal2; tUserA += tUser2-tUser1; tUserB += tUser3-tUser2; } tRealA/=500; tRealB/=500; tUserA/=500; tUserB/=500; ========ここまで======== >>219 func()がvolatile intをひたすらインクリメントするコードの場合は、期待通りの結果>>192がでます。しかし、func()を目的のコード（他者製ライブラリの関数）にすると、不自然な結果>>206になります。 >>216、>>224 AとBで何がそんなに変わるでしょうか。 230 名前：デフォルトの名無しさん mailto:sage [2016/12/01(木) 11:55:52.25 ID:lOA8D/0g.net] 最適化切ったら 231 名前：デフォルトの名無しさん [2016/12/01(木) 12:02:28.97 ID:5zfWITAP.net] 木屋さん元気かな 事故ったのは知ってるけど どのくらいご回復されたかな 232 名前：デフォルトの名無しさん mailto:sage [2016/12/01(木) 12:14:25.23 ID:i7gsdi/t.net] >>225 > 第二段落第一文は、おっしゃる通りです。 > 第二段落第二文は、思いつきのご発言でしょうか、 思いつきと言われればその通りだが、確からしい事（あなたの測定結果） から推測された事（第二段落第一文の条件が満たされていない）です >>226 > func()がvolatile intをひたすらインクリメントするコードの場合は、期待通りの結果>>192がでます。しかし、func()を目的のコード（他者製ライブラリの関数）にすると、不自然な結果>>206になります。 それはfunc()の一回の時間が桁違いだから誤差に埋もれるか埋もれないかが変わっただけだろ 233 名前：185 [2016/12/01(木) 13:04:50.94 ID:SFr2s2fw.net] >>227 コンパイラの最適化のことですよね。 コンパイラの最適化を無効にして、やってみました。 A timeGetTime()による時間：7msec カーネルモード時間：499usec ユーザモード時間：14882usec B timeGetTime()による時間：7msec カーネルモード時間：31usec ユーザモード時間：124usec 同じ傾向になりました。 234 名前：デフォルトの名無しさん [2016/12/01(木) 13:30:33.53 ID:O5qZU2qd.net] >>226 > >>216、>>224 > AとBで何がそんなに変わるでしょうか。 スタックは初期化されてアプリに引き渡すだろ スタックの中で使われずに解放されたページは論理アドレスでは解放状態でも OSがリザーブしておけば新たなスレッド生成で使い回しできるじゃないかな 他にもスタック以外でページの最初に書き込み時点でページをコピーするとかあるよね 235 名前：デフォルトの名無しさん [2016/12/01(木) 13:34:44.58 ID:RgG4Eqmg.net] >>226 いろいろ のところでライブラリの初期化とかやってない？ １回目はデータ構築処理があるのでCPUタイムを食うが、２回目は不要なのでCPUタイムを食わないとか。 で、DBとかサーバーへの問い合わせがあるので、7msくらいはかかってしまうなんてことは無いのか。 あるいは、２回目はfuncの中で別スレッドを起動して計算しているので、元スレッドのCPUタイムは食わないとか。 A B だけでなく A B C D と４回くらいやっても同じ傾向か、平均でなくすべてのタイムを見て 極端にばらつく値がないか調べるとかも必要では？ 236 名前：デフォルトの名無しさん mailto:sage [2016/12/01(木) 22:49:24.47 ID:/t7qmsTu.net] >>226 後だし感すごいな。 他者製ライブラリとやらの中身も分からず議論になるかってーの。 237 名前：デフォルトの名無しさん mailto:sage [2016/12/02(金) 08:27:00.87 ID:GvPbDV6s.net] どこがWin32APIの話なんだよ、ってことになるよなあ。 長々と議論に付き合ってた方々、お疲れ様。 238 名前：デフォルトの名無しさん mailto:sage [2016/12/02(金) 09:07:26.76 ID:0vMtCyDD.net] 粒度の平均化してるとか言って全く出来てないし 精度の悪い数字を正しいと断定してるし しかも間違ってる 何度も指摘してるのに正そうとしない 全部ダメでしょ。 239 名前：デフォルトの名無しさん mailto:sage [2016/12/02(金) 09:21:55.13 ID:+ocxhyeH.net] >>211みたいな事言ってるからお察し 240 名前：185 [2016/12/02(金) 10:43:58.72 ID:H1x5ETqP.net] 報告書は突っ返されたので、まだまだ続きそうです。 まず、大大大前提を確認したいのですが、 GetThreadTimes()で取得するＣＰＵ時間は スレッドがＣＰＵをとっている時間で、 一つのスレッドが同時に複数のコアを占有することはないので、 （精度云々ではなく定義上は）スレッドのＣＰＵ時間は実時間以下である（以下のペースで進む）。 これは、大前提としてあってますよね？ 241 名前：デフォルトの名無しさん mailto:sage [2016/12/02(金) 10:47:04.34 ID:rEQGNTwO.net] なんだ学校の課題だったのか 242 名前：デフォルトの名無しさん mailto:sage [2016/12/02(金) 11:24:10.48 ID:EDk65fqO.net] 質問者より賢い人はいないのか？ これでは、質問箱が成り立たないなｗ 243 名前：デフォルトの名無しさん mailto:sage [2016/12/02(金) 11:27:08.99 ID:+ocxhyeH.net] >>239 そうだな じゃあ頼んだ 244 名前：デフォルトの名無しさん mailto:sage [2016/12/02(金) 11:48:56.99 ID:2Jj/uLxs.net] だから再現できるサンプルをサクッと上げろよ。 だれも実物や社外ライブラリまで上げろといってないんだわ。 コーディングやデバッグ能力以外の能力が大きく欠如してるだろ。 245 名前：185 [2016/12/02(金) 11:58:27.27 ID:H1x5ETqP.net] 10回やってみました。 つまり、>>226のコードでAとBだけでなく、AからJまでやってみました。 A timeGetTime()による時間：7msec カーネルモード時間：1092usec ユーザモード時間：14133usec B timeGetTime()による時間：7msec カーネルモード時間：249usec ユーザモード時間：343usec C timeGetTime()による時間：7msec カーネルモード時間：936usec ユーザモード時間：9141usec D timeGetTime()による時間：7msec カーネルモード時間：1372usec ユーザモード時間：4180usec E timeGetTime()による時間：7msec カーネルモード時間：561usec ユーザモード時間：6583usec F timeGetTime()による時間：7msec カーネルモード時間：717usec ユーザモード時間：7737usec G timeGetTime()による時間：7msec カーネルモード時間：468usec ユーザモード時間：4773usec 246 名前：185 [2016/12/02(金) 11:58:51.26 ID:H1x5ETqP.net] H timeGetTime()による時間：7msec カーネルモード時間：655usec ユーザモード時間：9672usec I timeGetTime()による時間：7msec カーネルモード時間：218usec ユーザモード時間：4149usec J timeGetTime()による時間：7msec カーネルモード時間：405usec ユーザモード時間：10795usec 全体（A〜J） timeGetTime()による時間：74msec カーネルモード時間：6645usec ユーザモード時間：71510usec 247 名前：デフォルトの名無しさん mailto:sage [2016/12/02(金) 12:10:39.48 ID:fHtgnGrJ.net] 仕事が出来ないから、タダで手取り足取り協力してくれってか 248 名前：185 [2016/12/02(金) 13:02:57.14 ID:H1x5ETqP.net] 本件、私としては以下の結論に至りました。 ○timeGetTime()は信頼できる。 ○GetThreadTime()は信用できない 　（ティック間切り上げ的な傾向あり。理由不明。）。 ○timeGetTime()を基準に>>212のような方法をとるほかない。 もう一度GetThreadTime()はどうしても信用ならず、 他に有用な代替手段もないため、 >>212の方法が限界である旨を報告することにします。 何人かの真剣に助言して下さった方々、 本当にありがとうございました。 249 名前：デフォルトの名無しさん mailto:sage [2016/12/02(金) 13:27:24.15 ID:bjzW9gj9.net] >>228 ドラスレの木屋さんも、timeGetTimeのこと調べてたな 250 名前：デフォルトの名無しさん [2016/12/02(金) 14:04:58.11 ID:ELslSS33.net] timeGetTimeやめてQueryPerformanceCounterを使ったら？ 251 名前：デフォルトの名無しさん mailto:sage [2016/12/02(金) 14:15:28.80 ID:ocojT6FV.net] 内容のアホさからして オバケじゃないことは確実 252 名前：デフォルトの名無しさん mailto:sage [2016/12/02(金) 14:17:49.26 ID:6Vgvdyao.net] あらかじめtimeBeginPeriodも呼んでおかないと精度変わる

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef