有没有工具或方法可以告诉我一个代码块使用了多少个时钟周期？
对于更大的代码块，手工调试和计数很痛苦。
最佳答案
在x86上，Intel's IACA (Intel Architecture Code Analyzer是我所知道的唯一静态分析器。它假定缓存未命中为零，并进行了其他各种简化，但是有些有用。
我认为它还假设除最后一个分支以外的所有分支都不被采用，因此对于带有已采取分支的循环体来说，它可能没有用。
IACA的数据也有一些错误，例如它认为shld在Sandybridge上运行缓慢。它确实知道一些非显而易见的内容，例如SnB-family CPUs can't micro-fuse 2-register addressing modes的事实。
自从Haswell更新以来，它基本上已被放弃。 Skylake可以在比Haswell更多的执行端口上运行某些指令（请参见Agner Fog's instruction tables），但是管道足够相似，因此结果应该非常有用。另请参见x86标签Wiki上的其他链接，包括英特尔的优化手册，以帮助您理解输出。
我喜欢使用此iaca.sh包装器脚本将-64设置为默认值（可以用-32覆盖）。我忘记了我写了多少（也许只是末尾的if (($# >= 1))位）以及LD_LIBRARY_PATH部分的来源。iaca.sh：
#!/bin/bash
myname=$(realpath "$0")
mypath=$(dirname "$myname")
ld_lib="$LD_LIBRARY_PATH"
app_loc="../lib"
if [ "$LD_LIBRARY_PATH" = "" ]
then
export LD_LIBRARY_PATH="$mypath/$app_loc"
else
export LD_LIBRARY_PATH="$mypath/$app_loc:$LD_LIBRARY_PATH"
fi
if (($# >= 1));then
exec "$mypath/iaca" -64 "$@"
else
exec "$mypath/iaca" # there is no -help, just run with no args for help output
fi
例如：就地前缀总和，来自SIMD prefix sum on Intel cpu：
#include <immintrin.h>
#ifdef IACA_MARKS_OFF
#define IACA_START
#define IACA_END
#else
#include <iacaMarks.h>
#endif
// In-place rewrite an array of values into an array of prefix sums.
// This makes the code simpler, and minimizes cache effects.
int prefix_sum_sse(int data[], int n)
{
// const int elemsz = sizeof(data[0]);
#define elemsz sizeof(data[0]) // clang-3.5 doesn't allow const int foo = ... as an imm8 arg to intrinsics
__m128i *datavec = (__m128i*)data;
const int vec_elems = sizeof(*datavec)/elemsz;
// to use this for int8/16_t, you still need to change the add_epi32, and the shuffle
const __m128i *endp = (__m128i*) (data + n - 2*vec_elems); // pointer to last full vector we can load
__m128i carry = _mm_setzero_si128();
for(; datavec <= endp ; datavec += 2) {
IACA_START
__m128i x0 = _mm_load_si128(datavec + 0);
__m128i x1 = _mm_load_si128(datavec + 1); // unroll / pipeline by 1
// __m128i x2 = _mm_load_si128(datavec + 2);
// __m128i x3;
x0 = _mm_add_epi32(x0, _mm_slli_si128(x0, elemsz));
x1 = _mm_add_epi32(x1, _mm_slli_si128(x1, elemsz));
x0 = _mm_add_epi32(x0, _mm_slli_si128(x0, 2*elemsz));
x1 = _mm_add_epi32(x1, _mm_slli_si128(x1, 2*elemsz));
// more shifting if vec_elems is larger
x0 = _mm_add_epi32(x0, carry); // this has to go after the byte-shifts, to avoid double-counting the carry.
_mm_store_si128(datavec +0, x0); // store first to allow destructive shuffle (e.g. non-avx shufps for FP or pshufb for narrow integers)
x1 = _mm_add_epi32(_mm_shuffle_epi32(x0, _MM_SHUFFLE(3,3,3,3)), x1);
_mm_store_si128(datavec +1, x1);
carry = _mm_shuffle_epi32(x1, _MM_SHUFFLE(3,3,3,3)); // broadcast the high element for next vector
}
// FIXME: scalar loop to handle the last few elements
IACA_END
return data[n-1];
#undef elemsz
}
$ gcc -I/opt/iaca-2.1/include -Wall -O3 -c prefix-sum.c -march=nehalem -mtune=haswell
$ iaca.sh prefix-sum.o
Intel(R) Architecture Code Analyzer Version - 2.1
Analyzed File - prefix-sum.o
Binary Format - 64Bit
Architecture - HSW
Analysis Type - Throughput
Throughput Analysis Report
--------------------------
Block Throughput: 6.40 Cycles Throughput Bottleneck: Port5
Port Binding In Cycles Per Iteration:
---------------------------------------------------------------------------------------
| Port | 0 - DV | 1 | 2 - D | 3 - D | 4 | 5 | 6 | 7 |
---------------------------------------------------------------------------------------
| Cycles | 1.0 0.0 | 5.7 | 1.4 1.0 | 1.4 1.0 | 2.0 | 6.3 | 1.0 | 1.3 |
---------------------------------------------------------------------------------------
N - port number or number of cycles resource conflict caused delay, DV - Divider pipe (on port 0)
D - Data fetch pipe (on ports 2 and 3), CP - on a critical path
F - Macro Fusion with the previous instruction occurred
* - instruction micro-ops not bound to a port
^ - Micro Fusion happened
# - ESP Tracking sync uop was issued
@ - SSE instruction followed an AVX256 instruction, dozens of cycles penalty is expected
! - instruction not supported, was not accounted in Analysis
| Num Of | Ports pressure in cycles | |
| Uops | 0 - DV | 1 | 2 - D | 3 - D | 4 | 5 | 6 | 7 | |
---------------------------------------------------------------------------------
| 1 | | | 1.0 1.0 | | | | | | | movdqa xmm3, xmmword ptr [rax]
| 1 | 1.0 | | | | | | | | | add rax, 0x20
| 1 | | | | 1.0 1.0 | | | | | | movdqa xmm0, xmmword ptr [rax-0x10]
| 0* | | | | | | | | | | movdqa xmm1, xmm3
| 1 | | | | | | 1.0 | | | CP | pslldq xmm1, 0x4
| 1 | | 1.0 | | | | | | | | paddd xmm1, xmm3
| 0* | | | | | | | | | | movdqa xmm3, xmm0
| 1 | | | | | | 1.0 | | | CP | pslldq xmm3, 0x4
| 0* | | | | | | | | | | movdqa xmm4, xmm1
| 1 | | 1.0 | | | | | | | | paddd xmm3, xmm0
| 1 | | | | | | 1.0 | | | CP | pslldq xmm4, 0x8
| 0* | | | | | | | | | | movdqa xmm0, xmm3
| 1 | | 1.0 | | | | | | | | paddd xmm1, xmm4
| 1 | | | | | | 1.0 | | | CP | pslldq xmm0, 0x8
| 1 | | 1.0 | | | | | | | | paddd xmm1, xmm2
| 1 | | 0.8 | | | | 0.2 | | | CP | paddd xmm0, xmm3
| 2^ | | | | | 1.0 | | | 1.0 | | movaps xmmword ptr [rax-0x20], xmm1
| 1 | | | | | | 1.0 | | | CP | pshufd xmm1, xmm1, 0xff
| 1 | | 0.9 | | | | 0.1 | | | CP | paddd xmm0, xmm1
| 2^ | | | 0.3 | 0.3 | 1.0 | | | 0.3 | | movaps xmmword ptr [rax-0x10], xmm0
| 1 | | | | | | 1.0 | | | CP | pshufd xmm1, xmm0, 0xff
| 0* | | | | | | | | | | movdqa xmm2, xmm1
| 1 | | | | | | | 1.0 | | | cmp rdx, rax
| 0F | | | | | | | | | | jnb 0xffffffffffffff94
Total Num Of Uops: 20
请注意，总的uop计数不是对前端，ROB和4宽发行版/退休版宽度重要的融合域uops。它计算未融合域的运算符，这对执行单元（和调度程序）很重要。但是，这有点愚蠢，因为在未融合的域中，最重要的是uop需要哪个端口，而不是需要多少端口。
这不是最好的示例，因为它在Haswell的shuffle端口上很容易成为瓶颈。它确实显示了IACA如何显示运动消除，微融合存储和宏融合比较与分支。
当有选择时，端口之间的uops分配是相当随意的。不要指望它能与真正的硬件相匹配。我认为IACA根本不会为ROB /调度程序建模。在先前的SO问题中已经讨论了此限制和其他限制。尝试在IACA上搜索，因为它是一个非常独特的字符串。
关于c++ - 确定一个代码块需要多少个时钟周期，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/36263258/