科技观察：神威·太湖之光超级计算机

　　我们在前面提到过，申威SW26010处理器是一个64位的乱序架构、支持SIMD单指令多数据流的RISC处理器，其中，64位是Master Core——也就是MPE Core的规格，而Slave Core——CPE Core则是奇葩的62位，它们都同样提供了264位的“向量指令集”，根据文档，CPE Core只具有一个浮点运算流水线，它每时钟周期可以做8个64位的双精度浮点运算，8个64位其实是512位，超过了向量指令集的264位宽度，因此这个性能是通过类FMA（Fused Multiply-Add，融合乘加）运算来达到，FMA指令可以同时对三个操作数进行乘和加的运算，因此被视为同时进行了两个浮点运算。这个技术在下表的Intel KNC（Knight Corner）和KNL（Knight Landing）中都有用到，但Intel Ivy Bridge-EP当中没有。Intel从Haswell开始也搭载了FMA指令。顺便提一下，Intel的KNC和KNL搭载了同样的512位宽度的向量指令集——可以同时容纳8个64位的双精度浮点数——但它们并不兼容，后者搭载的AVX512指令集在未来的Intel x86-64处理器当中也会搭载，目前包括Broadwell、Sky Lake在内的Intel x86-64处理器仅支持AVX256。

2016-06-25更新：

最新的消息表明，Jack Dongarra的2016-06-20日的《Report on the Sunway TaihuLight System》的62-bit和264-bit都属于拼写错误，现在2016-06-24日（美国时间）的新版本文档已经修正该错误。正确的应该是64-bit和256-bit，因此，按照更新的消息，Master Core和Slave Core都是完全一致的指令集：64位通用+256位向量。因而，申威SW26010不是异构处理器，神威·太湖之光也不是异构计算机。

Intel从Haswell开始搭载的FMA，融乘加，作为让运算性能翻倍的特性，已经得到了广泛的部署，我们相信申威SW26010也具有这一特性

　　申威SW26010处理器的MPE Core具有两条浮点运算流水线，浮点能力就是CPE Core的两倍，不过，在整个处理器中，MPE Core还要负责运行操作系统——一个称为RaiseOS的Linux——并同时负责与外界的各种通信事务。在历史上，一开始的多处理器计算就是AMP不对称多处理，其中OS运行在一个独占的处理器上，后来发现运行OS的这个处理器经常成为系统瓶颈……随后就出现了SMP（Symmetric Multi-Processing，对称多处理），通常来说，SMP机器上，OS和应用可以自由运行于所有的CPU/Core上。

　　在算上CPU的主频后，我们最后得到申威SW26010处理器的理论双精度浮点运算能力为3.0624TFLOPS。在这里，1TFLOPS = 1000GFLOPS。整个系统提供了125.4PFLOPS，1PFLOPS = 1000TFLOPS。

从左到右：ORNL Titan、NUDT Tianhe-2（天河二号）、Sunway TaihuLight（神威·太湖之光）

　　但有时候，理论只是理论，在这里我得说申威SW26010偏离的太多。同样采用了Mesh架构，Intel KNL在达到3.456TFLOPS——比申威SW26010处理器要高12.9%，但这不是重点——的双精度浮点性能情况下，提供了8个128位的MCDRAM通道（容量可达16GiB），并具有6个DDR4-2400外部内存（容量可达384GiB），无论带宽还是容量都要高得多。额外地，KNL每个核心具有4个硬件同步多线程，用来隐藏内存访问延迟，作为对比，每个申威SW26010提供4个128位DDR3-2133内存控制器，不支持硬件多线程。总的来说，申威SW26010处理器在持续数据供给方面比较很欠缺，同时ILP（Instruction Level Parallelism，指令集并行）上也仅仅具有OoOE（Out-of-Order Execution，乱序执行）一个特性。另一方面，申威SW26010对外仅具备一个PCI Express 3.0 x8也是一个问题，相对来说，互联架构上的PCI Express Fabric不算瓶颈。具体如下图所示：

Intel KNC、Intel KNL、SW26010，希望未来能有机会观察下Intel KNL

