我正在使用C ++和OpenMP编写应用程序,我希望可靠(并且正确)地测量部分执行的时间。我已经回顾了几个选项(Windows,TDM-GCC x64 4.8.1):
omp_get_wproc
和clock
似乎可以完成这项工作,但文档(与实际行为直接相矛盾)说它们衡量的是给定流程消耗的总时间资源(例如,一秒钟,两个工作线程数为两秒)。 "正确"行为是不我想要的,time
/ difftime
没有足够的分辨率,GetProcessTime
(WinAPI)执行时钟应该做什么,并且是特定于平台的,QueryPerformanceCounter
(WinAPI)似乎是要走的路,但是特定于平台,high_resolution_clock
工作正常,但它是新标准的一部分。我的问题主要是:人们如何做科学计算,为什么这样做呢?并且,clock
的行为是我的标准库实现中的错误还是过于流行的误解?
编辑: 小解释:我对使用C ++ 11有点犹豫,因为我可能会在有些旧软件的集群上运行我的代码。
答案 0 :(得分:3)
直接从我目前的研究项目中复制:
#include <chrono>
#include <type_traits>
/** @brief Best available clock. */
using clock_type = typename std::conditional<
std::chrono::high_resolution_clock::is_steady,
std::chrono::high_resolution_clock,
std::chrono::steady_clock>::type;
我们希望测量墙上时间,而不是用户空间CPU周期是公平的,并考虑到多线程开销。不幸的是,许多实现将high_resolution_clock
定义为real_time_clock
的别名,如果在测量期间调整系统时间,这将破坏我们的结果。
是的,std::chrono
是一个C ++ 11的功能,但如果你正在研究,那么是什么阻止你使用最现代的编译器?您不会需要您的代码来编译可能存在于客户某个尘土飞扬的酒窖中的最奇怪的平台。无论如何,如果你不能拥有C ++ 11,你可以自己轻松实现这些时钟。它们(至少在GNU libstdc ++中)只是clock_gettime
周围的薄包装器。
答案 1 :(得分:1)
你没有提到boost::chrono
。与C ++ 11 chrono
相同,但与C ++ 03编译器一起使用。
另外,我无法理解你对C ++ 11的犹豫。我们差不多在2015年,而C ++ 11并不是那么新。它甚至不是最新的标准。所以,#include <chrono>
是一种可行的方式。
但请注意,chrono
在Visual Studio 2013标准库实现中有所不同。我个人在任何地方使用std::chrono
,并通过条件boost::chrono
和defines
将其与typedef
交换。希望他们能在Visual Studio Next中修复它。