当我在工作负载上运行Intel VTune时，我看到以下内容：
Memory Bound 50.8%
我阅读了英特尔文档，其中说(Intel doc)：
内存绑定测量一小部分时隙，其中管道可能因需求加载或存储指令而停滞。这主要是因为不完整的飞行中内存需求负载与执行饥饿一致，此外还有不太常见的情况，即商店可能意味着管道背压。
这是否意味着我的应用程序中大约一半的指令等待内存停滞，或者它是否比那更微妙？
答案 0 :(得分：2)
VTune使用的管道槽概念可以解释为例如在这里：https://software.intel.com/en-us/top-down-microarchitecture-analysis-method-win。 简而言之，管道槽代表处理一个uOp所需的硬件资源。因此，对于4宽CPU（大多数英特尔处理器），我们可以在每个周期执行4个操作，并且VTune将测量插槽总数为4 * CPU_CLK_UNHALTED.THREAD。 Memory Bound指标建立在CYCLE_ACTIVITY.STALLS_MEM_ANY事件的基础上，它会直接因内存而失速。考虑到乱序。基本上只有当CPU停止并且同时它具有飞行中的负载时，计数器才会递增。如果有飞行中的负载但CPU保持忙碌，则不会将其视为内存停滞。 因此，Memory Bound指标可以非常准确地估计工作负载受内存性能问题影响的程度。 50％的值意味着浪费了一半的时间来等待内存中的数据。
答案 1 :(得分：1)
slot是管道的执行端口。通常，在VTune文档中，停顿可能表示“未退休”或“未调度执行”。在这种情况下，它指的是调度了零个微指令的循环数。
根据VTune包含配置文件，Memory Bound的计算方式如下：
Memory_Bound = Memory_Bound_Fraction * BackendBound
Memory_Bound_Fraction基本上是文档中提到的插槽的一部分。但是，根据优化手册中讨论的自上而下的方法，内存绑定度量是相对于后端绑定度量的。所以这就是为什么它乘以BackendBound的原因。
我将重点介绍公式的第一项Memory_Bound_Fraction。第二项的公式BackendBound实际上很复杂。
Memory_Bound_Fraction的计算如下：
Memory_Bound_Fraction =（CYCLE_ACTIVITY.STALLS_MEM_ANY + RESOURCE_STALLS.SB）* NUM_OF_PORTS / Backend_Bound_Cycles * NUM_OF_PORTS
NUM_OF_PORTS是目标CPU的微体系结构的执行端口数。可以简化为：
Memory_Bound_Fraction = CYCLE_ACTIVITY.STALLS_MEM_ANY + RESOURCE_STALLS.SB / Backend_Bound_Cycles
CYCLE_ACTIVITY.STALLS_MEM_ANY和RESOURCE_STALLS.SB是性能事件。 Backend_Bound_Cycles的计算如下：
Backend_Bound_Cycles = CYCLE_ACTIVITY.STALLS_TOTAL + UOPS_EXECUTED.CYCLES_GE_1_UOP_EXEC-Few_Uops_Executed_Threshold-Frontend_RS_Empty_Cycles + RESOURCE_STALLS.SB
Few_Uops_Executed_Threshold是UOPS_EXECUTED.CYCLES_GE_2_UOP_EXEC或UOPS_EXECUTED.CYCLES_GE_3_UOP_EXEC，具体取决于其他指标。根据某些指标，Frontend_RS_Empty_Cycles可以为RS_EVENTS.EMPTY_CYCLES或为零。
我知道此答案仍需要大量其他解释，并且BackendBound需要扩展。但是，此早期编辑可以使答案准确无误。