超算队内培：HPL作业总结

<h2 id="跑分任务总结">跑分任务总结</h2>

<table>
  <thead>
    <tr>
      <th style="text-align: center">(/TFLOPS)</th>
      <th style="text-align: center">Theoretical value</th>
      <th style="text-align: center">Proposal</th>
      <th>Yours</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="text-align: center">HPL(4$\times$cpn)</td>
      <td style="text-align: center">12.4</td>
      <td style="text-align: center">8.45</td>
      <td>8.76（姜智瀚）</td>
    </tr>
    <tr>
      <td style="text-align: center">HPL(2$\times$4 张 v100)</td>
      <td style="text-align: center">62.4</td>
      <td style="text-align: center">33.89</td>
      <td>36.19（冯浚轩）</td>
    </tr>
    <tr>
      <td style="text-align: center">HPCG(4$\times$cpn)</td>
      <td style="text-align: center">12.4</td>
      <td style="text-align: center">0.06</td>
      <td>0.13（张景润，姜智瀚）</td>
    </tr>
    <tr>
      <td style="text-align: center">HPCG(2$\times$4 张 v100)</td>
      <td style="text-align: center">62.4</td>
      <td style="text-align: center">1.08</td>
      <td>1.07（冯浚轩）</td>
    </tr>
  </tbody>
</table>

<h3 id="计算理论性能">计算理论性能</h3>

<ul>
  <li><a href="https://ark.intel.com/content/www/cn/zh/ark/products/120490/intel-xeon-gold-6150-processor-24-75m-cache-2-70-ghz.html">Intel Xeon Gold 6150</a></li>
  <li>18 核 36 线程，TDP 165W</li>
  <li>单核睿频 3.7 GHz，全核睿频 3.4Ghz，AVX2 全核睿频 3Ghz</li>
  <li>AVX-512 只能运行在 2.7Ghz 以下，有 2 个 AVX-512 FMA 单元</li>
  <li><a href="http://blog.sysu.tech/Benchmark/%E5%A6%82%E4%BD%95%E8%AE%A1%E7%AE%97CPU%E7%AE%97%E5%8A%9B%E7%90%86%E8%AE%BA%E5%B3%B0%E5%80%BC/">每时钟周期浮点运算数理论值</a> $\frac{512}{64}\times 4=32$</li>
  <li>HPL 是计算密集型程序，应当关闭超线程！</li>
</ul>

<div class="language-shell highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1
2
</pre></td><td class="rouge-code"><pre><span class="o">[</span>cpn233]<span class="nv">$ </span><span class="nb">cat</span> /proc/cpuinfo | <span class="nb">grep </span>name | <span class="nb">cut</span> <span class="nt">-f2</span> <span class="nt">-d</span>: | <span class="nb">uniq</span> <span class="nt">-c</span>
     36  Intel<span class="o">(</span>R<span class="o">)</span> Xeon<span class="o">(</span>R<span class="o">)</span> Gold 6150 CPU @ 2.70GHz
</pre></td></tr></tbody></table></code></pre></div></div>

<ul>
  <li>$4\text{Nodes}\times 36\text{Cores}\times 2.7 \text{GHz}\times32\text{IPC}=12441.6 \text{GFLOPS}$</li>
  <li>节点数 x 单节点物理核数 x 单核运行频率 x 每时钟周期浮点运算数</li>
</ul>

<div class="language-shell highlighter-rouge"><div class="highlight"><pre class="highlight"><code><table class="rouge-table"><tbody><tr><td class="rouge-gutter gl"><pre class="lineno">1
2
3
</pre></td><td class="rouge-code"><pre><span class="o">[</span>gpu55]<span class="nv">$ </span>nvidia-smi <span class="nt">--query-gpu</span><span class="o">=</span>clocks.max.sm <span class="nt">--format</span><span class="o">=</span>csv <span class="nt">--id</span><span class="o">=</span>0
clocks.max.sm <span class="o">[</span>MHz]
1530 MHz
</pre></td></tr></tbody></table></code></pre></div></div>

