当 CPU 频率可变时,基于时钟的计时可靠吗?
测量经过时间的常见方法是:
const clock_t START = clock();
// ...
const clock_t END = clock();
double T_ELAPSED = (double)(END - START) / CLOCKS_PER_SEC;
我知道这不是测量实时时间的最佳方法,但我想知道它是否适用于具有可变频率 CPU 的系统。难道只是错误的吗?
A common way to measure elapsed time is:
const clock_t START = clock();
// ...
const clock_t END = clock();
double T_ELAPSED = (double)(END - START) / CLOCKS_PER_SEC;
I know this is not the best way to measure real time, but I wonder if it works on a system with a variable frequency CPU. Is it just wrong?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
有些系统架构可以改变 CPU 的频率,但具有单独且恒定的频率来驱动系统时钟。人们可能会认为 Clock() 函数会返回与 CPU 频率无关的时间,但这必须在代码要运行的每个系统上进行验证。
There are system architectures that change the frequency of the CPU but have a separate and constant frequency to drive a system clock. One would think that a
clock()
function would return a time independent of the CPU frequency but this would have to be verified on each system the code is intended to run on.在可变主频 CPU 上使用并不好。
http://support.ntp.org/bin/view/Support/KnownHardwareIssues
Linux 上的 NTP(网络时间协议)守护进程存在问题。
大多数操作系统都有一些 API 调用来获取更准确的值,例如 Windows 上的 QueryPerformanceCounter
http://msdn.microsoft.com/en-us/library/ms644904%28VS.85%29.aspx
It is not good to use on a variable clock speed CPU.
http://support.ntp.org/bin/view/Support/KnownHardwareIssues
NTP (network time prototcol) daemon on linux had issues with it.
Most OS's have some API calls for more accurate values, an example being on windows, QueryPerformanceCounter
http://msdn.microsoft.com/en-us/library/ms644904%28VS.85%29.aspx