ASMDB阅读笔记

原文献：ASMDB: Understanding and Mitigating Front-End Stalls in Warehouse-Scale Computer. ISCA 2019

1. 文章的整体思路

1. 发现问题：通过Top-Down方法发现前端堵塞，L1 I Cache Miss率居高。AutoFDO重构CFG，GWP收集集群性能数据。将上述信息、二进制代码等存入ASMDB当中，进行编译驱动、反馈制导的优化，提升数据中心性能。
2. 剖析原因：一方面WSC应用一般都有较深的软件栈，工作集在4-6MB左右，这个大小大于L2 Cache，小于L3 Cache，因此远距离跳转的控制流在L1 I Cache中频繁扑空。另一方面，冷代码会挤占热代码的Cache空间，造成Cache空间浪费和前端流水线堵塞，需要更强力的冷热代码分离优化。
3. 提出优化措施：经过分析发现跳转目标具有局部性，因此使用预取的方式提前将指令缓存。另一方面，为了让预取到的指令是最常用的代码，提出进行更激进的冷热代码分离，包括函数内、BB内、Cache行内部的代码分离。
4. 实施优化和结果评价：对大集群来说直接修改硬件代价过高，因此这里使用软件的方法进行优化。编译器识别跳转代码和目标地址，在适当的位置插入预取指令，通过这种方式消除L1 I Cache失效率过高的问题。

2. ASMDB介绍

1. ASMDB集成了WSC的指令级和BB级的trace信息，每一行是一条指令，以及BB的执行次数、上下文指令、操作码、操作数类型。这些信息由GWP采样获得。ASMDB同时收集指令层面的信息、BB层面的信息，以及硬件计数器捕获的体系结构信息。
2. 这里使用了一个特殊的硬件计数器：hardware last-branch-records(LBRs)，每个LBR可以记录32次的BB执行流转换，同时还能记录目标地址。获取trace的跳转信息，通过这种方法动态重建CFG图。AutoFDO用其实现编译器反馈制导的优化。

3. 问题发掘思路

确定是什么导致了Miss，需要丰富的数据来证明自己的论点。

3.1 跳转指令分析

1. 对于指令来说，目前的预取器只能做的next-line的预取，对于长跳转往往无能为力。
2. 对Trace中所有跳转指令进一步分析，结果发现，指令频率方面直接跳转最高，占全部代码的15%，直接调用占约2%，其他的间接调用、间接跳转和返回语句占比非常少。
3. 而在所有引起Miss的指令当中，直接调用和直接跳转分别占了36%和38%，这两者贡献了超过70%的Miss。
4. 将这两者相除，得到一个量叫扑空强度，指引起miss的次数和指令数的比值。结果发现直接分支和返回指令的扑空强度只有1-2，远低于另外3者的 50+。这意味着这两者本身可以被缓存地很好。
5. 对跳转距离的分析表明，99%的直接分支跳到500个Cache行之内。另一方面有超过70%的直接调用目标在6.4MB之外，这个距离会极大的增加Miss的可能。
6. 间接调用和间接跳转本身出现的频率极少，而且他们的目标也是冷代码，因此失效强度会很高。超过80%的间接调用和58%的间接分支总是跳到单一地址，这意味着他们很容易被profile guided optimization预测。
7. 总的来说，扑空指令的分析告诉我们几件事，一是直接调用很容易引起Cache miss，二是远距离跳转贡献了大量的Miss，三是间接调用和间接跳转的目标可以被很好的预测。

3.2 冷热代码分析

1. 接下来要做的一件事是分析代码膨胀和分段情况。分析结果：较小的函数被调用更频繁。大多数观察到的Cache Miss都在代码大小大于1KB的函数里，超过一半在大于5KB的函数里。小的热点函数被频繁的inline，大多数大于5KB的函数inline超过10层。这种行为导致代码被分段以及I Cache粗利用。
2. 函数内的分段。冷代码很容易被next-line预取器预取到Cache中。66%的函数中含有超过50%的冷代码。通常来说，在几乎一半的热点函数中，有超过一半的代码几乎从未被执行到，但被预取到了I cache中。
3. Cache行内的分段：如果Cache行只被使用了50%或者更少。至少有10%的函数有超过20%的cache行被分段。这些可以在BB层次，链接时或者链接后，当编译器的剖析信息足够精确时，可以对其进行优化。
4. 举例Memcmp：足够频繁、足够大。90%的执行指令只需要2个Cache行，而覆盖99%的指令则需要41个Cache行。在100个最热的函数中，有8.2%的i-cache Miss是由于memcmp引起的。在大多数的microbenchmark中，相关代码通常会全部塞进icache里，但对于大型应用却不是这样的。基于上述分析进行了手动的代码调优，将热点指令和某些Case集中到2个Cache Line当中。仅仅通过这样的改动就能使得在web搜索这样的业务上获取0.5%到1%的端到端的性能提升。但手动优化还是存在极限的，因此使用编译技术来进行这样的优化，例如冷热代码分离和部分内联等技术旨在讲热代码尽可能的串联在一起。为了避免反馈剖析的影响，这种技术最好是在链接之后再进行优化。后一种方法可以将某些大型数据中心应用加速2%到8%。

4. 软件优化方法

1. 要求：寻找预取目标、确定预取插入点。
2. 软件预取挑战：扇入时机、扇出时机选取、指令开销。指令执行历史树、最大指令窗口大小、缓存替换算法
3. 预取插入过程：构建预失效执行历史、计算预取插入位置、插入预取、
4. 评价方法：测试集（SPEC2006和部分业务）、模拟器、系统参数
5. 预取结果：被消除的Miss率从80%增长到95%，IPC提升从8%提升到12%，性能提升从9%到11%。指令增长开销不到1%，动态执行开销约为2.5%。

5. 相关工作

2. datacenter-wide profiling数据中心级别的分析。对于仓储级数据中心的剖析与一般的桌面CPU、服务器CPU的性能分析不同，一方面软件栈要更深，上层应用需要通过多个层次的调度、虚拟、映射、资源分配，最终到达CPU时的指令流很可能已经面目全非。这方面可以借鉴一些持续在数据中心层面上做优化的人的经验。
   David A Patterson. 2008. The data center is the computer. Com- mun. ACM (2008).
   Zhen Jia, Lei Wang, Jianfeng Zhan, Lixin Zhang, and Chunjie Luo. 2013. Characterizing data analysis workloads in data centers. In Workload Characterization (IISWC).
   John L Hennessy and David A Patterson. 2012. Computer architecture: a quantitative approach.
   Luiz Andr ́e Barroso, Urs Ho ̈lzle, and Parthasarathy Ranganathan. 2018. The datacenter as a computer: Designing warehouse-scale machines. Synthesis Lectures on Computer Architecture (2018).
   Grant Ayers, Jung Ho Ahn, Christos Kozyrakis, and Parthasarathy Ranganathan. 2018. Memory hierarchy for web search. In High Performance Computer Architecture (HPCA).
3. front-end prefetching前端预取。在这方面属于技术论的范畴，当对系统进行了完整的剖析，确定出最需要优化的点，那么接下来的工作就是对这个点穷追猛打，寻找所有在前端流水方面做的研究，从中寻求灵感和突破。