7703.572978 task-clock (msec) # 0.996 CPUs utilized
1,575 context-switches # 0.204 K/sec
18 cpu-migrations # 0.002 K/sec
65,975 page-faults # 0.009 M/sec
25,719,058,036 cycles # 3.340 GHz
<not supported> stalled-cycles-frontend
<not supported> stalled-cycles-backend
12,323,855,909 instructions # 0.48 insns per cycle
2,337,484,352 branches # 303.429 M/sec
200,227,908 branch-misses # 8.57% of all branches
3,167,237,318 L1-dcache-loads # 411.139 M/sec
454,416,650 L1-dcache-load-misses # 14.35% of all L1-dcache hits
326,345,389 LLC-loads # 42.363 M/sec
<not supported> LLC-load-misses:HG
我在libCCC的C中用perf stat编写了我的代码。它对双向链表进行排序，导致大量列表遍历操作，这意味着它可能会询问位于不同内存地址的许多数据。但是，现代处理器支持多级流水线操作，分支预测和无序执行，因此这些应该增加在相同时间间隔内执行的平均指令量。实际上，根据分析数据，每两个周期仅处理一条指令。可能导致这种现象的原因是什么？
答案 0 :(得分：1)
你的CPU只是在等待记忆，这就是全部。正是这种效果证明了HyperThreading的合理性：现代CPU可以快速切换，一个核心可以在两个线程上工作，在另一个线程在内存上等待时执行一个指令。
答案 1 :(得分：0)
仅仅因为你有一个管道绝不意味着它总是会被有效地使用。就像添加缓存一样，任何一个都可能会降低性能，而不是提高性能。所以没有理由假设无论你的处理器有多“现代”，你总能得到一些神奇的表现。问题从你的代码开始，它是你的应用程序出于某种原因，你如何编写你的应用程序你使用什么语言你使用什么编译器，你使用什么编译器选项是性能的第一步，然后是平台，ram，缓存，磁盘操作系统等都发挥作用。自从处理器成为瓶颈之后已经很多年了，假设您能够以尽可能快的速度提供处理器并假设指令序列是管道友好的并且您基本上没有数据访问，那么确定您可以尖叫，但现实是处理器花了很多时间等待数据或指令。您可以编写非常简单的基准测试，即使只有两个指令循环，并且由于各种因素，处理器读取的性质，对齐导致它获取的内容远远超过其需要，因此可以看到性能差别很大，移动对齐到高速缓存行的敏感区域可能导致额外的高速缓存行读取。这只是一对/几条指令，请考虑您的应用使用了多少指令。然后混合数据访问。基准测试在某种程度上是无用的，除了表明除了你可以操纵结果以使某些东西看起来好或坏之外，它并不意味着什么。
在你的情况下，你只是不编写你的代码以使编译器能够友好地执行，更可能是你的数据访问，你如何构建你的数据（可能使用字节数组而不是更大的数组，使用不同的结构大小的项目等），上帝禁止在两倍高速缓存行边界的功率上剥离数据。
开始调整您的数据或代码，重新排列源代码中的支持函数，您可能具有按此顺序定义的函数a，b，c，更改顺序a，c，b，如何改变性能？在项目开头附近添加一个虚拟全局函数（或进入引导带并添加或删除nops）可以在该虚拟函数中内联一个然后两个然后三个然后四个等等nops或其他类似的安全指令。更改变量的大小，如果可能，更改数组元素的大小，重新排列结构中定义的变量的顺序。其中一个或全部加上许多其他内容可能会影响您的效果。
底线，拥有现代处理器与任何随机程序的每个指令平均时钟无关。您希望每个时钟都能获得许多指令（并且没有理由认为一旦您在计算机上找到了一个最佳位置，您将该程序带到该程序在那里执行的另一台兼容计算机，它可能是狗慢在其他类似的类机器上快速上一个）。