Win32API質問箱 Build123©2ch.net

**デフォルトの名無しさん転載ダメ©2ch.net** · 2016/10/08(土) 12:33:02.29

Win32APIについての質問はこちらへどうぞ。

■注意
・質問する前にMSDNライブラリやPlatformSDK、Google等で検索しましょう。
・日本語版MSDN Online Libraryは不完全です。
　英語版( http://msdn.microsoft.com/en-us/library/ )の利用推奨。
・APIフックなど高度な事をしたい場合はできるだけAdvenced Windowsを読みましょう。
・言語特有の問題やIDE、MFCやVCLなどの質問はそれぞれの言語や開発環境スレで

■過去スレ
Win32API質問箱 Build122
http://echo.2ch.net/test/read.cgi/tech/1451988219/

**デフォルトの名無しさん** · 2016/11/19(土) 12:52:23.68

> MF_DISABLEDとMF_GRAYEDが違ったのはWindows3.1とかの時代で今は同じ
7で非エアロ + 視覚効果を無効にした場合はどちらになりますか

**164** · 2016/11/19(土) 22:31:46.85

>>165
なるほど、そういうことだったんですか。
ありがとうございます。

**デフォルトの名無しさん** · 2016/11/20(日) 10:34:28.02

Windows3.1 って標準で１画面に16色しか使えなかった時代の名残だから忘れていい

**デフォルトの名無しさん** · 2016/11/20(日) 10:50:09.74

3.1のときには256や6万色普通にあったろ

**デフォルトの名無しさん** · 2016/11/20(日) 12:16:32.29

16bit と間違ったんじゃね

**デフォルトの名無しさん** · 2016/11/20(日) 12:20:21.09

PC-9801の話だと思った。

**デフォルトの名無しさん** · 2016/11/20(日) 16:35:07.06

PCG

**デフォルトの名無しさん** · 2016/11/21(月) 11:15:47.37

ビデオカード次第だったよな

**デフォルトの名無しさん** · 2016/11/21(月) 12:21:40.28

PSG

**デフォルトの名無しさん** · 2016/11/22(火) 15:36:11.99

sscanf(buffer, "%4s", &data)の4の部分に変数を使いたい場合ってどうしたらいいんでしょう？

**デフォルトの名無しさん** · 2016/11/22(火) 15:42:16.93

"%4s"をsprintfで作る

**片山博文MZ** ◆T6xkBnTXz7B0 · 2016/11/22(火) 15:44:33.07

"%*s"

**デフォルトの名無しさん** · 2016/11/22(火) 15:45:01.21

>>175
int space = 4;
sscanf(buffer, "%*s", space, "t")

**デフォルトの名無しさん** · 2016/11/22(火) 15:47:04.45

>>175
"t"は編集ミスだから気にしないで
*の所にspaceの値が指定される

**デフォルトの名無しさん** · 2016/11/22(火) 18:37:11.83

ウンコしてくる

**デフォルトの名無しさん** · 2016/11/27(日) 05:47:03.44

windows8.1 環境下、imm にて ImmSetCompositionString で漢字変換したい文字列を設定し、
ImmNotifyIME で CPS_CONVERT、NI_OPENCANDIDATE を投げて
変換候補リストを表示したいのですが、MS-IME 系では問題なく使えていますが、
GoogleIME では変換候補リストが表示されません。

変換したい文字列が入力された状態にはなっていますが、変換候補リストが表示されない
だけでなく、キーボードで変換キーを押しても変換自体ができません。
（GoogleIME ではキー入力でただちに予測変換一覧が表示される仕組みだからか？）

これを実現するには、imm ではなく tsf に移行するしかないのでしょうか？

imm を使わず keybd_event でキー入力をエミュレートすればある程度実現できたのですが、
（文字入力→変換キー→変換候補一覧表示）
変換候補一覧を表示するための変換キーを押す回数が、MS-IME と GoogleIME では異なる
のが困ります。

ImmGetDescription で動作を切り分けることも考えましたが、そもそも ImmGetDescription が
廃止されてしまってこの手が使えません。

**デフォルトの名無しさん** · 2016/11/27(日) 16:59:16.60

Watashi no Namae wa Nakano desu

**デフォルトの名無しさん** · 2016/11/27(日) 19:36:59.90

Watashi ni Namae wa Nakattano desu

**デフォルトの名無しさん** · 2016/11/28(月) 15:21:52.39

情報通信業の残業やばす
https://www.youtube.com/watch?v=TnZEDQchkJk

**デフォルトの名無しさん** · 2016/11/29(火) 12:19:49.33

分かる方、教えて下さい。

プログラムの処理時間を計っているのですが、
GetThreadTimes()で取得した時間をもとに計算した処理時間（ＣＰＵ時間）が
timeGetTime()で取得した時間をもとに計算した処理時間（実時間）より長くなりました。
スレッドが複数のコアを同時に使うことはないので
こういうことは起こらないはずだと思うのですが、
どういう場合に起こるのでしょうか。

なお、1/16秒くらいの精度しかないことは、認識しています。
その上でループを何度も回して十分な時間動作させた上で、
前者が後者の２倍くらいになってしまうのです。

**デフォルトの名無しさん** · 2016/11/29(火) 12:57:55.07

GetThreadTimesで計算したのは処理時間でなくスレッド生成オーバーヘッドとかも含んでるからとか？

**185** · 2016/11/29(火) 13:40:47.29

>>186
そうでもないです。
スレッド生成終了は含まない部分を計っています。
チェックポイントで各関数で時刻を取り、差を計算して、
チェックポイント間にかかった時間を出しています。

>>185
1/16は1/64の誤りです。

**デフォルトの名無しさん** · 2016/11/29(火) 13:46:46.72

>>185
思いつくのはこのあたり
・単位は合っているか。GetThreadTimes()は１００ナノ秒単位、timeGetTime()は1ミリ秒単位
・GetThreadTimes()の計算方法は、作成時刻から終了時刻までの差なのか、カーネル・ユーザモードの実行時間の合計なのか
・timeGetTime()はいつどのタイミング、またどの場所で呼び出しているのか
・timeGetTime()が計測スレッド内部で実行されているなら
GetThreadTimes()の“作成時刻”からtimeGetTime()が実行されるまでの時間が含まれていない
・timeGetTime()が計測スレッド内部で実行されているなら
終了時のtimeGetTime()の呼び出しからGetThreadTimes()の“終了時刻”までの時間が含まれていない
・カーネル・ユーザモードの合計なら他のスレッドの“実行時間”が含まれていない

**デフォルトの名無しさん** · 2016/11/29(火) 14:01:14.55

>>187
GetThreadTimes()がtimeGetTime()の２倍なんでしょ？
ただ２倍と言っても１ミリ秒が２ミリ秒になったってのと１分が２分になったというのではかなり違う
平均して何ミリ秒が何ミリ秒になったの？

timeGetTime()　チェックポイントA
スレッド作成　　ポイントα
timeGetTime()　チェックポイントB
いろいろ実行
timeGetTime()　チェックポイントC
スレッド終了　　ポイントβ
timeGetTime()　チェックポイントD

GetThreadTimes()はαやβの時刻であって、timeGetTime()でA～Dのいずれかで計測しても誤差は生じる。
「スレッドが複数のコアを～」からすると計測スレッドでチェックポイントを設けているように見受けられるので
B、C間とするとαからBまでの差が含まれていないと思うけど。
ポイントαの時刻って言うのも「スレッドの作成を開始した時刻」なのか「スレッドの作成が完了した時刻」なのかでも誤差は生じる。

**185** · 2016/11/29(火) 14:28:28.52

>>188
・timeGetTime()とGetThreadTimes()の単位の違いは認識しています。
・GetThreadTimes()による時間の計り方ですが、
　CreationTimeとExitTimeは一切使用せず、
　KernelTimeとUserTimeだけを使用して、チェックポイント間の差を取り、
　ユーザーモード時間とカーネルモード時間を個別に出しています。
・スレッドの開始及び終了は、チェックポイント間に入っていません。
　>>189のイメージでいう所のBとCの間のいろいろ実行の部分だけを計っている感じです。

>>189
・今動かしてみたら、
　500回ほど回して平均を取った上での数字として、
　B-C間の測定結果が、
　timeGetTime()の場合で9msec
　カーネルモード時間が429usec
　ユーザモード時間が14037usec
　になりました。
　2倍までいってませんが、2倍くらいになることもあります。
・スレッド生成及び終了の処理部分は計っていません。

**デフォルトの名無しさん** · 2016/11/29(火) 15:45:24.23

GetThreadTimesが必ずしも正確な時間を返さない可能性もある
スレッドの切り替えは可能な限り超早業で行う必要があるので
細かな正確な時間など、二の次かもしれない

もっと長い時間のかかる処理(10秒とか)を走らせてみて
実時間とスレッド時間を比較してみては？
もしそれで上手くいくのなら、スレッド時間の精度の問題という
可能性が濃厚になる

**185** · 2016/11/29(火) 16:21:45.88

>>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

ほぼ期待通り（本来あるべき）の結果となりました。

**デフォルトの名無しさん** · 2016/11/29(火) 16:46:40.42

もう一つの可能性として
timeGetTimeの方の精度があまりよくない可能性もある
>Windows NT：timeGetTime 関数の既定の精度は、マシンによっては 5 ミリ秒以上になる場合があります。
とMSDNにも書いてあるしな
君が最初に測ろうとしていた処理の時間は
>timeGetTime()の場合で9msec
であるから、timeGetTime の「デフォルト」の精度の「5ミリ秒以上になる」は無視できない誤差だね

**185** · 2016/11/29(火) 17:48:25.90

>>193
十msec規模の誤差がありうることや、
9msecに対して5msecが無視できないことは理解します。
ただ、>>190に書いた9msecは
500回動かして平均を取っ（て整数にまるめ）た数字です。
誤差が毎回毎回プラスあるいはマイナスに偏って出るとは考えにくいので、
スレッドのＣＰＵ時間が実時間の1.5～2倍になることについては、
誤差以外の原因があるのではないかとかんぐっています。

**デフォルトの名無しさん** · 2016/11/29(火) 18:02:52.57

>>194
> 誤差が毎回毎回プラスあるいはマイナスに偏って出るとは考えにくいので

誤差が均等にバラつくなんていう保証はないだろ

**デフォルトの名無しさん** · 2016/11/29(火) 18:14:13.77

時間取得のオーバーヘッドじゃないか？

>>195
誤差の定義てか確率論の考え方を真っ向から否定してるなｗｗ

**デフォルトの名無しさん** · 2016/11/29(火) 18:40:14.32

いや、、、誤差の平均取るなら複数の環境でやらんと
同じ環境ならプラスばっかりとかマイナスばっかりとかあるべ

**デフォルトの名無しさん** · 2016/11/29(火) 19:46:40.98

環境というか仕組み上プラスしかないとかマイナスしかないということもある

**デフォルトの名無しさん** · 2016/11/29(火) 19:46:41.38

どちらか言えばDDK（WDK）の領域じゃね

**185** · 2016/11/29(火) 20:53:31.95

新たな発見がありました。

スレッドのＣＰＵ時間が実時間よりだいぶ長くなるコードの時間測定ですが、
該当コードを2回実行するコードと3回実行するコードも計ってみました。
（いずれも500回平均です。）

1回
timeGetTime()による時間：7msec
カーネルモード時間：1060usec
ユーザモード時間：13540usec

2回
timeGetTime()による時間：14msec
カーネルモード時間：2246usec
ユーザモード時間：13291usec

3回
timeGetTime()による時間：21msec
カーネルモード時間：2527usec
ユーザモード時間：19468usec

このデータから、
timeGetTime()はかなり正確であり、
GetThreadTimes()が真値より随分大きな値を返していることが強く疑われます。

クロックの誤差は、通常は、クロック更新粒度に起因する誤差であり、
それは一様な分布であるため、平均処理で抑えられます。

しかし、明らかにプラス方向の誤差が生じており、
クロック精度とは別の何らかの原因があるはずなのですが、
現在、原因の特定に至っていません。

**デフォルトの名無しさん** · 2016/11/30(水) 00:10:42.24

>>200
「クロック更新粒度」がいわゆるtickのことなら常に一方向に偏るはず。
timeGetTimeはtick単位の値を返すから、より正確な値を返すGetThreadTimesより
短い時間を返す、ということじゃないの？

**デフォルトの名無しさん** · 2016/11/30(水) 00:21:37.30

いや
開始タイムが実際の時間より小さければ、測定タイムは増えるし
終了タイムが実際の時間より小さければ、測定タイムは減るので
・・・
何が言いたいのか自分でもよくわからなくなったが
同じ方向へ偏っても、end - begin で計算するから
符号は反対だから打ち消しあうといいますか
複数回測定して平均をとれば均一になるという彼の意見も一理あるかと
ただ、なぜ、timeBeginPeriod しないのかは謎だけど、いや、しているのかもしれんが

**デフォルトの名無しさん** · 2016/11/30(水) 00:52:07.64

単純に時間取ってくる関数とスレッドのアクセス権取ってきたりしなきゃ関数とで比べたら後者の方が時間かかるよ
1度の実行でmsec変わるなら別に原因あるだろうが

**デフォルトの名無しさん** · 2016/11/30(水) 02:17:24.90

馬鹿発見

**デフォルトの名無しさん** · 2016/11/30(水) 03:54:14.51

おいおい
話逸れすぎていて草

**185** · 2016/11/30(水) 16:27:00.78

>>200の2回実行するケースについて
1回目と2回目に分けて測定しました。

すなわち、

　timeGetTime(); GetThreadTimes();
　時間測定対象コード　Ａ
　timeGetTime(); GetThreadTimes();
　時間測定対象コード　Ｂ
　timeGetTime(); GetThreadTimes();

とし、500回の平均で計測しました。
ＡとＢは全く同じコードです。

下記結果となりました。

Ａ
timeGetTime()による時間：8msec
カーネルモード時間：343usec
ユーザモード時間：14664usec
Ｂ
timeGetTime()による時間：7msec
カーネルモード時間：93usec
ユーザモード時間：904usec

スレッドＣＰＵ時間において、
ＡがＢより圧倒的に長くなりました。
なぜこのようなことが起こるのか分かりません。
どのような可能性があるでしょうか。

なお、>>200で触れましたが、
timeGetTime()は比較的正確です。

**デフォルトの名無しさん** · 2016/11/30(水) 18:01:03.98

まあ当然の結果だな

**185** · 2016/11/30(水) 18:01:22.28

ああ、もう時間がない。
今日までにＣＰＵ時間測定結果を報告しないといけないので。
GetThreadTimes()は信用できないという前提のもと、
timeGetTime()の結果も参考に、
推測されるおおよそのＣＰＵ時間ってことで報告するしかなさそうです。

皆さんありがとうございました。

**185** · 2016/11/30(水) 18:02:13.44

>>207
おっと！
なぜ当然の結果なのですか。
教えて下さい。

**デフォルトの名無しさん** · 2016/11/30(水) 18:03:45.74

ゲームスレで聞いてみ

**185** · 2016/11/30(水) 18:15:54.33

>>210
そうですか。教えてくれないなら結構です。

**185** · 2016/11/30(水) 19:24:20.97

>>200に示したように、1回だけ実行すると、
実時間7msec、スレッドＣＰＵ時間14msecという不整合が起きます。

ところが10回実行して計ると、
実時間78msec、スレッドＣＰＵ時間80msecとなります。

これでも不整合はあるものの、
実時間≒スレッドＣＰＵ時間であることから、
1回の場合でも実時間≒スレッドＣＰＵ時間であることが想定される。
また実時間の方がより信頼できることが分かっている。
したがって、1回実行時のスレッドＣＰＵ時間は7.8msec程度であろう。

このようなスレッドＣＰＵ時間の見積もり方で妥当でしょうか。

**デフォルトの名無しさん** · 2016/11/30(水) 20:49:07.15

>>212
GetThreadTimesの精度は15.6msなので、ある程度時間のかかる処理でないと
意味が無い。7msの処理をはかると0か15になるかのどちらか。
数百回の平均をとるのではなく1回だけ測定してみると意味ないのがわかる。

**デフォルトの名無しさん** · 2016/11/30(水) 20:49:57.04

.
.
■■人間性に批判殺到　あの悪質パクツイ垢　@copy__writing の管理人は東京都三鷹市の莉里子■■
http://i.imgur.com/5qAgsHG.png
http://i.imgur.com/kldi84l.png
http://i.imgur.com/8vCymiC.jpg

■今までのプライベート垢
@riricoco0
@bibliophilia333
@muzimuzi333
@nekomatagensou
@hanasoraumimori
@mirainosekai3
@zibanyan666
@parlorchild
@liliririko
@EriotN
@mike_peko
@riricoco0
@ririko_neko
@nyanpas ※1
@telegraphyneko
・
・
@riricatputi (新アカ)　　http://imgur.com/a/X1vQA

100垢以上作ってるキチガイ出会い厨　（粘着やめろ詐欺師！はやく捕まれホラ吹きネットストーカー犯罪者！！）

**185** · 2016/11/30(水) 22:05:18.43

>>212の方法でスレッドＣＰＵ時間を見積もって報告し、帰宅しました。
ID変わります。

>>213
クロック更新粒度に基づく精度のことは認識しています（>>185、>>187）。
500回の平均を取ることでその問題を回避し、
その上で>>200、>>206の結果になります。

>>206のデータは、
1回目で実時間を大きく上回るＣＰＵ時間が記録されており、
2回目で殆どＣＰＵ時間が経過していないことを表しています。
GetThreadTimes()で取得したクロックは、どうしてこのようになってしまうのか。
それが分からないんです。

どういう場合にこうなり得るのか、御存知の方は教えて下さい。

**デフォルトの名無しさん** · 2016/11/30(水) 23:20:53.03

1回目はいろいろオーバーヘッドあるよね

**185** · 2016/11/30(水) 23:52:18.25

>>216
ですと、実時間を超えるＣＰＵ時間になり得ると？
プロセスＣＰＵ時間ではなくスレッドＣＰＵ時間で。
同じ処理なのに2回目が1回目の6％のＣＰＵ時間で妥当だと？

メモリアクセスのキャッシュヒット率に違いがあるとか
そういうことであれば分かります。
でも、ＣＰＵ時間ですよ。
ＣＰＵ時間で圧倒的に2回目が有利でしょうか？
だとしても、
実時間の2倍近いスレッドＣＰＵ時間って何なのでしょうか？

不思議だらけで、困惑しております。

**デフォルトの名無しさん** · 2016/11/30(水) 23:54:22.80

>>217
先ずその測定方法では誤差が偏り問題を回避できなかったという事実を認めろ
500回繰り替えして全体の時間を500で割るなら誤差を縮小出来るが
一回分の時間を積み上げたところで誤差も同じように積み上がったということだろ

一回分の時間を積算して精度の問題を解消するには測定開始時刻が
tick周期に対して完全に自由でなければならないのでは？
どんな測定方法をしたのか分からないけどプログラムの起動やスレッド生成や
スケジューリングのスイッチなどがtickと相関関係にあれば破綻する方法だったんだろ

**デフォルトの名無しさん** · 2016/11/30(水) 23:55:15.34

>>215
GetThreadTimesが切り捨てなのか切り上げなのか、平均をとればうまい具合になるのか
あなたの環境で要確認。
206-Aは精度的にあり得るが、Bは異様に少なすぎるので、測定ミスを疑われるレベルですね。
コードを見ないとなんとも言えないですが、対象部分を適当な計算をするループに
変えても起こるんでしょうか？

**デフォルトの名無しさん** · 2016/12/01(木) 00:37:40.42

みんな憶測で偉そうに話すしかできないんだから、再現コード上げたらいいだけやん

**デフォルトの名無しさん** · 2016/12/01(木) 00:49:48.35

GetThreadTimes,つまりスレッドを作っているんだろ
1回目と2回目以降で違って当然じゃねぇ？

**デフォルトの名無しさん** · 2016/12/01(木) 00:54:41.76

クロックカウンタ使えよ

**デフォルトの名無しさん** · 2016/12/01(木) 02:56:36.59

CPUがいくら速くても切り替えは60Hzくらい

**デフォルトの名無しさん** · 2016/12/01(木) 04:56:48.70

スタック生成だけ考えても1回目と2回目以降で違ってくると思う

**185** · 2016/12/01(木) 11:21:31.25

>>218
第一段落はやり方が悪いというご批判だと思いますが、
ティックが粗いことによる誤差は平均で軽減しました。
その上で誤差が起こっています。
ティックが粗いこと以外の理由で誤差が起こっています。
その理由を知りたく、知恵を拝借したいのです。
間違っていないと思います。

第二段落第一文は、おっしゃる通りです。
第二段落第二文は、思いつきのご発言でしょうか、
それとも知識や経験に基づく助言でしょうか。
後者であれば、もうちょっと詳しくお願いします。
>>206のようなコードで起こりうるでしょうか。

**185** · 2016/12/01(木) 11:39:04.09

>>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で何がそんなに変わるでしょうか。

**デフォルトの名無しさん** · 2016/12/01(木) 11:55:52.25

最適化切ったら

**デフォルトの名無しさん** · 2016/12/01(木) 12:02:28.97

木屋さん元気かな
事故ったのは知ってるけど
どのくらいご回復されたかな

**デフォルトの名無しさん** · 2016/12/01(木) 12:14:25.23

>>225
> 第二段落第一文は、おっしゃる通りです。
> 第二段落第二文は、思いつきのご発言でしょうか、

思いつきと言われればその通りだが、確からしい事（あなたの測定結果）
から推測された事（第二段落第一文の条件が満たされていない）です

>>226
> func()がvolatile intをひたすらインクリメントするコードの場合は、期待通りの結果>>192がでます。しかし、func()を目的のコード（他者製ライブラリの関数）にすると、不自然な結果>>206になります。

それはfunc()の一回の時間が桁違いだから誤差に埋もれるか埋もれないかが変わっただけだろ

**185** · 2016/12/01(木) 13:04:50.94

>>227
コンパイラの最適化のことですよね。
コンパイラの最適化を無効にして、やってみました。

A
timeGetTime()による時間：7msec
カーネルモード時間：499usec
ユーザモード時間：14882usec

B
timeGetTime()による時間：7msec
カーネルモード時間：31usec
ユーザモード時間：124usec

同じ傾向になりました。

**デフォルトの名無しさん** · 2016/12/01(木) 13:30:33.53

>>226
> >>216、>>224
> AとBで何がそんなに変わるでしょうか。

スタックは初期化されてアプリに引き渡すだろ
スタックの中で使われずに解放されたページは論理アドレスでは解放状態でも
OSがリザーブしておけば新たなスレッド生成で使い回しできるじゃないかな

他にもスタック以外でページの最初に書き込み時点でページをコピーするとかあるよね

**デフォルトの名無しさん** · 2016/12/01(木) 13:34:44.58

>>226
いろいろのところでライブラリの初期化とかやってない？
１回目はデータ構築処理があるのでCPUタイムを食うが、２回目は不要なのでCPUタイムを食わないとか。
で、DBとかサーバーへの問い合わせがあるので、7msくらいはかかってしまうなんてことは無いのか。

あるいは、２回目はfuncの中で別スレッドを起動して計算しているので、元スレッドのCPUタイムは食わないとか。

A B だけでなく A B C D と４回くらいやっても同じ傾向か、平均でなくすべてのタイムを見て
極端にばらつく値がないか調べるとかも必要では？

**デフォルトの名無しさん** · 2016/12/01(木) 22:49:24.47

>>226
後だし感すごいな。
他者製ライブラリとやらの中身も分からず議論になるかってーの。

**デフォルトの名無しさん** · 2016/12/02(金) 08:27:00.87

どこがWin32APIの話なんだよ、ってことになるよなあ。
長々と議論に付き合ってた方々、お疲れ様。

**デフォルトの名無しさん** · 2016/12/02(金) 09:07:26.76

粒度の平均化してるとか言って全く出来てないし
精度の悪い数字を正しいと断定してるし
しかも間違ってる
何度も指摘してるのに正そうとしない
全部ダメでしょ。

**デフォルトの名無しさん** · 2016/12/02(金) 09:21:55.13

>>211みたいな事言ってるからお察し

**185** · 2016/12/02(金) 10:43:58.72

報告書は突っ返されたので、まだまだ続きそうです。

まず、大大大前提を確認したいのですが、
GetThreadTimes()で取得するＣＰＵ時間は
スレッドがＣＰＵをとっている時間で、
一つのスレッドが同時に複数のコアを占有することはないので、
（精度云々ではなく定義上は）スレッドのＣＰＵ時間は実時間以下である（以下のペースで進む）。

これは、大前提としてあってますよね？

**デフォルトの名無しさん** · 2016/12/02(金) 10:47:04.34

なんだ学校の課題だったのか

**デフォルトの名無しさん** · 2016/12/02(金) 11:24:10.48

質問者より賢い人はいないのか？
これでは、質問箱が成り立たないなｗ

**デフォルトの名無しさん** · 2016/12/02(金) 11:27:08.99

>>239
そうだな
じゃあ頼んだ

**デフォルトの名無しさん** · 2016/12/02(金) 11:48:56.99

だから再現できるサンプルをサクッと上げろよ。
だれも実物や社外ライブラリまで上げろといってないんだわ。
コーディングやデバッグ能力以外の能力が大きく欠如してるだろ。

**185** · 2016/12/02(金) 11:58:27.27

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

**185** · 2016/12/02(金) 11:58:51.26

H
timeGetTime()による時間：7msec
カーネルモード時間：655usec
ユーザモード時間：9672usec
I
timeGetTime()による時間：7msec
カーネルモード時間：218usec
ユーザモード時間：4149usec
J
timeGetTime()による時間：7msec
カーネルモード時間：405usec
ユーザモード時間：10795usec
全体（A～J）
timeGetTime()による時間：74msec
カーネルモード時間：6645usec
ユーザモード時間：71510usec

**デフォルトの名無しさん** · 2016/12/02(金) 12:10:39.48

仕事が出来ないから、タダで手取り足取り協力してくれってか

**185** · 2016/12/02(金) 13:02:57.14

本件、私としては以下の結論に至りました。

○timeGetTime()は信頼できる。
○GetThreadTime()は信用できない
　（ティック間切り上げ的な傾向あり。理由不明。）。
○timeGetTime()を基準に>>212のような方法をとるほかない。

もう一度GetThreadTime()はどうしても信用ならず、
他に有用な代替手段もないため、
>>212の方法が限界である旨を報告することにします。

何人かの真剣に助言して下さった方々、
本当にありがとうございました。

**デフォルトの名無しさん** · 2016/12/02(金) 13:27:24.15

>>228
ドラスレの木屋さんも、timeGetTimeのこと調べてたな

**デフォルトの名無しさん** · 2016/12/02(金) 14:04:58.11

timeGetTimeやめてQueryPerformanceCounterを使ったら？

**デフォルトの名無しさん** · 2016/12/02(金) 14:15:28.80

内容のアホさからして
オバケじゃないことは確実

**デフォルトの名無しさん** · 2016/12/02(金) 14:17:49.26

あらかじめtimeBeginPeriodも呼んでおかないと精度変わる

**デフォルトの名無しさん** · 2016/12/02(金) 14:21:54.01

静的領域に書き込みすると、コピーオンライトが発生し、
動的領域を確保すると、最初とおよび足りない時はOSで確保と初期化があると思う
それが１回目が遅い理由な気がする

**デフォルトの名無しさん** · 2016/12/02(金) 14:30:05.73

質問者はアレだが
それはそうと、どうでも良いことをいうのはやめたほうが良いだろう
実時間とスレッド時間が食い違うって話だから
1回目が遅いとかそういう話ではない

**デフォルトの名無しさん** · 2016/12/02(金) 17:49:56.46

結局>>237すら教えてあげなかったんだな。

**デフォルトの名無しさん** · 2016/12/02(金) 18:15:57.54

質問者のアプローチや解釈が正しいのかが分からないのに、憶測で質問者回答者とも上から目線で
やりあってる状況にまず疑問を抱いた方がいい。
そしてそれら以下の書き込みしかできないID:EDk65fqOはクソ中のクソだと認識した方がいい。

**デフォルトの名無しさん** · 2016/12/02(金) 22:19:54.42

最初からGetThreadTimesは約1/64秒の精度しか無いって分かっていたはずなのにね。
平均とっても意味がないってことが改めて分かったことだけが成果か。

**デフォルトの名無しさん** · 2016/12/02(金) 23:51:36.19

>>247とか>>249とか、全然関係ないことじゃん。

**デフォルトの名無しさん** · 2016/12/03(土) 10:51:33.05

OSがどうやってカーネルモードやユーザーモードの時間を計測しているのか想像できないのかねえ
オーバーヘッドが高いやり方は採用できないと分かりそうなもんだが

**デフォルトの名無しさん** · 2016/12/03(土) 11:08:29.93

触発されてGetThreadTimes=NtQueryInformationThread調べたんだけど”スレッド”の中身が興味深かった
質問者糞だから詳細は書かないがｗ

**デフォルトの名無しさん** · 2016/12/03(土) 20:00:37.46

俺もほんとはGetThreadTimesの特性知ってるけど、
質問者が土下座しないと教えてやらねぇｗ

**デフォルトの名無しさん** · 2016/12/03(土) 20:35:28.76

**デフォルトの名無しさん** · 2016/12/03(土) 20:36:25.77

the old new thing

**デフォルトの名無しさん** · 2016/12/04(日) 11:31:12.68

Windows10ってCOMポート番号は最大何番までなんでしょうか？

**デフォルトの名無しさん** · 2016/12/04(日) 11:37:47.55

com1～com256まで

**デフォルトの名無しさん** · 2016/12/04(日) 12:08:20.93

昔、レジストリから認識してるポート名を取得するサンプルあったな。
MSDNだったかな

**デフォルトの名無しさん** · 2016/12/04(日) 12:22:02.41

select欲しい

**261** · 2016/12/04(日) 16:50:15.73

>>262
>>263
ありがとうございました！