<ul>
  <li>V100 SXM2 单卡有 5120 个 CUDA 核心，2560 个 FP64 单元。</li>
  <li>双精度性能为 $1530\text{MHz}\times2560\text{Cores}\times 2\approx 7.8\text{TFLOPS}$</li>
  <li>ASC19 现场用的 V100 PCI-E 稍弱一些，$7 \text{TFLOPS}$</li>
  <li>也可在<a href="https://www.nvidia.cn/data-center/v100/">官网</a>上直接查到性能数据</li>
  <li>明年比赛大概率会使用 <a href="https://www.nvidia.cn/data-center/a100/">A100 PCI-E</a>
    <ul>
      <li>安培架构的 TensorCore 可做 FP64 矩阵乘法，要考虑进去！</li>
    </ul>
  </li>
</ul>

<h3 id="选择针对硬件架构特别优化的软件软件包">选择针对硬件架构特别优化的软件软件包</h3>

<ul>
  <li>反例：轩轩一开始使用英伟达官网上八年前的 hpl-2.0_FERMI_v15 进行跑分！
    <ul>
      <li>直接调用 cuBLAS，未对规模小的矩阵优化</li>
      <li>只能跑到理论性能的十分之一</li>
    </ul>
  </li>
  <li>明年 A100 是新的 Ampere 架构，不能使用之前的二进制包（只支持到 Volta）！
    <ul>
      <li>单卡性能 19.5TFLOPS（TensorCore）</li>
    </ul>
  </li>
  <li>CPU 上的跑分，一般使用 MKL 中提供的即可。</li>
</ul>

<blockquote>
  <p>（使用两个节点后）…现在效率只有 58%了，怎么看这个数值都太感人了吧，可能是其它的小参数有限制，也可能是网络原因</p>
</blockquote>

<ul>
  <li>引入多节点进行计算后会由于节点间延迟高通信的原因导致性能下降</li>
</ul>

<ul>
  <li>使用 IntelMPI 的时候可以配置 <a href="http://blog.sysu.tech/MPI/Intel%20MPI/I_MPI_FABRICS/">InfiniBand</a> 来优化连接带宽。</li>
  <li>Intel MPI 提供了名为 Direct Access Programming Library（DAPL）的中间层来支持多架构，兼容多种网络硬件及协议，优化网络互联。</li>
  <li>其他 MPI 实现也有类似手段。可以参照去年永锋的 wiki：重新编译 openmpi + 不用 tcp 多机 GPU HPL。</li>
  <li>总之，在网卡、交换机支持的情况下，尽量少用 TCP！</li>
</ul>

<blockquote>
  <p>Linpack 算法可以说是最精妙的并行算法，算法本身的细节可以通过大量调整参数，应用于各种不同计算环境的 Benchmark（杜总）</p>
</blockquote>

<ul>
  <li>不同于机器学习中的「炼丹玄学」</li>
  <li>讲武德，遵守基本法（则）</li>
</ul>

<ul>
  <li>Amdahl 定律
    <ul>
      <li>$\text{Speedup}=1/\left(\left(1-f\right)+\frac{f}{m}\right)$</li>
      <li>$f$ 为问题的并行化比例，$m$ 为并行核数</li>
      <li>问题规模 N 固定时，可并行化的比例是固定的，加速比有上限</li>
    </ul>
  </li>
</ul>

<ul>
  <li>Gustafson 定律
    <ul>
      <li>$\text{Speedup}=(1-f)+mf$</li>
      <li>问题规模不固定时，问题并行化程度越高，加速比越接近于并行核数</li>
      <li>对 Amdahl 模型的补充修正，重拾对大规模并行计算的信心</li>
    </ul>
  </li>
</ul>

<ul>
  <li>一般问题规模越大越好
    <ul>
      <li>不造成内存页交换</li>
      <li>系统总内存（显存）的 80%?</li>
      <li>系统空闲内存（显存）的 90%?</li>
    </ul>
  </li>
</ul>

<ul>
  <li>矩阵被分成 $\text{NB}\times\text{NB}$ 的循环块，分配到各个进程当中去处理</li>
  <li>取决于单进程所能调度的资源限制
    <ul>
      <li>CPU 核数</li>
      <li>CPU 向量化指令同时操作的元素数</li>
      <li>CPU 对应的缓存大小</li>
      <li>GPU 单线程束的宽度</li>
      <li>单进程占用内存（显存）</li>
    </ul>
  </li>
</ul>

