boost :: posix_time :: microsec_clock是CPU密集型的吗？

Question

我想使用Boost以毫秒精度获得时间.(准确度不需要是毫秒,只需关闭.)

参考当地时间(以毫秒为单位)和其他时间,表示应使用微秒钟:

boost::posix_time::microsec_clock::local_time();

根据我的经验,使用标准的,低影响的系统调用(即::GetTicks()在Windows上),不可能获得精确到微秒(假设具有相似的准确度)的时间.相反,需要发出CPU密集型调用以提高精度超过毫秒(以微秒为单位).

正如我所提到的,我不需要微秒精度 - 只是接近毫秒精度.但是,Boost.Date_Time不提供任何"millisec_clock" - 它提供了一个second_clock,而下一个渐变是microsec_clock,其间没有"millisec_clock".

如果我使用microsec_clock,如上所述,获得MILLIseconds,我会被CPU密集型呼叫击中？

Answer 1

我做了一个辅助对象,用于测量函数内部的时间,使用boost :: date_time对象,特别是我使用了microsec_clock :: local_time().

我正在使用这个对象测量几百万个不同函数的快速调用(压力测试用例),突然我开始注意到我无法解释我的进程的大量执行时间.经过一些实验,我删除了大部分这些计数器,我的代码总执行时间从大约23分钟到大约12分钟(大约50%!!)

所以,根据我的经验回答你的问题,microsec_clock :: local_time()是昂贵的.

看到这个之后,我使用microsec_clock :: universal_time()而不是microsec_clock :: local_time()进行了测试,这绝对是我运行时间的改进.它还增加了大约3分钟,但好于10分钟:P.考虑一下,我想问题是local_time()抵消时间值来考虑时区,在我的情况下不需要(因为我只需要时间上的差异).我仍然需要进行测试以检查其他方法是否更快(例如clock_gettime).

我希望这是你正在寻找的答案类型.

Answer 2

根据相关文件：

在大多数 Win32 平台上，它是使用 ftime 实现的。Win32 系统通常无法通过此 API 实现微秒分辨率。如果更高的分辨率对您的应用程序至关重要，请测试您的平台以查看所达到的分辨率。

ftime 似乎并不是一个过于繁重的函数（这是一个关于它如何工作的问题），但我想这取决于你对 CPU 密集型的想法。