　　理论性能峰值基本没有可能达到，在数据供给完全不成问题，并且程序完全能达到单流水线完美执行、核心之间通信没有或很少的时候可以接近。目前TOP500使用的一个评估指标是HPL（High Performance LINPACK，LINPACK本身是LINear system PACKage的缩写，这是一种使用高斯消元法求解N元一次稠密线性方程组的测试）测试，这种测试比较简单，并可以配置一些参数用来配合机器以掩盖数据访问的延迟。例如，神威·太湖之光测试中使用了163,840个MPI进程，每个进程具备64个线程，也就是说，申威SW26010处理器的每一个Core Group上运行了一个MPI通信节点进程，然后在每一个CPE Core上运行一个MPI线程，这种方式下取得了74.15%的HPL效率（也因为这个配置在测试中没有用到MPE Core的浮点运算能力，所以结果的74.15%效率是以所有CPE Core提供的总能力125PFLOPS为准）。

HPL测试：太湖之光：93PFLOPS，效率74%，可以看到天河2号的62%有点低（这应该是由于Intel KNC的原因），而后面的K Computer（93%）和BlueGene/Q（85%）的效率却是惊人，其中，K Computer使用的是Tofu互联，BlueGene/Q是定制互联

　　显然，实际的应用程序不可能只是求解N元一次稠密线性代数方程组，目前，一个新兴的测试标准是HPCG（High Performance Conjugate Gradient，高性能共轭梯度），共轭梯度算法是一个用于求解线性方程组的迭代算法，HPCG测试使用到了目前高性能计算中常见的计算和通信模式，目测可以更好地表达高性能计算机系统的性能。推动HPCG测试的Jack Dongarra既是LINPACK标准的创始人，又是HPCG标准的创始人之一，他在负责全球超级计算机TOP500排名工作的同时也撰写了《Report on the Sunway TaihuLight System》（也就是本文的资料来源之一）。

HPCG性能TOP10

　　可以看出，HPCG TOP10按顺序分别是天河2号（0.580 HPCG PFLOPS，1.1% Peak）、K Computer（0.550 HPCG PFLOPS，4.9% Peak），然后是太湖之光（0.371 HPCG PFLOPS，0.3% Peak），0.3%的峰值理论性能效率与其他系统具有明显的差距。至于差距的来源很清楚，按照前面的分析，太湖之光/申威SW26010的处理器微架构到架构都过于简化，CPE核心是单线程单流水线（MPE核心是单线程双流水线），没有超标量，也就是分别对应单发射和双发射，指令吞吐量会有些问题，SPM暂存内存是个亮点，但实际上是将运行复杂度抛给了应用软件。

　　另外，随着处理器独有指令集而来的一个大问题就是，所有的软件组件都需要为独有的指令集重新编译，并为Mesh架构和SPM架构进行优化，此外，太湖之光的PCI Express Fabric当前问题不大，但如果要继续扩大规模，申威SW26010仅具备的PCI Express 3.0 x8接口可能会成为一个问题。另外显而易见的是，高频率、高带宽的内存控制器和PCI Express控制器都不好做，具有这些特征的处理器的功耗都不算低。总之，就我们来看，神威·太湖之光现在的设计思想仍然是先驱者性质，要在实际应用中取得好表现是极具挑战的。

一个大问题在于，一切的软件都要为独有指令集环境进行重新开发、编译、调试，乃至——优化

　　最后的最后还有几个有趣的数字，这里一并给出：神威·太湖之光（Sunway TaihuLight）的造价大概是18亿人民币，约合2.7亿美元，并由中央、江苏省、无锡市分摊，造价包括了硬件、搭建、研发以及软件。运维成本没有包括在内。

参考文献：

Jack Dongarra，《Report on the Sunway TaihuLight System》
Jack Dongarra，《Toward a New Metric for Ranking High Performance Computing System》
Jason Sewall，《Preparing for a smooth landing: Intel's Knights Landing and Modern Applications》
Ravi Budruk，Don Anderson，Tom Shanley，《PCI Express System Architecture》
Akber Kazmi，《PCI Express Basics & Applications in Communication Systems》
盘骏/Lucifer ，《Intel Ivy Bridge-EP处理器评测》，http://solution.zdnet.com.cn/2013/1125/2996552.shtml
盘骏/Lucifer ，《Intel Haswell-EP处理器评测》，http://solution.zdnet.com.cn/2014/0909/3032770.shtml