<ul>
  <li>一般 N 要微调成 NB 的整数倍，防止边缘处性能下降</li>
  <li>$\text{NB}\times 8$ 一定是 Cache line 的倍数</li>
  <li>对于 AVX-512 指令集优化的 benchmark，一般来说是 384
    <ul>
      <li>实际上还是都测一下</li>
    </ul>
  </li>
  <li>对于 GPU 上的 benchmark，一般至少要设置成 32 的整数倍
    <ul>
      <li>一个 Warp 的宽度</li>
    </ul>
  </li>
  <li>NB 过大容易导致 Cache Miss</li>
</ul>

<h4 id="第-9-行-pmap-process-mapping-处理器阵列排布方式">第 9 行 PMAP process mapping 处理器阵列排布方式</h4>

<ul>
  <li>按行的排列方式适用于节点数较少、每个节点内 CPU 数较多的系统</li>
  <li>按列的排列方式适用于节点数较多、每个节点内 CPU 数较少的系统</li>
  <li>一般在大规模集群系统上，按列的排列方式的性能远好于按行的排列方式</li>
  <li>小型集群上，行优先略优</li>
</ul>

<h4 id="第-1112-行-p--q-二维进程映射">第 11~12 行 P × Q 二维进程映射</h4>

<ul>
  <li>P × Q = 进程数
    <ul>
      <li>一般来说一个进程对于一个 CPU 可以得到最佳性能</li>
    </ul>
  </li>
  <li>P 的值尽量取得小一点（$P\le Q$），因为向量维度相同时，列向通信量（通信次数和通信数据量）要远大于横向通信。</li>
  <li>P 不宜过小（1），不利于计算过程中通过 Lookahead 掩盖通信开销</li>
  <li>$P = 2^n$，即 P 最好选择 2 的幂。
    <ul>
      <li>HPL 中，L 分解的列向通信可选二元交换法（Binary Exchange）。</li>
    </ul>
  </li>
</ul>

<h4 id="第-13-行-threshold-检验结果时的计算精度">第 13 行 threshold 检验结果时的计算精度</h4>

<ul>
  <li>不许改，使用默认的 16.0
    <ul>
      <li>不然结果非法就白跑了</li>
    </ul>
  </li>
</ul>

<h4 id="第-1421-行-递归分解的方式">第 14~21 行 递归分解的方式</h4>

<ul>
  <li>每次完成 NB 列的消元，然后更新后面的矩阵，NB 的消元就是 L 的分解</li>
  <li>每次 L 的分解只在一列处理器中完成</li>
  <li>PFACTs 和 RFACTs 存在三种方法，对应参数的含义详见参考论文
    <ul>
      <li>Left-looking</li>
      <li>Crout-looking</li>
      <li>Right-looking</li>
      <li>对性能的影响不大，一般使用经验值（1 或 2）</li>
    </ul>
  </li>
  <li>NBMINs,NDIVS 取一样的值，经验值 2</li>
</ul>

<h4 id="第-23-行-bcasts-l-的横向广播方式">第 23 行 BCASTs L 的横向广播方式</h4>

<ul>
  <li><code class="language-plaintext highlighter-rouge">0=1rg,1=1rM,2=2rg,3=2rM,4=Lng,5=LnM</code></li>
  <li>前 4 种适合于快速网络</li>
  <li>后 2 种采用将数据切割后传送的方式，主要适合于速度较慢的网络
    <ul>
      <li>一般不采用后两种方式。</li>
    </ul>
  </li>
  <li>一般来说
    <ul>
      <li>在小规模系统中，选择 0 或 1</li>
      <li>对于大规模系统，选择 3</li>
    </ul>
  </li>
</ul>

<h4 id="第-25-行-depths-l-的横向通信的通信深度">第 25 行 DEPTHs L 的横向通信的通信深度</h4>

<ul>
  <li>依赖于机器的配置和问题规模的大小</li>
  <li>经验值 1（优先）,0</li>
</ul>

<h4 id="第-2627-行-u-的广播算法">第 26~27 行 U 的广播算法</h4>

<ul>
  <li>U 的广播为列向广播，HPL 提供了 3 种 U 的广播算法：
    <ul>
      <li>二元交换（Binary Exchange）法</li>
      <li>Long 法</li>
      <li>混合法</li>
    </ul>
  </li>
  <li>推荐 Long 法</li>
</ul>

<h4 id="第-2829-行-l-和-u-的数据存放格式">第 28~29 行 L 和 U 的数据存放格式</h4>

