SOFT MACHINES VISC CPU架构初步解析

这个中间翻译层和Intel的CISC x86指令转RISC uops指令格式不同，Intel的翻译是完全基于硬件完成，优势是翻译速度，缺点是丧失了灵活性。也就是说如果翻译部分需要更新，就需要修改硬件，只能等待下一代芯片，而全美达和VISC都选择把翻译层做在软件上，好处是降低了设计复杂度，允许软件层面的补丁来持续更新翻译部分，坏处是性能会受到影响，毕竟每一条指令都要经过翻译。为了减少这一负面影响，全美达使用了两种技术，也就是动态翻译代码缓存和分层的反馈式代码优化来解决这个问题，这项技术后来也被NVIDIA做进了丹佛计划中的自研核心上。Soft Machines在这个问题上则处理得比较含糊，在VISC的媒体通气会上公布的一页PPT上出现了与全美达和丹佛类似的Dynamic optimization动态优化流程，但是没有更进一步披露的情况下，也无法确认这个设计是否暗示着采用了与全美达和丹佛类似的流程。

但是可以确定的是，即便这个动态优化流程存在，也没有设计得如同全美达和丹佛那样激进。据外媒报道，Soft Machines曾表态不应该在软件层面上投入过多的优化精力来追求性能。这是一句非常耐人寻味的话。为什么Soft Machines没有选择和以往的几个设计一样，在软件层面做大量的优化来追求性能呢？这就是VISC结构有意思的地方：Soft Machines虽然吸收了前辈们的经验引入了软件翻译层，但是却不在软件层面上做性能优化，它的秘密武器藏在硬件微结构上。

实现指令切分与核心融合   VISC核心微结构解析

在Soft Machines设计的这种执行框架下，软件翻译层翻译完的指令会通过一个全局共享的硬件前端（Global Front End），指令序列会在这里被切分成多个虚拟硬件线程，然后继续递交给多个执行核心。

VISC的执行框架与核心流水线

指令序列如何切分呢？我们可以看看这个直观的例子，以下四条指令看似是只能逐一执行的单线程任务，但通过指令切分，VISC结构可以让它实现部分并行运算。

1.寄存器1=寄存器2+寄存器 3

2.寄存器4=寄存器2+寄存器 4

3.将地址01的值装入寄存器1

4.寄存器1=寄存器1+寄存器4

首先在允许寄存器重命名的情况下，前三条指令可以单独开辟一个硬件线程来执行。我们来分析一下为什么：第一条指令之前没有任何指令，肯定可以独立开来并行执行；第二条指令只需要读取寄存器2的值，只要寄存器堆的读写端口足够多，同时读一个寄存器的值没有问题，因此也可以独立开来并行执行，第三条指令需要对寄存器1做写操作，看上去与指令1有冲突，但是通过寄存器重命名可以将第一条指令的寄存器1和第三条指令的寄存器1分别重命名成两个不同的物理寄存器，因此也可以独立开来并行执行。但是第四条指令需要用到寄存器1的新值，也就是刚刚从地址01装载上来的值，这是一个真实的数据相关关系，不能通过寄存器重命名变换来消除掉，所以第四条指令不再能够并行。

这个例子演示了简单的一个硬件指令切分，从上个世纪60年代开始，业界就在苦苦追求能够进行全程序范围的指令分析，从而设计出并行度达到理论大值的架构，这种架构被称为数据流架构（Dataflow architecture）。但是截至目前为止，数据流架构仍然没有在CPU这个层面迈向实用化，事实上，传统硬件乱序多发射也正是这样分析指令相关性、抽取指令级并行度的，但是硬件受限于规模，只能在有限的范围内做这样的相关性分析，这个范围被称为乱序执行窗口的大小。在Intel的新一代的Skylake微结构上，这个窗口大小约为200多条指令，也就是说，即便考虑进指令融合，目前的硬件分析处理极限也就是在200～300多条指令的范围上。因此，现在广泛流行的硬件乱序多发射实际上是一个经过弱化、分析范围受到极大限制的数据流架构。基于软件的分析可以克服硬件分析范围不足的问题，目前的软件分析可以借助自身的灵活性去分析几乎无穷大范围的指令序列，相关的一些优化也做进了标准的编译优化流程里，只是分析速度会比硬件有数量级程度的落后。

VISC核心流水线细节

VISC在SPEC2006的测试成绩，SHASTA和TAHOE分别是VISC的第一代和第二代设计的代号，1T代表1个软件线程，2PC代表两个物理核心（Physical Core），除了VISC以外，其余芯片虽然有多核设计，但是只能把一个软件线程放在一个核心上执行。

那么VISC的这个解决方案厉害的部分在哪里呢？注意框架图中的全局共享前端部件，它画在Virtual Cores的框架内部，也就是说它同样是通过硬件进行指令分析。这个硬件分析流程能做到多快的分析速度，能分析多大范围的指令，在公开资料中都没有披露，但笔者仍为此感到兴奋，因为这个设计有着暗含的一层意思：如果VISC的设计方案，没有信心在指令级并行度的抽取范围上超越传统的硬件乱序多发射，他们就不会选择把这个关键部件做在硬件上，否则就失去了创新技术的意义。可以乐观地估计，VISC的设计将可以在指令级并行度的抽取能力上大大超越传统框架下的乱序多发射，可能更加逼近数据流架构的完全形态，亦或者是业界长期困扰无法解决的线程级推测执行的硬件实现版。无论这个设计方案后能否达到设计预期，都是一个非常值得钦佩，也非常值得关注的大胆尝试。

