我希望计算API返回值所花费的时间.这种行动所花费的时间是纳秒秒.由于API是C++类/函数,我使用timer.h来计算相同的:
#include <ctime>
#include <cstdio>
using namespace std;
int main(int argc, char** argv) {
clock_t start;
double diff;
start = clock();
diff = ( std::clock() - start ) / (double)CLOCKS_PER_SEC;
cout<<"printf: "<< diff <<'\n';
return 0;
}
上面的代码给出了以秒为单位的时间.如何在毫秒秒内获得相同的精度？
我正在从一个线程发送网络数据包,并在另一个运行在不同CPU核心上的线程上接收回复.我的进程测量每个数据包的发送和接收之间的时间(类似于ping).我正在使用rdtsc来获得高分辨率,低开销的时序,这是我的实现所需要的.
所有测量看起来都很可靠.尽管如此,我仍然担心核心的rdtsc准确性,因为我一直在阅读一些暗示tsc未在核心之间同步的文本.
恒定的TSC行为可确保每个时钟周期的持续时间均匀,并支持将TSC用作挂钟定时器,即使处理器内核更改频率也是如此.这是所有英特尔处理器的架构行为.
我仍然担心核心的累积性,这是我的问题
我在SO上看到这篇文章,其中包含C代码以获取最新的CPU周期数:
基于CPU周期计算的C/C++ Linux x86_64中的分析
有没有办法在C++中使用这个代码(欢迎使用windows和linux解决方案)？虽然用C语言编写(而C是C++的一个子集)但我不太确定这段代码是否适用于C++项目,如果没有,如何翻译呢？
我使用的是x86-64
EDIT2:
找到此功能但无法让VS2010识别汇编程序.我需要包含任何内容吗？(我相信我必须换uint64_t到long long窗户......？)
static inline uint64_t get_cycles()
{
uint64_t t;
__asm volatile ("rdtsc" : "=A"(t));
return t;
}
EDIT3:
从上面的代码我得到错误:
"错误C2400:'操作码'中的内联汇编语法错误;找到'数据类型'"
有人可以帮忙吗？
挂钟时间通常由系统RTC提供.这主要仅提供低至毫秒范围的时间,并且通常具有10-20毫秒的粒度.但是,gettimeofday()的分辨率/粒度通常报告在几微秒范围内.我假设微秒粒度必须来自不同的来源.
gettimeofday()的微秒分辨率/粒度是如何完成的？
当从RTC获取毫微秒的部分并且从不同的硬件获取微秒时,出现了两个源的定相问题.这两个来源必须以synchronized某种方式.
这两个来源之间的同步/阶段是如何完成的？
编辑:从我在amdn提供的链接中看到的,特别是以下的英特尔链接,我在这里添加一个问题:
是否gettimeofday()在微秒制度中提供分辨率/粒度？
编辑2:总结amdns 答案以及更多阅读结果:
Linux仅在启动时使用实时时钟(RTC)与更高分辨率的计数器同步,即Timestampcounter(TSC).引导后gettimeofday()返回一个完全基于TSC值和该计数器频率的时间.frequency通过将系统时间与外部时间源进行比较来校正/校准TSC的初始值.调整由adjtimex()函数完成/配置.内核运行锁相环以确保时间结果是单调且一致的.
这样可以说gettimeofday()具有微秒分辨率.考虑到更现代的Timestampcounter在GHz体系中运行,可获得的分辨率可能在纳秒范围内.因此这个有意义的评论
/**
407 * do_gettimeofday - Returns the time of day in a timeval
408 * @tv: pointer to the timeval to be set
409 *
410 * NOTE: Users should be converted to using getnstimeofday()
411 */
可以在Linux/kernel/time/timekeeping.c中找到.这表明在稍后的时间点可能存在更高分辨率的功能.现在getnstimeofday()只在内核空间中可用.
但是,查看所有涉及的代码以获得正确的信息,显示了很多关于不确定性的评论.有可能获得微秒分辨率.该功能gettimeofday()甚至可以在微秒方案中显示粒度.但是:由于driftTSC频率无法准确校正,因此对其准确性有严重的考虑.此外,在Linux中处理这个问题的代码的复杂性暗示着相信它实际上很难做到正确.这是特别的,但不仅仅是由Linux应该运行的大量硬件平台引起的.
结果: …
在我们的应用程序的Linux版本中,我需要一个用于嵌入式探查器的高分辨率计时器.我们的分析器测量的范围与单个功能一样小,因此它需要一个优于25纳秒的定时器精度.
以前我们的实现使用内联汇编和rdtsc操作直接从CPU查询高频定时器,但这是有问题的,需要经常重新校准.
所以我尝试使用该clock_gettime函数来查询CLOCK_PROCESS_CPUTIME_ID.文档声称这给了我纳秒时间,但我发现单次调用的开销clock_gettime()超过250ns.这使得不可能将事件计时100ns,并且在计时器功能上具有如此高的开销会严重降低应用程序性能,从而扭曲配置文件超出值.(我们每秒有数十万个分析节点.)
有没有办法调用clock_gettime()开销小于¼μs？或者是否有其他方法可以可靠地获得时间戳计数器,开销<25ns？还是我坚持使用rdtsc？
下面是我过去常用的代码clock_gettime().
// calls gettimeofday() to return wall-clock time in seconds:
extern double Get_FloatTime();
enum { TESTRUNS = 1024*1024*4 };
// time the high-frequency timer against the wall clock
{
double fa = Get_FloatTime();
timespec spec;
clock_getres( CLOCK_PROCESS_CPUTIME_ID, &spec );
printf("CLOCK_PROCESS_CPUTIME_ID resolution: %ld sec %ld nano\n",
spec.tv_sec, spec.tv_nsec );
for ( int i = 0 ; i < TESTRUNS ; ++ i …我正在编写一个C代码,用于测量获取信号量所需的时钟周期数.我正在使用rdtsc,在对信号量进行测量之前,我连续两次调用rdtsc来测量开销.我在for循环中重复了这么多次,然后我将平均值用作rdtsc开销.
这是正确的,首先要使用平均值吗？
尽管如此,这里的一个大问题是,有时我会得到开销的负值(不一定是平均值,但至少是for循环中的部分值).
这也影响了连续计算sem_wait()操作所需的cpu周期数,有时也证明是负数.如果我写的不清楚,这里有一部分我正在编写的代码.
为什么我会得到这样的负值？
(编者注:请参阅获取CPU周期计数？以获得完整的64位时间戳的正确和可移植方式."=A"编译为x86-64时,asm约束只能得到低或高32位,具体取决于寄存器分配是否发生为uint64_t输出选择RAX或RDX .它不会选择edx:eax.)
(编辑的第二个注释:哎呀,这就是为什么我们得到负面结果的答案.仍然值得留下一个注释作为警告,不要复制这个rdtsc实现.)
#include <semaphore.h>
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <inttypes.h>
static inline uint64_t get_cycles()
{
uint64_t t;
// editor's note: "=A" is unsafe for this in x86-64
__asm volatile ("rdtsc" : "=A"(t));
return t;
}
int num_measures = 10;
int main ()
{
int i, value, res1, res2;
uint64_t c1, c2;
int tsccost, tot, a;
tot=0;
for(i=0; i<num_measures; i++)
{ …我想在特定点获得CPU周期.我在这一点上使用这个功能:
static __inline__ unsigned long long rdtsc(void)
{
unsigned long long int x;
__asm__ volatile (".byte 0x0f, 0x31" : "=A" (x));
return x;
}
问题是它总是返回一个增加的数字(在每次运行中).就好像它指的是绝对时间.
我错误地使用了这些功能吗？
我正在尝试编写一些代码来确定是否clock_gettime使用CLOCK_MONOTONIC_RAW将给我的结果来自不同内核上的相同硬件.
据我所知,每个核心都可能产生独立的结果,但并非总是如此.我被赋予了在所有内核上获得定时的任务,精度为40纳秒.
我没有使用的原因CLOCK_REALTIME是我的程序绝对不能受NTP调整的影响.
编辑:
我找到了unsynchronized_tsc函数,它试图测试所有内核上的TSC是否相同.我现在试图找出是否CLOCK_MONOTONIC_RAW基于TSC.
最终编辑:
事实证明,CLOCK_MONOTONIC_RAW它总是可以在多核系统上使用,即使在英特尔机器上也不依赖于TSC.
我正在使用开源库进行 i2c 总线操作。这个库经常使用一个函数来获取毫秒分辨率的实际时间戳。
示例调用：
nowtime = timer_nowtime();
while ((i2c_CheckBit(dev) == true) && ((timer_nowtime() - nowtime) < I2C_TIMEOUT));
使用此 i2c 库的应用程序使用大量 CPU 容量。我发现，运行程序最多的时候是调用函数timer_nowtime()。
原函数：
unsigned long timer_nowtime(void) {
static bool usetimer = false;
static unsigned long long inittime;
struct tms cputime;
if (usetimer == false)
{
inittime = (unsigned long long)times(&cputime);
usetimer = true;
}
return (unsigned long)((times(&cputime) - inittime)*1000UL/sysconf(_SC_CLK_TCK));
}
我现在的目标是，提高这个功能的效率。我是这样试的：
struct timespec systemtime;
clock_gettime(CLOCK_REALTIME, &systemtime);
//convert the to milliseconds timestamp
// incorrect way, because (1 / 1000000UL) …std::chrono提供几个时钟来测量时间。同时，我猜 cpu 评估时间的唯一方法是计数周期。
问题 1： cpu 或 gpu 是否可以通过计数周期来评估时间？
如果是这样的话，因为计算机计数周期的方式永远不会像原子钟那样精确，这意味着period = std::ratio<1>计算机的“秒”（）实际上可能比实际秒更短或更大，从而导致在长时间运行计算机时钟和 GPS 之间的时间测量。
问题2：正确吗？
某些硬件具有不同的频率（例如空闲模式和 Turbo 模式）。在这种情况下，这意味着循环数将在一秒钟内发生变化。
问题 3： cpu 和 gpus 测量的“周期数”是否因硬件频率而异？如果是，那么如何std::chrono处理？如果不是，一个周期对应什么（比如什么是“基本”时间）？有没有办法在编译时访问转换？有没有办法在运行时访问转换？
我很困惑rdtscp在多核环境中是否单调递增。根据文档：__rdtscp，rdtscp似乎是基于处理器的指令，可以防止围绕调用重新排序指令。
处理器在每个时钟周期单调递增时间戳计数器 MSR，并在处理器复位时将其复位为 0。
rdtscp肯定会在同一个 CPU 内核上单调递增，但是这个rdtscp时间戳是否保证在不同的 CPU 内核上是单调的？我相信没有这种绝对的保证。例如，
Thread on CPU core#0 Thread on CPU core#1
unsigned int ui;
uint64_t t11 = __rdtscp(&ui);
uint64_t t12 = __rdtscp(&ui);
uint64_t t13 = __rdtscp(&ui);
unsigned int ui;
uint64_t t21 = __rdtscp(&ui);
uint64_t t22 = __rdtscp(&ui);
uint64_t t23 = __rdtscp(&ui);
以我的理解，我们可以有一个决定性的结论t13 > t12 > t11，但我们不能保证t21 > t13。
我想写一个脚本来测试我的理解是否正确，但我不知道如何构建一个例子来验证我的假设。
// file name: rdtscptest.cpp
// g++ rdtscptest.cpp -g -lpthread -Wall -O0 -o …