<ul>
  <li>若选择「transposed」，则采用按列存放，否则按行存放。</li>
  <li>影响 Cache Miss</li>
  <li>GPU 上还要考虑合并访存的问题</li>
  <li>推荐第一个 1，第二个 0</li>
</ul>

<h4 id="第-30-行-equilibration">第 30 行 Equilibration</h4>

<ul>
  <li>主要在回代中使用</li>
  <li>对性能影响极小，可使结果更精确</li>
  <li>建议打开</li>
</ul>

<h4 id="第-31-行-memory-alignment-in-double">第 31 行 memory alignment in double</h4>

<ul>
  <li>用于在内存分配中对齐地址</li>
  <li>在向量化指令中有更佳表现</li>
  <li>一般设为 8 的整数倍</li>
</ul>

<h2 id="presto-赛题探索">PRESTO 赛题探索</h2>

<ul>
  <li>甘家振
    <ul>
      <li>在天河上部署所有依赖，并完成 modulefile</li>
      <li>在天河上成功运行两个算例</li>
    </ul>
  </li>
  <li>冯浚轩
    <ul>
      <li>在天河上部署所有依赖（使用 spack）</li>
    </ul>
  </li>
  <li>吕天翔
    <ul>
      <li>在自己实验室的集群上运行两个算例</li>
    </ul>
  </li>
</ul>

<h2 id="下一阶段任务">下一阶段任务</h2>

<ul>
  <li>自己有更多的想法可以自行探索</li>
  <li>每个人的工作在 wiki 上展示出来的方式
    <ul>
      <li>争取做到「一个人做了等于大家都做了」的效果</li>
      <li>切忌眼高手低</li>
    </ul>
  </li>
  <li>尽可能提高合作效率
    <ul>
      <li>避免无谓的重复试错</li>
    </ul>
  </li>
</ul>

<ul>
  <li>在天河上部署 PRESTO 环境依赖并成功跑通两个算例
    <ul>
      <li>后续在天河上测已优化程序的可扩展性</li>
      <li>天河上已有安装好的 glib 和 fftw</li>
    </ul>
  </li>
</ul>

<ul>
  <li>分析两个官方算例，搞清楚一下几个问题
    <ul>
      <li>建议借助各种工具（advisor/vtune/aps，或自行探索其他工具）</li>
      <li>这两个算例在算什么，有哪些流程？</li>
      <li>每个步骤的耗时情况？</li>
      <li>代码的热点、瓶颈在哪里（计算/访存/通信）？</li>
      <li>各部分数据的依赖情况？</li>
      <li>哪些地方可以并行？</li>
      <li>整理一份初步的 proposal 草稿（中/英文）</li>
      <li>做一些数据可视化工作</li>
    </ul>
  </li>
</ul>

<ul>
  <li>探索不同软件环境下的性能对比
    <ul>
      <li>不同编译器</li>
      <li>不同编译选项</li>
      <li>不同 MPI</li>
      <li>python/ipython</li>
      <li>最好能有一个自动化测试脚本，可以在决赛现场使用</li>
    </ul>
  </li>
</ul>

<ul>
  <li>尝试使用 mkl fftw 或 cufft 代替 fftw
    <ul>
      <li>一个可行方向，暂不清楚 fftw 在总时间里的占比</li>
      <li>cufft 的接口和 fftw 接口略有差异，不过应该可以完成</li>
    </ul>
  </li>
</ul>

<ul>
  <li>阅读<a href="https://wu-kan.cn/2021/03/14/HPL-AI/">论文</a>中对 HPL 算法的详细介绍</li>
  <li>阅读 <a href="https://enigmahuang.me/2017/12/27/HPCG_3_Notes/">HPCG 3.0 reference implementation 阅读笔记</a>
    <ul>
      <li>思考 HPCG 跑分时候如何分配进程到节点的映射</li>
    </ul>
  </li>
  <li>使用 3 机 12 卡，破 ASC19 HPL 跑分记录（50.21 TFlops）</li>
</ul>

<h2 id="下期内培预告">下期内培预告</h2>

<ul>
  <li>本周末，具体时间地点待定</li>
  <li>By 黄承欢：选拔赛优化组必做题讲解+如何舒服地进行调优工作
    <ul>
      <li>优化至每轮迭代 1.4ms</li>
    </ul>
  </li>
</ul>