Intel MIC 没有免费的午餐

最近有关 Intel 即将问世的众核 加速器--MIC的新闻报道和业内反应很有意思。  似乎跟英伟达和 AMD一样，Intel 最终也得出结论: 要解决高性能计算日益增长的功耗限制问题，混合型架构是正确的方法。

 

虽然我认同这一观点，但是围绕 MIC 芯片编程问题展开的一些讨论让我绞尽脑汁思索，尤其是这种看法: “因为 MIC 运行的是 x86 指令集，所以无需更改现有代码，移植将是免费的。”

 

功率是个问题

 

朝着混合型计算转型背后的技术基础非常引人注目，由过去十年里我们经历的巨大拐点所推动。 摩尔定律至今仍在服役，继续在每平方毫米内包含越来越多的晶体管，然而登纳德缩放比例定律 (Dennard Scaling) 却已经寿终正寝。 我们已经无法按照晶体管尺寸的比例来降低电压，因此每次运算的能耗下降速度再也无法补偿密度的增加。 如此一来，处理器现在全都受到功率的限制。  每一次集成电路更新换代，这个问题会迅速变得更加严重!

 

电路的每瓦特性能虽然仍在提升，然而现在的提升速度是每年将近 20%，而非我们过去的每年近70%。 那么我们如何能够继续在提升性能方面保持过去的节奏呢? 如何能够在截至 21 世纪二十年代末为止实现百亿亿次级 (Exascale) 计算呢? 因为底层的技术远远满足不了我们的改进需要，我们只能寄希望于大幅降低每次操作的系统总开销。

 

混合型架构是解决方案

 

这就是混合型架构的价值所在。  英伟达 GPU 采用数百个简单而节能的核心，这些核心专为并行工作负荷的高吞吐量而进行了优化。  多核 x86 处理器则采用少量复杂的核心，这些核心专为实现快速单线程性能而进行了优化，然而每次操作的能耗却高出很多倍。  为了改善应用的每瓦特性能，我们将大部分工作转到了专为吞吐量而优化的核心上来，仅使用快速 (但效率较低) 的 CPU 核心来处理常驻的串行工作。 这就是混合型架构。  因为一个核心无法做到既针对节能而优化又针对快速的单线程性能而优化，所以混合型架构让我们能够把精力集中在使 GPU 核心越来越节能上来，同时依赖 CPU 核心实现极高的串行性能。

 

