第11章 优化多线程应用程序

对软件来说，为持续增长的CPU核数做好准备，对应用程序在未来的成功至关重要。

11.1 性能扩展和开销

通过可伸缩定律将计算单元（线程）之间的通信描述为影响性能的另一个门控因素。通用可伸缩定律描述性能劣化由多个因素导致：
        1. 随着计算单元增加，它们开始竞争资源，导致在同步这些访问上增加额外的耗时。
        2. 多个工作单元共享资源，需要在多个工作工作单元之间保持共享资源的状态一致。

11.2 并行效率指标

评估应用程序的并行效率时推荐使用有效CPU利用率，该指标基于有效时间。因为高CPU和IPC可能是由于自旋导致的。

11.2.1 有效CPU利用率

有效CPU利用率表示应用程序有效利用可用CPU的情况，显式了系统上所有逻辑CPU和平均CPU利用率。CPU利用率只统计了有效时间，没有包含并行运行系统引入的开销和自旋。

11.2.2 线程数量

配置低于可用线程运行应用程序，则没有充分利用它的资源。运行过多的线程又会导致上下文切换次数频繁。

为了避免线程创建和销毁的开销，工程师通常会分配一个具备多个线程的线程池，用于等待管理程序分配并发执行任务，这对执行短周期任务尤其有效。

11.2.3 等待时间

等待时间是指软件线程被同步阻塞或者发起同步锁的API导致的等待，等待时间是线程粒度的。

操作系统的调度器可基于同步或者抢占停止线程的执行，这样等待时间可以被进一步拆分为同步等待时间和抢占等待时间。大量的同步等待时间可能提示应用程序有高度竞争的同步对象。大量的抢占等待时间可能是线程超额认购的问题，此时开发者应该考虑减少线程的数量或者增大每个工作线程的任务粒度。

11.2.4 自旋时间

自旋时间也属于等待时间，经常在同步API导致CPU轮询时发生。实际上，内核的同步原语实现更倾向于在锁上自旋一段时间，而不是立即进行线程上下文切换，尽管更多的自旋时间反映了有效工作时间的浪费。

使用Intel VTune Profiler、Linux perf、Coz、eBPF和GAPP进行分析

11.7 检查缓存一致性

通过窥探缓存来监视所有内存事务并相互协作来保持内存一致性，能缓解缓存一致性，代价是一个处理器的修改会使另一个处理器的缓存中相应的缓存行失效，这会导致内存类型的CPU空转。浪费带宽。

一致性问题分为：真共享和伪共享。

11.7.2 真共享

unsigned int sum
// parallel
{
    for (int i = 0; i < N; i++)
        sum += a[i];
}

真共享意味着很难检测到数据竞争。幸运地是，Clang的Thread sanitizer和helgrind工具可以。

使用C++原子变量有助于解决真共享发生时的数据竞争问题 。但是，它高效地序列化原子变量访问，可能会影响性能。另一个方法解决真共享问题的方法是使用本地线程存储。

11.7.3 伪共享

当两个不同的处理器恰好修改位于同一缓存行的不同变量时，称为伪共享。

struct S {
    int a;
    int b;
}；

S s;

{
    for(int i = 0; i < N; i++)
        s.a += A[i];
    for(int i = 0; i < N; i++)
        s.b += B[i];
}

针对伪共享问题，用户首先运行微架构探索分析，检测应用程序是否发生了伪共享问题，如果出现高竞争访问指标，则是。接下来选择“分析动态内存对象”选项来运行内存访问分析，帮助找到导致竞争问题的数据结构访问。通常，这类内存访问都具有高时延。

使用perf c2c工具检测具有高缓存一致性损耗的内存访问。

通过内存对象对齐/填充可能会消除伪共享。

从性能角度来看，状态转换成本可能是最需要考虑的事情。在CPU读/写操作周期间，所有缓存状态中唯一不涉及高损耗跨缓存子系统通信和数据传输是修改M和独有E状态。

11.8 总结

        1. 应用软件为多核做好准备；
        2. 线程通信可能会产生负加速效果。优化多线程应用程序的性能还涉及检测和缓存争用和一致性问题。