相关疑难解决方法(0)

有没有一种简单的方法可以在执行C程序时快速计算执行的指令数量(x86指令 - 每个指令的数量和数量)？

我gcc version 4.7.1 (GCC)在x86_64 GNU/Linux机器上使用.

是否可以通过perf收集硬件计数器统计信息,仅用于程序执行的一部分？如果是这样,怎么样？

likwid提供了能够定义命名区域的功能,但如果只在安装了perf的系统上实现这一点,那将会很棒.

以前的一些问题已经返回相关答案,但仍有一些缺点:

• 使用探针我得到相同的错误,我使用的是稍微更新的内核(3.13).这些修补程序是否在较新版本中可用？
• 使用perf_event_open我想保持在命令行上定义事件的灵活性.我还看了一下perf stat 本身的代码,但似乎没有通过调用perf_event_open进行设置.

我试图用来clflush手动驱逐缓存行,以确定缓存和行大小.我没有找到任何关于如何使用该指令的指南.我所看到的,是一些使用更高级别功能的代码.

有一个内核函数void clflush_cache_range(void *vaddr, unsigned int size),但我仍然不知道在我的代码中包含什么以及如何使用它.我不知道size该功能是什么.

更重要的是,我怎样才能确定该行被驱逐以验证我的代码的正确性？

更新:

这是我想要做的初始代码.

#include <immintrin.h>
#include <stdint.h>
#include <x86intrin.h>
#include <stdio.h>
int main()
{
  int array[ 100 ];
  /* will bring array in the cache */
  for ( int i = 0; i < 100; i++ )
    array[ i ] = i;

  /* FLUSH A LINE */
  /* each element is 4 bytes */
  /* assuming that cache line size is 64 bytes */
  /* array[0] till …

我正在尝试针对特定的 Kaby Lake CPU (i5-7300HQ) 优化以下子例程，理想情况下，与原始形式相比，代码速度至少快 10 倍。该代码在 16 位实模式下作为软盘式引导加载程序运行。它在屏幕上显示一个十位数的十进制计数器，从 0 - 9999999999 计数然后停止。

我查看了 Agner 的微体系结构和汇编优化指南、 指令性能表和英特尔的优化参考手册。

到目前为止，我能够做的唯一明智的优化是将loop指令交换为dec + jnz，在此处进行解释。

另一种可能的优化可能是交换lodsbfor mov + dec，但我发现的关于它的信息一直存在冲突，有些人说它有一点帮助，而另一些人则认为它实际上可能会损害现代 CPU 的性能。

我还尝试切换到 32 位模式并将整个计数器保留在一个未使用的寄存器对中以消除任何内存访问，但在读入一点后我意识到这十位将立即被缓存，并且 L1 缓存之间的延迟差异和寄存器只有大约三倍，所以绝对不值得以这种格式使用计数器的额外开销。

（编者注：add reg延迟为 1 个周期，add [mem]延迟约为 6 个周期，包括 5 个周期的存储转发延迟。如果[mem]像视频 RAM 那样不可缓存，则更糟。）

org 7c00h

pos equ 2*(2*80-2)  ;address on screen

;init
cli
mov ax,3
int 10h
mov …

我正在使用开源库进行 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) …

我使用以下代码来分析我的操作,以优化我的函数中的cpu周期.

static __inline__ unsigned long GetCC(void)
{
  unsigned a, d; 
  asm volatile("rdtsc" : "=a" (a), "=d" (d)); 
  return ((unsigned long)a) | (((unsigned long)d) << 32); 
}

我不认为这是最好的,因为即使连续两次通话也给了我"33"的差异.有什么建议 ？

std::chrono提供几个时钟来测量时间。同时，我猜 cpu 评估时间的唯一方法是计数周期。

问题 1： cpu 或 gpu 是否可以通过计数周期来评估时间？

如果是这样的话，因为计算机计数周期的方式永远不会像原子钟那样精确，这意味着period = std::ratio<1>计算机的“秒”（）实际上可能比实际秒更短或更大，从而导致在长时间运行计算机时钟和 GPS 之间的时间测量。

问题2：正确吗？

某些硬件具有不同的频率（例如空闲模式和 Turbo 模式）。在这种情况下，这意味着循环数将在一秒钟内发生变化。

问题 3： cpu 和 gpus 测量的“周期数”是否因硬件频率而异？如果是，那么如何std::chrono处理？如果不是，一个周期对应什么（比如什么是“基本”时间）？有没有办法在编译时访问转换？有没有办法在运行时访问转换？

在最近的英特尔ISA文档中,该lfence指令被定义为序列化指令流(防止指令流无序执行).特别是,该指令的描述包括以下行:

具体来说,LFENCE不会执行,直到所有先前的指令在本地完成,并且在LFENCE完成之前没有后续指令开始执行.

请注意,这适用于所有的指令,不只是内存加载指令,使得lfence 更多的不仅仅是一个存储排序防护.

虽然这现在出现在ISA文档中,但不清楚它是否是"架构",即所有x86实现都遵守,或者它是否特定于Intel.特别是AMD处理器是否也将lfence序列化为指令流？

我正在尝试在 x86-64 处理器上分析执行时间的代码。我指的是这篇英特尔白皮书，并且还浏览了其他 SO 线程，讨论了在此处和此处使用 RDTSCP 与 CPUID+RDTSC 的主题。

在上面提到的白皮书中，使用 CPUID+RDTSC 的方法被称为不可靠，并且也使用统计数据进行了证明。

CPUID+RDTSC 不可靠的原因可能是什么？

此外，同一白皮书中的图 1（最小值行为图）和图 2（方差行为图）中的图具有“方波”模式。什么解释了这种模式？

我试图确定读取元素所需的时间,以确保它是缓存命中或缓存未命中.为了阅读顺序我使用_mm_lfence()函数.我得到了意想不到的结果,经过检查后,我看到lfence函数的开销不确定.所以我正在执行程序,在例如100 000次迭代的循环中测量这种开销.我得到一次迭代的超过1000个时钟周期的结果,下次是200.这可能是lfence函数开销之间存在这种差异的原因,如果它是如此不可靠,我怎样才能正确判断缓存命中和缓存未命中的延迟？我试图使用与此帖相同的方法:使用时间戳计数器进行内存延迟测量

给出不可靠结果的代码是这样的:

for(int i=0; i < arr_size; i++){
  _mm_mfence();
  _mm_lfence();
   t1 = __rdtsc();
  _mm_lfence();
  _mm_lfence();
   t2 = __rdtsc();
  _mm_lfence();

   arr[i] = t2-t1;
}

arr中的值在不同的范围内变化,arr_size为100 000.