除了硬件切分以外，这个核心微结构里面还存在着另一个亮点。在全局共享前端切分了执行序列以后，被分隔开的各个独立执行线程可以被动态地分配给下面的多个物理执行核心，分配粒度达到了几个时钟周期的级别，并且含糊地提到了可以动态地追踪各个核心中的数据流向。这是令笔者感到兴奋的第二个亮点：业界一直在探索的另外一个方向，核心融合，在VISC的微结构中现身了。“核心融合”实际上就是坊间流传很久的“逆向超线程”技术，将多个核心的执行资源合并成一个来使用，也是VISC结构的重点。在往期的《微型计算机》也曾介绍过，核心融合技术的一大难题是如何实现各个核心间的低延迟通信。在上面的那个指令切分例子中，如果我们把前三条指令放到三个不同核心上执行，到了第四条指令的时候，就要把负责指令1的核心和负责指令3的核心中产生的新数据传递给负责指令4的核心，如果低延迟通信不能实现，逆向超线程实际上也就是镜中花水中月。Soft Machines宣称可以在几个周期的延迟下通过寄存器堆和一级缓存交换数据，尤为令人震惊。

另一个值得关注的问题是推测执行（Speculative Execution）。现代高性能微结构大量地使用推测执行来提高性能，例如往期介绍过的访存地址反别名的推测性分析，以及分支预测。如何进行精准的推测，以及如何从错误推测中快速回退也是非常重要的高性能设计技术。Soft Machines披露，VISC结构可以在个位数的执行周期中从错误预测的分支中回退，但是除此以外没有披露其他有用的信息。从核心内部的流水线上来看，分派（Dispatch）、寄存器读与执行和传统流水线区别并不大，但是整个流水线的前半段才是VISC的不同之处。硬件虚拟线程的形成（formation）、执行资源的分配（allocation）、调度（scheduling）花了9-12个周期的时间，对比传统的硬件乱序多发射流水线，指令从取出到解码、重命名、推入保留站也需要大约十个时钟周期左右，从流水线深度上来说VISC与传统解决方案可能是互相持平。Soft Machines认为自己的设计应该算是短流水，对此笔者不敢苟同，在流水线深度上来说VISC结构并不占优势。硬件虚拟线程的处理也是颇为核心的要素，可惜的是Soft Machines到目前为止也没有公布更多的信息，使得外界的判断多半流于猜测。虽然许多关键细节缺失，但从目前已知的信息来看，VISC的这个设计基本已经靠拢了大家想象中的“逆向超线程”，由一个全局共享前端对一个单线程的指令切分成多个虚拟硬件线程，然后多核心的执行资源互相协作执行，允许低延迟地相互传递数据，可以说“逆向超线程”是描述这种设计的好解释。

可信度不高 疑云重重的测试数据

从设计框架上来看，VISC确实非常超前，实践了至少两个目前仍处于探索阶段、未见大规模工业化量产的结构设计点，那么它的实测性能如何呢？从VISC开始放出消息到现在，许多人为它宣称的IPC成倍提高感到震惊，后来更是由震惊转而怀疑。Soft Machines于今年向媒体公布了一组测试数据，但是仍未能打消怀疑，反而引来了更多外界的质疑。如上一页右下图，这组数据的横轴是SPEC2006的性能测试分数，纵轴是这个SPEC分数水平背后对应的单位能量消耗。乍看之下，VISC的新设计似乎在性能和能耗上完全碾压了现有乱序多发射设计中的几个代表性样本，但实际上并非如此。这张图被诟病多的一点就是：图中的SPEC2006测试分数不是SPECint也不是SPECfp，而是SPECint和SPECfp的几何平均数，使得其真实性能水平被盖上了一层伪装。

SPECint和SPECfp是SPEC CPU基准测试程序中的两大组件，包括截然不同的一批测试项目，分别统计整数性能和浮点性能。由于整数和浮点测试集的性能特征差别太大，一般来说这两个分数是各自独立计算的。Soft Machines将这两者混合统计是一个明显、不可辨驳的错误，也让外界对VISC产品的性能解读变得更加困难。当年基于超长指令字结构的安腾系列CPU就是在浮点上领先同时代其他硬件的乱序多发射设计，但是整数性能则十分孱弱。笔者怀疑Soft Machines的这个错误是为了掩盖整数性能的落后，而有意为之。

即便忽视了混合SPECint和SPECfp这个严重错误，Soft Machines的测试仍旧如同筛子一样满是疑点和漏洞。Soft Machines声称所有的参测CPU都按照某种“业界标准”把测试分数按照Last-Level-Cache(即处理器的后一级缓存，如普通CPU的三级缓存)1MB大小的设定进行了调整。笔者从未听说过有这个“业界标准”的存在，SPEC测试集中的测试程序有的对Last-Level-Cache极其敏感，如429.mcf，在一定Last-Level-Cache容量范围以内它的执行性能几乎是随着容量呈现线性增长的，也有的如同403.gcc，在不同的Last-Level-Cache大小下性能只有个位数百分点的小幅波动，几乎可以忽略不计。这个“业界标准”就算是真的存在，又要如何去处理这种情况呢？对不同的测试子项进行不同的加权处理吗？