在Win32中,有没有办法获得一个独特的cpu循环计数或类似的东西,对于多个进程/语言/系统/等是统一的。
我正在创建一些日志文件,但是必须生成多个日志文件,因为我们正在托管.NET运行时,并且我想避免从一个调用到另一个来进行日志记录。因此,我认为我只生成两个文件,将它们组合起来,然后对它们进行排序,以获得涉及跨世界调用的连贯时间线。
但是,每次通话都不会增加GetTickCount,因此不可靠。是否有更好的号码,以便在排序时以正确的顺序接听电话?
编辑:感谢@Greg把我带到QueryPerformanceCounter的轨道,这就是诀窍。
发布于 2019-06-24 13:36:13
这是一篇有趣的文章!说不要使用RDTSC,而是使用QueryPerformanceCounter。
结论:
timeGetTime()
在许多基于Windows的操作系统上使用常规旧定时是不可靠的,因为系统定时器的粒度可能高达10-15毫秒,这意味着timeGetTime()
只能精确到10-15毫秒。[请注意,高粒度发生在基于NT的操作系统上,如Windows NT,2000和XP。Windows 95和98往往具有更好的粒度,大约1-5毫秒。] 但是,如果您timeBeginPeriod(1)
在程序开始时(以及timeEndPeriod(1)
结束时)调用 ,timeGetTime()
通常会精确到1-2毫秒,并将为您提供极其准确的计时信息。Sleep()
表现相似;Sleep()
实际睡眠的时间长度与粒度相同timeGetTime()
,因此在调用timeBeginPeriod(1)
一次之后,Sleep(1)
实际上将睡眠1-2毫秒,Sleep(2)
为2-3,依此类推(而不是以高于10-15毫秒)。 对于更高精度的时序(亚毫秒精度),您可能希望避免使用汇编助记符RDTSC,因为它很难校准 ; 相反,使用QueryPerformanceFrequency
和QueryPerformanceCounter
,精确到小于10微秒(0.00001秒)。 对于简单的时序,timeGetTime和QueryPerformanceCounter都运行良好,而QueryPerformanceCounter显然更准确。但是,如果你需要进行任何类型的“定时暂停”(例如帧速率限制所需的那些),你需要小心坐在一个调用QueryPerformanceCounter的循环中,等待它达到某个值; 这会占用100%的处理器。相反,考虑一个混合方案,你需要传递超过1毫秒的时间,然后只进入QueryPerformanceCounter 100%-busy循环,你可以调用Sleep(1)(不要忘记timeBeginPeriod(1)!)完成你需要的最后<1/1000秒延迟。这将为您提供超精确的延迟(精确到10微秒),并且CPU使用率极低。
发布于 2019-06-24 15:10:52
System.Diagnostics.Stopwatch.GetTimestamp()返回自时间原点以来的CPU周期数(可能在计算机启动时,但我不确定)并且我从未见过它在2次调用之间没有增加。
CPU Cycles将特定于每台计算机,因此您无法使用它来合并两台计算机之间的日志文件。
https://stackoverflow.com/questions/-100001280
复制相似问题