Intel 现已在 MIC 方面公布了一种类似的办法。 他们没有专为吞吐量而优化的 GPU 核心，但是能够回到 15 年以前的奔腾设计上 (http://news.cnet.com/8301-13924_3-57326934-64/intel-supercomputer-revamp-needs-our-50-core-chip/)，以采用更简单的处理器核心，然后搭配宽幅向量单元，从而实现比至强处理器更高的每瓦特浮点性能。

 

目前为止，这种办法还不错。  然而，有些人说无需改变现有代码即可在 MIC 上运行，只因 MIC 采用x86 指令集。当我听到这种言论时，我感到十分困惑。  他们说，只要利用 –mmic flag 重新编译一下，现有的 MPI 或 OpenMP 代码就会与生俱来地在 MIC 处理器上运行! (换言之，这实际上忽略了至强处理器，只使用 MIC 芯片作为一个大型的多核处理器。)

 

原生模式的复杂化

 

从功能上来讲，一步简单的重新编译也许会奏效，但是我坚信，这对大多数高性能计算应用程序来说都不切实际，并没有反映出采取了什么方法使大多数人能够在 MIC 系统上实现更高的性能。

 

在多节点 MIC 系统上运行普通 MPI 代码 (one rank per core) 的理念似乎很成问题。 位于 PCIe上d的MIC卡无论什么内存都会被 50 多个核心共享，这样会导致每个核心分到的内存非常小。 据我对MPI 通信堆栈的了解，堆栈不会为实际数据留下很多内存，当然远远低于传统的每个核心 1-2 GB，大多数高性能计算应用程序均需要每个核心分得 1-2 GB内存。 而且 50 多核核心全都试图通过系统互连的网卡来发送消息，这一点似乎会导致网络拥挤。 另一个值得关注的地方是Amdahl定律瓶颈，这一瓶颈源自在低性能奔腾级标量核心上执行所有的串行代码。

 

OpenMP 方法似乎也强不了多少。 你每个核心的内存容量仍然很小，另外还有Amdahl定律瓶颈，但是至少从网卡发出的消息数量减少了。 也许这种方法最大的问题是现有的 OpenMP 代码，这些代码专为多核 CPU 而编写，不大可能具备足够的并行机制来充分得益于 50 多个向量核心。

 

MIC 的性能如何?

 

目前为止，围绕 MIC 编程的讨论对所有与性能有关的内容都避而不谈，没有直面这些问题。 我们看到，MIC 的扩展图表显示，使用的核心越多，性能提升就越大，然而却并未展示绝对性能。 而且“扩展”结果几乎全是单一芯片 (从高性能计算的角度而言完全算不上扩展)。 看起来与四年前最初的Larrabee GPU 图表非常相似。

  2011 年超级计算大会演示文稿                       2008: Larrabee: 用于视觉计算的众核 x86 架构

 

 (图片属性: 2011 年超级计算大会 Intel 展台演示文稿，题为: “Intel MIC 架构的科学应用”; 2008 年 Intel 论文，题为: “Larrabee: 用于视觉计算的众核 x86 架构”)

 

平心而论，Knights Ferry 是一款生产前的原型产品，因此性能上估计没什么竞争力。 但是，在完全不考虑性能的情况下大谈编程有多么轻松是毫无意义的。  加速器的意义在于加速! 那么想要在 MIC 上取得实际的良好性能，必须在编程方面付出怎样的辛勤工作呢?

 

没有什么“魔幻”编译器

 事实上，根本就没有什么“魔幻”编译器，没有一种编译器能够让你的代码自动实现并行化。 未来不会有什么处理器或系统 (无论是出自 Intel、英伟达还是别的什么公司) 能够消除当今程序员在面向未来编写应用程序这方面的辛勤工作。

 

在时钟频率停止增长的情况下，未来所有的性能提升均源自并行机制的加深，而功耗限制实际上会导致我们在大多数工作上运用更简单的处理器以更低的时钟频率来运行，这样就会进一步加重这一问题。 在高端方面，一台以不高于 1 GHz 频率运行的百亿亿次级浮点运算 (Exaflop) 计算机将需要多达十亿路(Billion-way) 并行机制，同理，各种规模的系统所需行机制都会大幅增加。 这意味着，所有 高性能计算节点均需要解决大量并行线程的吞吐量问题。 随着数据传输与计算相比之下的相对成本不断升高，利用本地资源也将变得越来越重要。 这将会对用来解决诸多科学难题的算法和数据布局产生重大影响，同时也是一个没有与任何一个处理器架构关联起来的根本性问题。

 

指令: 性能 + 可移植性

 对应用程序开发者来说，在多台机器上的可移植性非常重要，而指令则是一种以可移植的方式表达并行机制的好办法。 程序员把精力集中在展现并行机制上，而编译器和运行时则专注于将其映射到底层硬件上 (也许要借助于自动调谐程序)。 全新的 OpenACC 标准让用户既能够表达本地特性，又能够表达并行机制，尤其适合当今新兴的混合型架构。

现有的 OpenMP 代码页可以继续利用，但是需要一些额外的工作。 不幸的是，当今的大多数 OpenMP代码均将并行指令应用到内部循环上，这适合在少量核心上利用最少量的并行机制。  然而，为了让更多的节点并行机制在未来计算机上良好地运行，指令需要提升到调用树中来，以展现大幅增加的并行机制。

 

没有免费午餐

这需要付出劳动，然而这种劳动能够让应用程序具备内在的优势，更适合未来的架构。  在为新型英伟达 GPU 加速的 Titan 超级计算机调整代码这方面，橡树岭国家实验室最初的经验具有很大的积极意义，大幅加速了主要的科学程序。  利用 OpenACC 来表达并行机制和本地特性，由于代码经过调整后能够在GPU 上更好地运行，因此这些代码现在在 vanilla 多核 CPU 系统上的运算速度大幅提升! 针对加速器而调整高性能计算节点的确是一项很大的工作，但是这个工作能够在各种类型的计算机上让你得到回报，尤其是在未来并行机制水平更高的计算机上。

 

这就回到了针对 MIC 处理器进行编程的话题上来。 对我来说，在未来功耗限制的时代，混合型架构的意义无疑会越来越大。Intel 在 MIC 上付出的努力说明他们也认同这一点。 据报道，即将问世的 Knights Corner 处理器类似当今的 Fermi GPU: 通过 PCIe 与 x86 CPU 相联的节能型加速器。 对这两种架构进行编程应该非常类似: 结构应用程序通过指令来展示并行机制和本地特性，利用多核 CPU 来处理串行代码，而在加速器上执行并行程序内核。 寄希望于不改动高性能计算应用程序、只靠一次重新编译就能在MIC 上良好运行的想法十分不可信，在不考虑性能的情况下大谈编程如何轻松同样不可信。

 

天下没有免费的午餐。  程序员需要付出辛勤的劳动，为混合型架构而改编其应用程序的结构。 然而这项工作会为当今、尤其是未来的高性能计算系统而提供很好的回报。

 

现在就着手

 至于 Intel MIC 的性能如何，还有待于它最终上市后人们对它的检验。 但是为什么要等待呢? 现在就走混合型多核之路、提前采取行动不是更好吗。 你现在就可以在英伟达 GPU 上着手改编，无论最终选用哪一款处理器架构，你都会大幅领先于其他人。

 如果你目前已经得到 MIC 芯片，并且已经用实际应用程序进行了测试，那么我将很乐意听到你的见解。你可以在下面发表评论，分享你的经验和测试结果。 同时，我还有兴趣了解你对移师混合型多核架构的想法以及你认为我们为何需要对其进行编程。